Servers by jDrones

EK2_ALT_SOURCE and rangefinder

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

@rmackay9
Lightware suggested me to put your name in order to have your assistance

There is a pull request the significantly improved height estimation on the 4.1 ArduCopter branch. Are you willing to backport that to 3.6.12?

I backported it to my local 4.0 branch, and it works great.

The core issue is that EK2_ALT_SOURCE should not be set to “1” (RangeFinder) to do either “Surface Tracking” or “Terrain Following”.

This is a common misunderstanding and although I’ve put warnings on the wiki and in the EKx_ALT_SOURCE parameter descriptions users still get it mixed up sometimes.

So please set EKx_ALT_SOURCE = 0 (Baro) and then review the wiki pages below that show how terrain following is done in more manual-ish modes (AltHold, Loiter, PosHold, etc) and Auto mode:

@amilcarlucas it is not a good idea for users to be setting the EKF altitude source to range finder especially outdoors when they really want to be doing terrain following.

Can I see your parameters? And also if we don’t put alt source as rangefinder then the drone is not going to change altitude on fields that have no terrain data available. Specially for us that we fly at 1.5 alt above the ground.
For you to take advantage of rangefinder as primary source of altitude you must also set at what percentage of altitude the range finder should be activated and above that it will switch back to barometer.
Also when ekf variance error happened for us it was when we were getting different in altitude from range finder and barometer. Our problem was our range finder was slightly blocked by the drone leg and then sometimes it would get false reading at high altitude. When you are flying for example at 2meters and suddenly your rangefinder shows 0.16 meter (or any low alt close to land) the ekf will change to 0 or 1. I’m not sure. And since you’re getting this error I’m assuming you’re using a FC that have redundancies like pixhawk cube.

1 Like

@amilcarlucas What is the improvement you are talking about?
@rmackay9 I’ve already read the links you suggested and I do not misunderstand the warnings on the wiki. The aim of setting EKx_ALT_SOURCE = 1 is that I need to obtain an evolution for Alt as steady as possible. Using the Baro as primary source makes the resulting Alt value incorrect due to systematic errors. In particular, the Alt results not the same as that measured by the rangefinder (about 1 meter greater or lower): in this way I cannot know the real height the drone is flying and I cannot compare the Alt with the distance acquired by the scan sensor in order to reconstruct the ground below.

I am talking about this one:

It has not been ported to 4.0 yet.

I did a 4.0 PR to port the only the flyaway fixes, but that has not been merged yet.

At this point I don’t think it’s a good idea to try and use the blended range finder and barometer outdoors. Maybe it works a little better with Copter-4.1 but this hasn’t gone through beta testing to ensure it works reliably. I pretty sure that it won’t work well with Copter-4.0.x.

Something I don’t understand is why we shouldn’t be using rangefinder as terrain follow when flying at low altitude (1.5). There are many agricultural fields that their land is manmade and there is no terrain data available for their land. If I set primary source at 0 the copter doesn’t change altitude when there is no terrain data available for a field or if there is a wrong terrain data. I have tried to use rangefinder as ekf primary source of height and the copter flies well at low altitude. So what’s the danger here if we don’t plan on flying at high altitude with rangefinder set as ekf primary height source? And what would happen to ekf altitude estimation if rangefinder ever fails during the flight.

@JackJavan

Terrain Following is totally fine of course but instructions for how to do it are here: https://ardupilot.org/copter/docs/terrain-following.html

There’s not need to change how the estimated altitude is calculated. It’s all about the desired altitude changing with the terrain.

@ArcheoDrone

I don’t understand the “evolution for Alt” part but it sounds like you’re trying to do some mapping but I don’t see why this should require the EKF to use the range finder as its altitude source. The range finder distance is stored in the onboard logs in case this is needed for some post-processing. For terrain following (i.e. maintaining a specified distance above the terrain) we adjust the desired altitude to maintain the distance.

I don’t want to do terrain following. I want that the drone follows a constant altitude even if it flies over not leveled ground. I aggree with you that in conventional flight this result can be obtained by setting EKx_ALT_SOURCE to 0 (use barometer). Our application is quite different. We are using another sensor for mapping selected areas. This sensor measures the distance from the scanned ground (aka between the drone and the ground below). In order to reconstruct the map of this terrain, we need to obtain a fine Alt computed by the EKF. The Alt computed using the baro as primary source not only is characterized by fluctuations, but results also different from the actual flight height, making it impossible to use the data acquired by the scanning sensor successfully. On the other hand, for our previous applications, our drones flew very well with the rangefinder and EKx_ALT_SOURCE = 1.

Do you have any proposal?

Thanks to @amilcarlucas for the (interesting) reported link!!

Yesterday afternoon we made new flight tests both with the Quadcopter as described above and with an Hexacopter on the Pixhawk of which we updated the ArduCopter firmware (version V4.04).
We tested the same flight plan: the drone takes off, flies towards a waypoint in auto mode and runs into a height difference (while in auto mode).
The behavior of the drone are different:

  1. the quadcopter changes the DAlt and follows the gradient;
  2. the hexacopter remains at the Mission Alt.

What is the explanation for these so different behaviors?

Note: I can’t understand also why the ALT data saved in the .log for the Hexacopter are shifted even if in the Mission Planner console I saw correct values starting from 0 at the start.

Link .log files: https://we.tl/t-jGJU8pCUud

Which drone the ekt2_alt_sourece is set to 0 and which is set to 1?

And as far as I know the mission planner doesn’t show Dalt and achieved alt is showen.

no news about the new flights?
@rmackay9
@amilcarlucas

Servers by jDrones