Hello everyone,
I’m from a research laboratory where I and other guys develop projects with drones for very different applications. At the moment we are using a customized Tarot 650 Sport quad-copter with Pixhawk1 and an onboard computer. On the Pixhawk the ArduCopter firmware is the version V3.6.12 at now.
While working on a different project, about one year ago, we included on board the same drone a LightWare SF20, directly connected to the Pixhawk as altimeter in order to improve the accuracy during changes in altitude. We faced with the LightWare technical support about the connection of the Lidar and the related parameters for using it as the primary altimeter. All the drones flew very well with a very good ability of vertical allignment.
Now, we are re-designing our drone for new tasks aiming at scanning unknown areas in the field of archaeology with some differences from our previous application. In particular, we expect that the ground overflown isn’t leveled due to the archeological remains.
During our past flights, before installing the SF20 and using the barometer as alt source, we noted some problems related to its innacuracy that would not be compatible with the actual requirement of flying at a constant and trusted altitude as we can do due to the rangefinder over a sufficiently regular ground, as paved areas and grass.
On Friday afternoon we made some flight tests. Firstly we tested our drone in manual mode (ALT_HOLD) thanks to an experienced pilot: the EK2_ALT_SOURCE was set to 0 (use barometer) and the drone was flying both over a leveled terrain and over some boxes (80x60x35). During this flight, the readings of the Alt fluctuated following the barometer oscillations, as expected. Then we set the EK2_ALT_SOURCE to 1 (use rangefinder) and replicated the same flights over a leveled terrain and over the boxes both in manual (ALT_HOLD) and in AUTO mode. All the tests have been good: we were able also to acquire
data with the scanning laser.
At the end we tested a different scenario, close to the actual archaeological remains that we want to scan. As you can see from the map related to the log files attached, there are a couple of trees
and a container. We tried to fly over the tree in order to test the reading ability of the scanner sensor under bushes and trees. This flight was conducted in ALT_HOLD by the pilot and the speed was very low in order to successfully scan the ground below.
In the link below, I attached the log files related to this flight from Mission Planner and from the
Pixhawk too. As you can see, when there is a first inconsistency between the computed alt and the rangefinder alt value, the target alt switches on the estimated alt (as also explained here https://ardupilot.org/copter/docs/common-understanding-altitude.html ), while on the Mission Planner screen the “Error pos vert variance” appeared coupled with the “EKF-primary changed0”.
In this situation, however, the flight continued as long as the “Error pos vert variance” appeared coupled with the “EKF-primary changed1”. This time the Pixhawk genereted a sharp reduction of the thrust command and the drone went down precipitously above the container. I cannot explain this second event.
Do somebody report an analogue behavior? Can you help me to find a possible reason and, subsequently, a possible solution? Is there any upgrade in the new firmware version related to this problem?
Note that in the final application the drone will flight in AUTO mode. Can this event occur also in this case?
Can I change any parameter in order to fly at a height comparable to the distance provided by the scan LiDar? In fact, using the barometer as primary source could introduce errors in the computation of the alt that could deteriorate the results of the reconstructed area.
I am at your disposal for additional information about the flight. Thanks for support!
Kind Regards
Link log file: https://we.tl/t-AVgsUeA59U