Should vehicles that fully utilize a VectorNav GPS+IMU device, i.e. the VN-300, bypass EKF2 altogether?
My vehicle has only the VN-300, and we’re running it with most of the bells and whistles turned on. Practically speaking, it provides us the authoritative measurements for vehicle pose and position.
The engineer in me says that since the VN data has already been extensively filtered, we should skip EKF2 to avoid the risk of introducing errors and lag. The software guy in me somewhat agrees, but the result is a configuration that’s pretty different from (what I think is) a traditional PX4 setup. Then again, how many “traditional” systems have a $5K-ish GPS+IMU package onboard?
The other software guy in me complains that, for situations where VectorNav isn’t the sole sensor, a chunk of code that writes directly to the same uORB topics as EKF2 will just get into everyone else’s way.
So, do I (a) leave EKF2 off, and send VectorNav data directly to uORB topics including vehicle_attitude; (b) dissect incoming VectorNav data to pretend that it’s an ordinary GPS receiver and IMU, and feed the stream to EKF2 as usual; or, (c) something else entirely?
Don’t you have an IMU? What’s your flight controller?
Can you verify that the VN IMU gives a proper Attitude? What about the VN IMU calibration?
Setups I would try:
- Q_attitude_estimator & publishing position directly
- Publishing position and attitude directly
The VectorNav VN-300 is a “Dual Antenna GNSS-Aided Inertial Navigation System” . It fuses all that stuff together via Kalman filtering and provides position, velocity, orientation, and heading measurements at rates of up to 800Hz or so.
It’s got EKF2/Q_attitude_estimator already inside, which is why I asked if I should bypass the comparable functions in PX4 or not.
My FMU is a VN-300 tethered to a Beaglebone Black, along with half a ton of additional stuff.
After bleeding my eyeballs out some more last night, I realized that position_estimator_inav is mixed up in all of this, too. I think I’m going to leave it turned on, though, because it’s doing some useful sanity checking too.
 - https://www.vectornav.com/products/vn-300
What is the precision of the navigation (filtered ouput) of the VN-300, it says 3 meters but is it 3 meters to absolute GPS position or up to 3 meters jumps? Did you consider an RTK solution (~1k€, 2mm position) or geostationary satellite solution (drifting but 20cm position)?
Let’s keep it simple. If the output of the VN-300 is continuous, simply publish the data to the uORB topics and do not start any other estimator.
Publishing directly to the uORB topics seems to be working fine so far.
As a followup, we did indeed deploy with code that pushes the VN data more or less directly to uORB. The main sticking points ended up being topics that came from LPE that we lost by not running LPE, which seemed to confuse navigator the most. We basically had to track them down one-by-one, but since there weren’t very many of them, we got it resolved fairly quickly once we realized what was going on.
Hi @bgat, first of all thanks for posting this question, I know this post is fairly old, but in regard to your last message, do you happen to recall or have a list of the topics that were lost by not running the LPE?
I’m currently working on getting a VN300 to talk to PX4 on a different (Nuttx based) board. It sounds like I ended up taking a similar path, where it makes more sense to skip the PX4 EKF2 and publish directly to uORB using the already filtered data. Any other pointers or gotchas that you might be aware of when using this IMU would be welcome as well. Thank you for your time!
Hi @joshuawhitehead I know this post was a long time ago, but how are you sending the vectorNav data to the PX4 in order to bypass the EKF2. Are you using something like direct MAVLINK messages or MAVROS? I image you are building a new PX4 module that reads said messages and simply publishes?
Hopefully you see this message in modern times. I am trying to do the same but can’t figure out the best way to proceed.
@Juan_Tapiero you either publish all the same data that ekf2 would (vehicle_attitude, vehicle_local_position, vehicle_global_position) or you can feed the VectorNav sensor data (already calibrated and corrected) into the system like any other sensor.
It seems @bgat found some unexpected side effects of bypassing LPE, but left those gatchas to be rediscovered. At least we have a heads-up, tho, and that is appreciated.
@joshuawhitehead, any chance we can get the VN300 module pushed upstream? If it would take work to make a an acceptable PR, I’d be happy to help.
Unfortunately that work was done on behalf of a contract client and I have not yet gotten their permission to push that work back to the public repos. I think they’re open to it, and plan to do it eventually, but I get the impression they’re concerned about some “first to market” aspects of their product and I don’t know what their timeline for allowing that to happen looks like.