Chapter two: Onboard Tuning & Testing a Monocular Visual Odometry System
This is the second part of my experiments with ROVIO, ; Experiment with Visual Odometry - ROVIO , we will now discuss the details of on-board integration and test phases, like the Static test, Walk Test, Initial test and the Autonomous flight…
Once the lab tests are complete and the operational envelope is defined, this is the time to test in real life on a flying vehicle. My test quadcopter is a Q450 (or 500 depending on the supplier) with 2412 type engines turning 10 1/2’’ propellers powered by 4,000mA - 3S packs.
The total weight of the configuration is 1.55 Kg without battery and 1,86Kg with the pack, making it quite heavy for a nylon frame. The experiments being accomplished in my garage, I don’t plan to get a bigger frame as this configuration is intended to be a technological demonstrator and not a fully functional solution.
Integration
This picture is from first blog
I have distributed the weight on the longitudinal axis and used the battery pack for balance. The AAEON pico-apl3 Pentium board and the 12 V 5 A Step Up-Down regulator are mounted on corrugated board that is sliding along the 10 mm tubes attached to the frame. The Battery holder is attached to the same tubes and can slide to adjust for a “0” CoG.
Static test
The camera was mounted on a tilt adjustable holder but that proved to be a source of vibration that got ROVIO loosing track. You can see this problem on the following video of a static test.
Note: Once the system is drifting there is a possibility to reset it using a python script (look @ 1:00)
The solution is to mount the camera on a damping platform that isolates the camera and particularly the IMU sensor from the vehicle vibrations.
The walk test
Once all the signal are optimal and the system start OK, it is time to simulate a flight by ‘‘walking’’ the quadcopter.
Here is the sequence:
Computer A -
Windows with Mission planner connected to vehicle as a standard GCS
Computer B -
Linux system connected to CC (passing through Beaglebone on ssh remote)
Loading 3 remote session:
a) roslaunch rovio rovio_full.launch
b) roslaunch mavros apm.launch fcu_url:=udp://0.0.0.0:14551@
c) python rovio_reset.py
Once Mavros is started you will receive message ‘‘gps glitch clear’’ confirming that the ROVIO system localisation signal is recognized by the system. Then you can go on Mission Planner and right click on the map to set EKF HOME. You will see the quad icon on the screen showing that EKF is doing its job.
Now, take the Quadcopter, hold it about 1 meter and do a circle, square, figure 8 or any pattern you like. The vehicle on the map should move accordingly without too much distortion or overshoot.
This is what I am doing on the first 20 seconds on the first video above.
Initial test
As explained above, we need to confirm the system work OK before powering the quadcopter.
Once this is confirmed, I prefer to takeoff in stabilize to make sure the quadcopter is stable at 1 Meter facing the targets and then I switch to Al-Hold just to adjust the correct power for level flight (you can actually see the overloaded Q450 oscillation @ 0:30). As the prototype is so heavy, altitude is holding at above average power level so I prefer having it stabilized before switching to loiter. Then you take a look at Mission Planner Map , for a confirmation that ROVIO is still tracking and then you switch Loiter, getting ready to switch back to Att-Hold if the Quadcopter acts like a Psychotic Wasp.
Here is a snapshot of the log showing how well the system tracks compared to IMU:
And RangeFinder ( with the altitude variation when switching to Alt_hold @ 0:30)
Conclusion
That completes what is reasonably possible to accomplish with a Q450 autonomously fling in my Garage , aka the ThunderDrone. The next steps will involve outdoor testing, but it will take a few more weeks as it is still snowing outside…
I just hope that this blog was helpful in explaining how you can build , test and fly a Monocular Robust Visual Intertial Odometry system.
