Closed geofrancis closed 3 years ago
I changed the issue a bit because:
I think supporting this is worthwhile.
I have used the altitude information for a while now to control the landing gear and not had any issues with it just using the barometric sensor, although it can drift over time the 5m buffer is usually enough to compensate so i wouldn't restrict it to only working with a sonar, since altitude is set to 0 on arming it will have a very accurate measurement from the ground using the barometric sensor alone for retracting the gear and most flights wont last long enough for the baro to drift over 5 meters plus you would still have your auto deploy when entering an automatic landing mode.
since I also have arming information to my taranis from my pixhawk via a teensy telemetry converter it wont retract until machine is armed+altitude is over 5 meters so I could just have it on a 2 position switch for auto and deploy since i know it cant retract until those conditions have been met and I could still manually deploy if i had to.
you dont have to know exactly where the ground is for deploy thats why you just have a parameter for what hight you want it to retract and/or deploy most people fly in flat areas with little variation in altitude with machines that climb and decend slowly so 5m or less would work for them, if you have a machine that decends fast or you have slow landing gear you can just deploy a little higher.
since altitude is set to 0 on arming it will have a very accurate measurement from the ground using the barometric sensor alone
No, it will have a good estimate of the altitude above home, not above the ground.
most people fly in flat areas with little variation in altitude with machines that climb and decend slowly so 5m or less would work for them
That's an assumption that I'm not prepared to make.
Like I said, automatic retract and deploy has been discussed before and the only thing that was accepted as doable and missing is doing deploy when we have a usable rangefinder. In any case, PRs can always be discussed in dev calls so feel free to open one and we can discuss it again.
I think ground speed should also be considered, if copter is doing 40km/h should we deploy on low altitude? So the smooth line between low altitude flying and low altitude i_want_to_land must be found. It will be supercool though
"No, it will have a good estimate of the altitude above home, not above the ground."
yes and unless your taking off from the top of a building home altitude = ground level at point of take off. so its never going to retract the gear unless you go above 5m above home altitude, it will be more accurate with a rangefinder but i have only seen a range finder on an arducopter machine but that was an industrial inspection machine worth thousands.
"Like I said, automatic retract and deploy has been discussed before and the only thing that was accepted as doable and missing is doing deploy when we have a usable rangefinder."
i have used this method on dji a2 and a3 controllers for many years without issue. the main advantage of it is as a lockout so the gear is never retracted accidentally on the ground, damaging the retracts and camera gimbal. I know there is currently a crude lockout in arducopter for when the machine is powered on with the switch in the wrong position but that doesnt help after power up.
Regarding retract: I think that we could do it in automated takeoffs. For all the others, without being aware of the surrounding environment (so only with baro), I think it can be dangerous - I guess we could have it with a parameter turned off by default.
i have used this method on dji a2 and a3 controllers for many years without issue.
That's great, but you aren't our only user :wink:
I know there is currently a crude lockout in arducopter for when the machine is powered on with the switch in the wrong position but that doesnt help after power up
I'm not sure what you mean by this. If you have your switch in auto mode, it only deploys (and in automatic land situations); if you have your switch in retract mode when you power up it will only retract if you change into another mode and then back to retract - that sounds reasonable to me.
I had an auto retract/deploy routine working, and scraped it because to have it work well there's a need to have an hysteresis zone so that when flying "around" the set height the system wouldn't start retracting/deploying continuously. Also the system would have to be aware of the vertical speed, specially when descending because it would have to compensate for the speed of the landing gear itself to deploy completely.
As it is currently is good.
I'll just add my 2cents here.. I think it would be nice to retract the gear after take-off. So if we move from a landed to non-landed state and the altitude (above EKF origin) has climbed by X meters and the pilot hasn't touched the landing gear auxiliar switch.., retract. a simpler method might be at the completion of a take-off command (in AUTO).
@lvale i didnt use a hysteresis zone just a short time delay before starting deployment when i was using opentx and the system does not need to know vertical speed you just need to know the max decent speed allowed in althold and retract deploy time + hysteresis time buffer and you can work out what is the minimum altitude that you can deploy at while descending at maximum speed not including the time needed for deceleration.
0.5 second buffer and gear deploy time of 3 seconds with a default max decent speed of 2.5m/s gives 8.75m
so even if you descended at maximum speed into the ground without slowing down your gear would have deployed before impact as long as you were over 9 meters above the ground, if you set it to 15 or 20m meters default then that would give a very wide margin for error for even the slowest landing gear and baro drift.
with a range finder this altitude could be reduced closer to the 9-10m range since you would have much more accurate information on where the ground is.
there is already a landing gear function in arducopter what about just making it a 3 position with the middle being auto.
that way you can have it work manually like it does just now by having a 2 position switch or 3 position for up auto and down but i would probably use it with a 2 position as auto and deploy so that it cannot be retracted on the ground.
@geofrancis :) My first approach was also using a script on the Taranis (I have telemetry data-height) that implemented a simple method like yours (time delay between retract/deploy if height variation less than x%). Second was fiddling around on the Landing Gear on the Copter source. This required creating 2 new parameters, desired LGR height and LGR time to deploy (mine take from 3 seconds to 30 seconds depending on the LGR model). Anyway the manual override of the automation must always be enabled. It's not the first time that I had to choose to do a belly landing :) or wanting to fly "below" the LGR auto height with the LGR retracted :)
note: The Auto/Middle is already working and deploys the LGR automatically on the last Land stage (which also includes RTL) https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_LandingGear/AP_LandingGear.h#L12
Hello. I am attempting to set up my 450’s landing gear to retract and deploy using logical switches based on altitude. I can’t figure out the logical switches. Would someone please walk me thru it?
Issue details
having the landing gear retract based on altitude would let it work fully automatically, i have used this function on dji a2 controller and it worked well and managed to replicate it on my taranis using the altitude information and logical switches in opentx.
i have a 3 position switch for my landing gear now, up, auto and down, when in auto it will raise the gear when it reaches 5m altitude and lower it when it goes back below 5m.
this works ok but not for long auto missions where it might go out of range of the handset, because its controlled by the handset i had to set the failsafe to lower the gear incase of handset failure i didnt want it to rtl with the gear up.
if the flight controller could manage this then it would remove the handset dependancy.
Version
all
Platform
[ ] All [ ] AntennaTracker [x] Copter [x] Plane [ ] Rover
Airframe type
all
Hardware type
pixhawk
Logs
na