Hello,
I am using Pixhawk as fight controller with APM 3.5.5 Firmware. I am facing a problem with altitude hold mode.
I arm my quad, switch to Altitude hold mode, and then increase the throttle. This is what I observe: motors not rotating till around 1300 value, 1300- 1600 very less rpm of motor (similar to rpm of 1100 value in Stabilize mode), greater than 1600 very high RPM(similar to greater than 1600 of Stabilize mode).
Since the quad did not takeoff even till 1500, I asked my friend to hold the quad at a constant height and then change the altitude by hand to observe the response in motors. The change in rpm was negligible, not sure there was even some change actually.
Stabilize mode is working properly. Stabilizing throttle is around 1250-1300.
I tried PX4Flow sonar as well as Maxbotix sonar for getting the altitude.
Is there any additional parameter to change to tell the quad to switch from distance of barometer to distance of sonar?
Altitude hold puts a âdead bandâ around mid throttle. Take off in Stabilize, climb to your target altitude and engage Altitude Hold. Works every timeâŚ
You really need to read the wiki on initial setup and how guided modes work.
For a start you need to adjust Stab hover to be as close to 1500 as you can get it, otherwise when you switch from any guided mode to Stab your copter is going to go up.
Guided modes: 1500 on throttle means stay at that altitude. Below 1500 is descend, above 1500 is ascend.
So starting at 1500 with the throttle down is telling the controller to reduce altitude (below ground), then you raise the throttle 1500 and it stays where it is (below ground), and finally you raise the throttle above 1500 and the controller increases altitude until it is above ground, at which point it takes off.
Thank you for your replies @mboland@OldGazer,
The dead band is 1400-1600.
My previous quadcopter was working in altitude hold mode (Used LidarLite v3 in that). I had read the documentation before doing it.
I did find a similar issue in the forum in which the problem was solved by re-uploading the firmware. I tried that as well.
Am I missing something? (I am getting data from sonar, it is shown in sonarrange value)
Also, what is the mapping in the altitude hold wrt stabilize mode?
Example: If my quad stabilises in 1300 throttle(in stabilise mode). 1000-1300 gets mapped into 1000-1400(if lower limit of dead band is 1400) and 1300-2000 gets mapped to 1600(the lower value)-2000? Is that right?
The dead band is used so minor hand âtremorsâ do not cause the aircraft to change altitude.
So, the aircraft is on the ground with motors armed and you switch to Altitude Hold. As far as Pixhawk knows on the ground is where you want to be and Pixhawk will not change motor speed and initiate an ascent until throttle crosses the UPPER boundary of the Altitude Hold dead band.
The fix is simple. Take off in Stabilize, climb to your target altitude and then engage Altitude Hold.
Yeah, read the Wiki and youâll find out you donât need to set Stab Hover to 1500 because Pixhawk can learn were hover throttle is: Setting Throttle Mid. Once Pixhawk figures out at what throttle setting the aircraft hovers, Pixhawk maps that PWM to Throttle Mid so the aircraft hovers at mid stick.
@OldGazer,
I have another doubt. Which the altitude reading is the Pixhawk using for maintaining altitude? Is it the one coming in the Quick values in the Mission Planner window or the sonarrange value?
These values arenât same. I think itâs because the sonarrange values is the value from the Maxbotix sonar that I am using and the other is the combination of sonar, accelerometer and barometer. Is that correct?
The altitude shown by Mission Planner is relative altitude above the home point. It is derived from EKF altitude, which is mostly affected by the barometer, but does use data from other sensors as well. The sonarrange is the raw reading from your rangefinder. Itâs normal for them to be different, although they should be similar when you are hovering just over your home location.
ArduCopter uses EKF alt to maintain altitude, unless you configure it to use something else with the EK2_ALT_SOURCE parameter.
The sonar is always used as long as it is plugged in and working - the EKF considers its data and fuses it into the overall altitude estimate. The parameter only changes the primary altitude source. For general use, keeping EK2_ALT_SOURCE = 0 is best. Setting it to anything else is mostly for special use cases, as other sensors donât always work. For example, setting it to Rangefinder can be dangerous if configured improperly, as the copter will lose its altitude estimate if the sonar is out of range, causing it to fly away! The parameter EK2_RNG_USE_HGT can be used to make the EKF switch between sonar and barometer as the primary source, but using rangefinder as primary is only really needed if the barometer is not reliable, such as when flying indoors.
Ohkay⌠Didnât know that⌠I had earlier thought it would give priority to rangefinderâs readings⌠Thanks.
I want to use the quad for indoors so barometer wonât be reliable.
So, what parameter changes should be made? I will have to the default value of EK2_RNG_USE_HGT.
USE_HGT is a percentage of MAX_CM, so with these settings, your copter will use sonar as the primary source when it is below 3.5 meters altitude. If it flies above this altitude, it will start using the barometer as primary instead (but will still use sonar data), so that it doesnât go crazy. This is just an example, youâll have to set these parameters to whatever your rangefinder is capable of.
Is it possible to turn off sonar from altitude calculation?
I want to use sonar to give back some data from pixhawk through passthrough telemetry to frsky, and itâs working for me but it give some problems with alt hold in automatic modes, the copter is not hovering is going down or up even if the EK2_ALT_SURCE is set to 0(baro only).
More recently, the ArduPilot team has discouraged the use of the EK2_RNG_USE_HGT parameter because it can potentially lead to a flyaway if the rangefinder gets stuck at a value lower than that threshold. Generally, it is sufficient (and safer) to leave the parameter at -1, and use RNGFND_GAIN to control how strongly the rangefinder reading affects altitude hold.
This one post literally helped me more than any other piece of info forever. I was having some issues with Herelink on my 25+ UAV which I canât get approved yet. Decided to get a smaller sub 2kg drone with the same FC and running gear. Day 1 nuub error with props. Day 2. Had to reverse the pitch on RC. Good solid flight in Stabilise with a bit of drift. Day 3 recalibrated. Stabilise good. Stage 2 Altitude hold not working. Tried Pos hold which worked well but the altitude would decrease when I took power off. Quick search for specifics and found this post. Been looking for a while.
The comment specific to deadzone and 1500 made me think maybe I needed to uncheck Zero Thot and add deadzone from 50% and it worked beautifully
.