I have got a question about altitude mode. By reading this page in the documentation it is my understanding that altitude hold mode does not require the GPS.
But does it use GPS data if available to improve altitude estimation? I ask because I saw a fused position in the logs (I’m guessing from the barometer and GPS).
Also, since the GPS fix is not very good in the area in which we are doing these tests would using only altitude mode be better while using the GPS or deactivating it?
Correct. Altitude based on just baro data can drift over time, e.g. when the atmospheric pressure changes (aka weather) or the pressure changes based on flight direction, temperature, etc. So, GPS altitude can help to correct the altitude estimate over time, plus it will allow you to have the “absolute” altitude and not just a relative altitude relative to when you powered the Pixhawk on (or set the pressure at sea level manually).
Depends on what “not very good” means. If you are for instance flying indoor, then it might indeed be advisable not to use the GPS because it will be noisy, especially in altitude.
You could also consider using a distance sensor pointing down to improve altitude tracking.
Thank you for the extensive answer,
We are flying outdoor but in a safety area near some building so the accuracy of the data provided is not really precise. As you can see from the plot below.
We are already incorporating a distance sensor, but we have observed that it occasionally produces incorrect values, particularly when the quadcopter is nearing the ground. So, we have opted to employ the barometer instead of the range sensor as the height reference for EKF2 (
Thank you once again for your assistance.
You could try to add some filtering to you distance sensor to filter out these outlier measurements.
Also, you could try to enhance your position estimation using a flow sensor.
Thank you for the recommendation. I’m afraid I’m not an expert on the autopilot, when you say add some filtering do you mean by modifying the .cpp (
teraranger_main.cpp) file of the distance sensor or just by modifying some parameters?
Regarding the flow sensor, I will look into it, thanks.
Yes, it would involve changing the code.
Ok I see. I was wondering If I could do it through a ros2 node? The steps I have in mind would be:
- Getting the
/fmu/distance_sensor/out topic from the autopilot (through the rtps bridge)
- Filtering the data with a ros2 node
- Sending the filtered data back to the autopilot with the
Now I have some doubts. Were this to work, would it create two data sources from the range finder? So the filtered and unfiltered ones? And how can I make the autopilot discard the unfiltered data?
Thanks again for the previous answers you have been very helpful.
I’m aware I have gone quite off topic in this question, for this reason I am opening another discussion at this link regarding my question about filtering the data using a ros2 node.