I’m Sam from MIT UAV Team and we’re working on a competition where we need to fly inside autonomously. We’re using the 3DR Solo which has a pixhawk 2 onboard, and we’re using ArduCopter 3.4 on board. We’ve attached and calibrated the PX4Flow and the LIDER Lite rangefinder and confirmed that they are reading values and oriented properly.
We tested this in flight, and unfortunately we crashed into the wall (video here: https://youtu.be/AFeRD_LUK5U). Here is the log file of this flight
Quick note in that we decided to disable and cover the lens of the laser rangefinder before flying because the laser rangefinder and the optical flow sensor were interfering with each other. When we looked at the raw video from the optical flow sensor, we saw a white splotch that we determined to be caused by some sort of reflection between the two lenses.
During the flight, we took off in Loiter mode. The quadcopter was able to take off and I had a little bit of control (for around 3-5 seconds), and then I started to yaw the copter and it accelerated into the wall as seen in the video.
The questions that we have are:
do the readings from the optical flow look good enough? When we looked at the logs they seemed very noisy and we’re not sure if we have a faulty flow sensor or if our calibrations were ok
could there be other issues that caused this crazy acceleration into the wall when flying with just optical flow
is the laser rangefinder necessary for this flight and if so, has anyone else run into interference between the laser rangefinder and the optical flow sensor?
Thanks for replying. We will order the IR filter to get rid of the interference between the LIDAR and flow sensor and update here to see if that works.
I hadn’t seen the Optical flow on Solo guide but I went through it and that’s more/less what we did. I will make sure that the parameters match up and go through the guide before flying again. We’ll make sure to fly in better lighting with a textured floor next time.
Thanks for giving ArduPilot/Solo a try. I haven’t looked at your logs but you’ll definitely need the lidar working for the optical flow to work. There have also been a number of EKF2 fixes in the past two weeks that may help although they may not because they weren’t specifically related to optical flow.
Paul Riseborough is really the optical-flow+EKF expert so if he’s around he may be able to help.
I have been using 3.4 dev version and now RC1. I also noticed that loiter with optical flow changed behavior like Sam experienced. The earlier version (about a month old 3.4 dev) worked perfectly fine when yawing with optical flow, indeed we intentionally yawed during the flights and it didn’t cause any issue. However, this is not the case with 3.4 RC1, which seemingly confused EKF and the copter just ran away with any yaw stick input. I haven’t been able to track down the cause yet. I will run more tests and get back to this issue.
On a related question, is height limit in optical flow mode supposed to override the RC throttle input when the measured altitude gets close to e.g. alt_limit_cm? Thanks.
According to your logs, it seems that you took off in Stabilized mode and then switched to Loiter. At that moment OF.bodyX and IMU.GyrX went flat. Hopefully Paul can chime in.
After more tests it seems the range finder was the problem. It is obvious if the range finder has wrong readings after vehicle is armed (kinda expected because the initial flow rate is way off). Also I can confirm the height limit in optical flow mode does override RC throttle when measured altitude gets to height limit.
Thanks for the feedback and input. We did more tests and were also to get it working in loiter mode with OF+Rangefinder after actually enabling the rangefinder and making sure that the white splotch in the optical flow feed was gone. We didn’t end up using the IR filter (yet) but the white splotch disappeared.
The lighting didn’t end up being a problem, nor did the floor (we tested in the same space).
