Treatment of log for a ROVER with an odometer
-
Hello, I have a ROVER model that I use together with a VOXL-CAM, that is capable of visually estimating the odometry (local position values) of the circuit path, due to the circuit being underground and no GPS signal is available, the information is sent to the CUAV X7 Flight Controller where I can recover the data using the SD card slot.
I have a problem where, for some reason, while in the circuit with the QGroundControl controller the local position of the odometer is reseted in some specific places (as shown in the figure below), I believe due to the camera losing reference.
I was wondering if there was a way to correct this error so I could correctly estimate the position. If not possible would there be a way to export the *.ulg file to a *.csv for example and then manually removing the problematic points, and then re-exporting it to *.ulg so I could visualize the data in the logs.px4.io website?
Here’s two logs that I took that can help.
For this one the discontinuity apperars around 13:20 https://logs.px4.io/plot_app?log=2196a6ba-f03f-438c-bc69-28420727308a
And for this one the discontinuity appears around 11:40 https://logs.px4.io/plot_app?log=9a360a9b-ebb0-4a1a-82ac-d351c06b9c08
-
Have you reviewed the VIO troubleshooting guide?
-
If you are just trying to modify the ULG file, the tools to do so are in the PX4 project here
-
@Chad-Sweet Hey Chad, thanks for the answer, I believe is more of a problem with the camera itself, in some periods, as described above, the odometer outputs extremely high local values before resetting all to zero and losing all reference.
I'm having difficulties mapping an indoors track without GPS (basically creating a virtual map of the path), because everything goes well when the camera does not reset and I have a reliable circuit shown, but when the camera does reset all the work is lost. My client is very pressing about this matter.
Thanks for any additional information!
-
Looking at your mavlink log on estimator_visual_odometry_aligned, I can confirm VIO resetting to 0 at the moment your local position resets (picture #1).
(pic 1)
On a rover typically VIO will reset on 3 situations (everything else working normally as specified):
- Fast yaw transitions (I do see a large manual input/actuator output around that time--indicated on pic #2). To solve this, have your vehicle turn/tuned slower on yaw motions.
- auto-exposure not keeping up with rapid lighting conditions (high noon sunlight + tree shadows), the
- too much vehicle vibration (e.g. treads).
From the logs it appears you have a max yaw/roll input into the rover, that indicates scenario #1 above. If you slow down you yaw movements may solve the problem, please try that 1st (there are other, more complicated options).
(pic 2)
What you can do aside from following the vio troubleshooting guide is to monitor the vio stream on QGC. In order to do that, you need to edit the voxl-streamer service file on VOXL. Basically:
- login to VOXL
- edit /etc/systemd/system/voxl-streamer.service
- on the Exec line that says /usr/bin/voxl-streamer, append to the end of it "-c qvio-overlay".
- cycle power and QGC video should show the VIO debug video (and not the high resolution stream), showing at the top: vio xyz position and number of features
- Run thru your test again to recreate the error, when it occurs, keep in mind the number of features, if it drops under 5, you'll see vio reset confirming the reset is due to one of 3 scenarios above. If not, post a video of that as it would be a configuration issue & we'd need to see the video stream on what's happening to debug further. Good luck.
