VIO and GLOBAL_POSITION_INT
I'm testing out a Starling prototype and finding that VIO works well for position hold and can do offboard mapping, figure eight etc.
I've upgraded everything to the dev builds provided by Modal:
PX4 Firmware is 1.11.3-0.2.3 from Modal.
I have tried EKF Mask of 329 and 1 for pure GPS with an M8N PX4 GPS and an MroRobotics m9N GPS which both get a good lock. I See GPS_RAW_INT is populated but never see a GLOBAL_POSITION_INT message and it seems QGroundControl always shows a GPS Error status.
What am I missing? It won't do a pure GPS position hold and worst case just flies away out of control until I revert to manual mode.
Thanks for any help!
Hi @Steven-Turner ,
I'm sorry you're dealing with this. Some of the setup with PX4 can be a pain.
This looks like a PX4 setup issue. You can try the m500 outdoor GPS parameters to see what the diff is and if you're missing something in your setup: https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/tree/master/helpers/m500
In the original starling setup, you should have SYS_HAS_MAG set to 0.
The general parameters file for starling is here: https://gitlab.com/voxl-public/flight-core-px4/px4-parameters/-/blob/master/platforms/v1.11/starling_3S_config.params
I've tried the Mro GPS, since it was nice and small, although there were some issues at the time I tried - maybe they are fixed by now. Just in case, take a look at their site to esnure it's fully supported with 1.11. There may still be a mag issue.
Let me know if this helps.
Thanks for the gouge! Tried a few of your suggestions.
I flashed the FW from the Firmware page -> https://storage.googleapis.com/modalai_public/flightcore-releases/v1.11.3-0.2.3-modalai_fc-v1_default.px4
I then loaded params from the m500 outdoor GPS file and the only difference was barometer for altitude instead of vision.
I connected one of the "Pixhawk 4" GPS units to the Voxl Flight and let it get a lock outside, to rule out the MRO unit.
QGroundcontrol says that HDOP is too high -- at 1-1.3 with 13 satellites visible. Heading looks good.
Still shows GPS Error in QGroundControl but Ready to Fly alternates between "Ready" and "Not Ready".
LOCAL_POSITION_NED looks OK.
I still don't see GLOBAL_POSITION_INT in the QGroundControl Mavlink debugger.
Was hoping I could replicate the demos performed here: https://www.youtube.com/watch?v=jLrxtM_7qyE or https://www.youtube.com/watch?v=-x4turdU2J8
I'm sure I'm missing something silly... here are a few log files and my params: https://www.dropbox.com/sh/ggb2nnezvdpf1cr/AAAzwHWzVdMrbLJR0W6sPBTfa?dl=0
Great, thanks for the info.
For logs, I'd recommending loading the .log/.ulg file to PX4 Flight Review, then share the link that's generated. It's an awesome tool.
I assume you're testing outside, not too close to trees or buildings with good view of the sky?
How are you mounting the GPS unit? Are you using a mast to create some separation. I believe you're experiencing some EMI that's jamming the GPS signal.
You can try moving the GPS as far away from the drone to see if you get the Green LED status flash showing that the GPS is fully ready. Flashing blue, means it's still waiting for the GPS to be fully ready. Small blue LED on the side will flash blue showing a lock.
You can also try opening up the GPS check values or disabling some checks. For instance you can open up ekf2_req_sacc from 0.5 to about 0.75.
There's also the GPS check you can experiment with to see what exactly the error is to get to ready (most likely interference). You can try turning off bit 4 for instance. Your mask is currently set to the default 245 or 11110101.
@RichieRich said in VIO and GLOBAL_POSITION_INT:
PX4 Flight Review
Thanks again for the prompt response.
I am outside -- clear view of the sky. Monitoring with https://play.google.com/store/apps/details?id=com.android.gpstest
Have been checking things out in the PX4 flight review tool and I think you might be right.
I do have it on a mast, but apparently still some kind of coupling is occuring. I'll keep troubleshooting. I had the EKF Mask set to 329 and was hovering just fine in POSITION_CONTROL with QVIO looking good -- and then boom the drone just took off and I had to snap it into Manual mode so that does point to perhaps some interference.
Is the firmware used in this demonstration (https://www.youtube.com/watch?v=-x4turdU2J8) a variant of the 1.11.3-0.2.3 firmware with a specific toggle between VIO and GPS?
Yeah that was a variant we tested. I'm unsure if we pushed those changes which will allow you enable this feature via parameters. I'll have to check.
Yeah, definitely getting jammed. Values should be at or below 40.
Thanks for looking into that -- would definitely like to build on that feature if possible. It seems like with the bitmask set to 329, GPS still takes some precedence over the visual odometry inputs.
I'm trying to track down the interference. Here is what it looks like with no electronics on other than USB to the Ublox M9N receiver:
Looks OK -- HDOP is solid and Horizontal velocity stays consistently low.
Here is what it looks like with just the ModalAI power module and ModalAI ESC powered:
Still low enough.
And here is what it looks like with the full VOXL Flight powered on -- which looks good but after about 4-5 seconds (once it is fully booted?) Jamming Indicator goes much higher and the horizontal velocity creeps up to 0.5-1m/s:
I've tried twisting the cabling from the ModalAI power module to the VOXL Flight, twisting every cable on the drone, getting the GPS as far away from the VOXL Flight as possible, and disconnecting the radio and cooling fan temporarily to see if they were contributing to the interference. None of these options seemed to really help.
I am going to try some shielding and ferrite beads once they arrive to see if that helps. Open to any other suggestions!
One more quick note/data -- looking at the FFT out of the ublox receiver I'm seeing the following without the VOXL Flight powered on:
"Looks" like a fairly clean GNSS signal.
With the VOXL Flight powered on:
Looks like something fairly significant around ~1600MHz and a bit more noise introduced here and there in the GNSS band.
Chad Sweet Dev Team last edited by
The TOF sensor definitely creates GPS interference. On the Seeker we mitigated by putting the GPS behind the battery using that as a shield.
That's definitely it -- thanks for sharing!
Disconnected ToF and the interference is gone.
Great to hear.
I forgot about the ToF. Chad beat me to the punch here.
Glad that helped!