Posts made by Evan Hertafeld

Hi team,

I'm setting up a drone with a Voxl Deck, and I've pulled in the default extrinsic file ("factory_m500_flight_deck") to modify for my needs. I was looking to just leave it as-is except for adding a fixed offset to all the "body" measurements, but a few things about it seem a bit off. I'd like to either correct my understanding or help the team correct the file, depending on whether these errors are in my interpretation or in the file itself.

1. The y-distance between imu0 to imu1 is 0.037m in the file, but it seems like it should be .029m according to the reference drawings (36mm - 2.8mm - 4.25mm) as well as my calipers. And .037m is wider than the board itself.

2. This is a tiny one, but the z distance between IMUs is .002 which makes sense since they're on opposite sides of the PCB. Shouldn't the Z distances for imu-to-body and imu-to-tracking differ by .002 for each IMU? They're each the same in in the config file.

3. The z height of the stereo and tof cameras relative to body are both 0 but they are clearly at different heights on the mount.

4. Per imu-to-body, the body's X is just around the back edge of the PCB (.02m behind imu0). But per tof-to-body and stereo-to-body, it's a few cm behind the board (.1m behind the cameras).

I doubt any of these (save for possibly #1) will significantly affect performance, if at all, but I imagine it's in everyone's interest for the extrinsics to be self-consistent. Should these files be corrected, or am I missing something?

For reference, here's the file I'm looking at (as set by "voxl-configure-extrinsics factory_m500_flight_deck"):

{
	"name":	"M500_flight_deck",
	"extrinsics":	[{
			"parent":	"imu1",
			"child":	"imu0",
			"T_child_wrt_parent":	[-0.0484, 0.037, 0.002],
			"RPY_parent_to_child":	[0, 0, 0]
		}, {
			"parent":	"imu0",
			"child":	"tracking",
			"T_child_wrt_parent":	[0.065, -0.014, 0.013],
			"RPY_parent_to_child":	[0, 45, 90]
		}, {
			"parent":	"imu1",
			"child":	"tracking",
			"T_child_wrt_parent":	[0.017, 0.015, 0.013],
			"RPY_parent_to_child":	[0, 45, 90]
		}, {
			"parent":	"body",
			"child":	"imu0",
			"T_child_wrt_parent":	[0.02, 0.014, -0.008],
			"RPY_parent_to_child":	[0, 0, 0]
		}, {
			"parent":	"body",
			"child":	"imu1",
			"T_child_wrt_parent":	[0.068, -0.015, -0.008],
			"RPY_parent_to_child":	[0, 0, 0]
		}, {
			"parent":	"body",
			"child":	"stereo_l",
			"T_child_wrt_parent":	[0.1, -0.04, 0],
			"RPY_parent_to_child":	[0, 90, 90]
		}, {
			"parent":	"body",
			"child":	"tof",
			"T_child_wrt_parent":	[0.1, 0, 0],
			"RPY_parent_to_child":	[0, 90, 90]
		}, {
			"parent":	"body",
			"child":	"ground",
			"T_child_wrt_parent":	[0, 0, 0.1],
			"RPY_parent_to_child":	[0, 0, 0]
		}]
}

I see the supported method for using MAVSDK with Voxl is a preconfigured Docker container, which I have successfully set up with voxl-docker to run MAVSDK and control my vehicle from within the container.

I see that by default /run/mpa/ is shared into this container, which is great. However, when I try the libmodal_pipe hello_world example, I get an error:

fatal error: modal_start_stop.h: No such file or directory

Clearly this container isn't set up with the libmodal_pipe libraries. What's the proper way to use the MPA pipes from within the voxl-docker-mavsdk-cpp container?

Hi all!

We have the wonderful luxury of GPS in our environment, but want to leverage the precision of vision-based fiducial markers. My first thought was to rely on the PX4 EKF to fuse these, but the PX4 docs discourage using two position-based systems simultaneously.

Then I realized - can't we leave vision out of the EKF entirely, fly by GPS, and rely on the relocalization to provide the correct setpoints translated into the drone's GPS NED frame?

Whether this is feasible seems to depend on whether the voxl-vision system assumes that the drone's NED frame is the same as its own vision-based NED frame (in which case this wouldn't work out-of-the-box), or if it can pull in the drone's NED frame and relocalize based on this.

In short, my question is: Will Apriltag relocalization still work if I use GPS for the PX4 EKF, assuming there's a known tag in view?

I was thinking of something simple, eg:

Use tracking cam qvio until reported quality drops below a particular value (near blowup). If it does, switch to stereo qvio feed as long as the position + velocity were recently in agreement within some threshold and its reported quality is sufficient. If not, switch to manual mode and call an adult. Once the main qvio recovers, store the position offset (for future switchovers) and switch back.

I'm sure proper fusion will obtain a smoother and more robust result, but I'd just like something that can handle a blowup without crashing.

Thanks for the reply! We'll definitely stay tuned. Curious about your thoughts on my specific approach - namely, are there enough resources to run 2 simultaneous instances of the VIO system?

Hi all,

I've had a pleasant time setting up my Voxl Flight for offboard vision-based navigation but the occasional QVIO blowup makes me seek a level of redundancy for vision tracking. The apriltag relocalization feature is great, but if we blowup while relocalizing, then the setpoints leap to the new reference frame before the next tag is detected and we jerk/crash.

I'm sure there are things I can do do reduce the chance of a blowup but it seems unlikely I could eliminate the risk entirely - loss of light, debris on the camera, the sensor shifting, could all occur if this system is deployed at scale.

Currently the PX4 EKF seems to only take in a single vision stream, so my thoughts are focused around adding this redundancy upstream (eg within the Voxl system). The general idea would be to generate some other stream(s) of Odometry data with another vision source, and be able to switch to that if the main source fails. Most likely by passing both to some monitor process that in turn sends the "clean" data out the actual QVIO pipe for PX4.

So my questions are:

1. Is this a sensible idea? Gotchas to consider? Or aught I be able to entirely mitigate QVIO blowups with a single sensor?
2. Would a second tracking camera be able to run a separate instance of QVIO? This would be the idea situation since it seems the easiest.
3. Would a non-tracking camera doing AprilTag detection, then relocalizing these detections and providing odometry data directly, be a reasonable idea? Eg my stereo cam, which isn't suitable for QVIO (bummer), could deduce position from known locations of detected tags and compute NED-frame odometry.
4. Is there existing work in this area (redundant vision on Voxl) or other ideas I should look into?

Thanks so much!