VIO coordinates suddenly resets to 0,0,0 in the air!!! every flight
-
@Chad-Sweet what do you think?
-
@Chad-Sweet and also i found this
https://docs.px4.io/main/en/advanced_config/tuning_the_ecl_ekf.html#external-vision-systemwhat do you think?
-
@Chad-Sweet
maybe I should try to fly without gps from the beginning? with a mask value of 280. do I need to include ev_rotate? and in that case I'd like to use the barometer for the altitude, not the VIO. I think for high altitudes it will be more accurate. how to do it?
Do you think it is possible to fly using VIO at 500 meters altitude and at a distance of 10-15 km? somewhere on this forum someone said that there are no height restrictions. -
Switching back and forth between GPS and VIO has not been well supported in PX4. It's an area we are investigating internally and have been working on for over a year. We are working with the PX4 dev team on better support, but it will be incremental changes for the time being.
I would not recommend using just relying on VIO outdoors as the terrain may not always be suitable.
-
@Chad-Sweet Following up on this, I have 2 drones with Flight Deck onboard and they are flying well outside with no GPS, however I have been running into a failure state where VOXL loses position and it just flies off before I manually engage the kill switch. Ultimately I'll be flying indoors, however I need to start just outside a building a go inside. I'm concerned that if I cant rely on VIO outdoors, I will run into issues indoors as well.
Can you go into more detail as to why you would not recommend using only VIO outdoors but you do indoors? I've got contrasting terrain where it should be able to easily find a relative location point without much issue.
-
The issue is less indoor/outdoor as it is scale. VIO performs best when it can track multiple points moving across large portions of the frame in a relatively short amount of time. When flying indoors this tends to be the case, as marks on the floor and walls will pass by the drone as it flys around, allowing it to get a much better sense of the location of these points relative to each other, and thus calculate how the drone has moved with relation to them. However, when flying outdoors at high altitudes the points that it sees will move much more slowly in the camera's field of view since they are much farther away, and thus small inconsistencies in the detection of said point will lead to much higher relative error and can cause blowups like the ones that you're having to kill the drone for.
In short: if there's an average error of 0.25 pixels in the detection of a feature, that's not a major issue indoors when the features are travelling dozens of pixels at a time, but will be outdoors at higher altitudes when features may be moving less than a pixel between frames.
If your goal is to use vio starting directly outside a building and then going in this should be very doable, we've used vio outdoors around 10-15 feet high without any issues, but if you're planning to fly in from a remote location and ascend/descend hundreds of feet to get to the indoor location then vio won't get the job done.
A last note for indoor-outdoor transitions, you'll need to monitor the relative light level between the environments, if the camera has to do a major auto exposure adjustment it'll likely take a couple frames to adjust to a new light level and could encounter issues if it doesn't have reliable points in that time, so you should take those entrances slowly. We've tested that transition in a few different environments and haven't had issues when there's similar light levels, but we had almost immediate blowups when flying from a bright outside desert into a dark, unlit storage container.
-
@Alex-Gardner I'm actually having issues at very low altitudes like 1ft off of the ground, both indoor and outdoor. I suspect it is because I'm over bare concrete, however the concrete does have stains and such that the camera should be able to track. I've also had this issue at about 3ft above an asphalt road. Is there any way to make it more reliable? I'm seeing a flight termination rate of about 2-3/10 due to loss of position while using VIO both indoors and outdoors.
-
How many features do you see in qvio-portal?
Have you gone through the steps in the troubleshooting document? https://docs.modalai.com/flying-with-vio/#troubleshooting-vio
-
@Alex-Gardner said in VIO coordinates suddenly resets to 0,0,0 in the air!!! every flight:
The issue is less indoor/outdoor as it is scale. VIO performs best when it can track multiple points moving across large portions of the frame in a relatively short amount of time. When flying indoors this tends to be the case, as marks on the floor and walls will pass by the drone as it flys around, allowing it to get a much better sense of the location of these points relative to each other, and thus calculate how the drone has moved with relation to them. However, when flying outdoors at high altitudes the points that it sees will move much more slowly in the camera's field of view since they are much farther away, and thus small inconsistencies in the detection of said point will lead to much higher relative error and can cause blowups like the ones that you're having to kill the drone for.
In short: if there's an average error of 0.25 pixels in the detection of a feature, that's not a major issue indoors when the features are travelling dozens of pixels at a time, but will be outdoors at higher altitudes when features may be moving less than a pixel between frames.
If your goal is to use vio starting directly outside a building and then going in this should be very doable, we've used vio outdoors around 10-15 feet high without any issues, but if you're planning to fly in from a remote location and ascend/descend hundreds of feet to get to the indoor location then vio won't get the job done.
A last note for indoor-outdoor transitions, you'll need to monitor the relative light level between the environments, if the camera has to do a major auto exposure adjustment it'll likely take a couple frames to adjust to a new light level and could encounter issues if it doesn't have reliable points in that time, so you should take those entrances slowly. We've tested that transition in a few different environments and haven't had issues when there's similar light levels, but we had almost immediate blowups when flying from a bright outside desert into a dark, unlit storage container.
This post contains really useful info..
But I'm curious about the monocular VIO's performance in pure rotation. Is pure rotation (yaw) something to be avoided as well?
-
This is also something that we've done extensive testing with. In short, yawing can actually be one of the most reliable motions if the field of view of the camera is set up correctly. Our standard tracking sensor has a 166° diagonal/100° vertical field of view. We mount the camera at 45° down from the horizon, so the bottom of the image will be ~5° past straight down, and the corners of the frame will stretch farther into the backwards left/right swaths of area. The result of this is that yawing in place actually maintains a lot of features directly below the drone, where the bottom 10° arc will always be in view and the farther up features will stay in view for a long time. If there are a reasonable amount of features in the bottom say 20-25° below the drone it'll maintain a very robust position and yaw estimate.
However, the behavior that you're probably thinking of can also happen. We've experimented on some of our other cameras that have a wide (though not as wide as the fisheye (84° vertical)) field of view also mounted at 45° below level. The result here is that the bottom of the frame ends a couple of degrees above straight down, and so that super reliable zone of features always in view doesn't exist, and the pretty reliable zone is also much smaller. The yawing in this situation can be very unreliable, and the filter can often blow up rather quickly if not also moving during the yaw. Similarly, yawing in place with little to no features directly below you will show the same behavior, and the feature tracker will struggle to track the rapidly moving horizon-level features and can blow up.
We've also done tests with the fisheye sensor mounted straight forward which resulted in the same behavior as in the second paragraph, where the lack of downward features led to us being unable to yaw in place.
TL;DR: Yawing in place without translation as well needs to see features very close to the axis of rotation or else the filter will blow up. This can be achieved with a combination of wide fields of view and aiming the sensor not level with the horizon.