Hello, for thos uses landing gear controller, there’s an issue due to PWM output during pixhawk startup that make thoses controller unusable.
for example
If LGR_SERVO_RTRACT set to 2000 and LGR_SERVO_DEPLOY set to 1000, during startup pixhawk output 1500pwm on LGR Port and after less than a seconds put LGR_SERVO_DEPLOY VALUE.
This lead to many LGR Controllers to force deployed lgr to redeploy, and cause behavior that makes impossible to retract lgr.
FYI:
Many LGR Controlers are based on current spike detection for determine limit switch deploy or retract.
If at startup DEPLOY value is directly sent to LGR Controler, it not drive the motors for deploy the LGR’s.
Could you please make sur that first PWM generated on LGR Port during startup is LGR Deploy value?
I’ve recently had a couple of landing gear motors burn out, and from what I can tell it’s because the controllers use current sensing to determine if endpoints have been reached (motor stalled) and every time I power up the copter the landing gear tries to deploy even though it’s already deployed, stressing the motors. (FYI I’m still running AC3.4.6 on this rig, not sure if landing gear logic has changed in AC3.5)
I know this is an issue with the design of my landing gear rather than with Arducopter, but I would love to see a configurable option to ensure that there is no PWM signal at all from the landing gear output until the assigned RC input channel changes for the first time. This would help ensure that the motors never run unless specifically commanded to do so.
I would see this working with at least two different landing gear startup PWM options:
0: Use LGR_SERVO_DEPLOY value
1: Use LGR_SERVO_RTRACT value (not sure why anybody might want this)
2: No pulses
I was trying to reproduce this issue today on my Pixhawk1 using a log analyser but I’m not having any luck. That doesn’t mean that there’s no problem of course, just that I can’t reproduce it.
From what I can see there’s a bit of garbage that appears soon after startup if AUX1 (aka output channel 9) is used and then about 10 seconds later the output appears as 1750 (the deploy value in my setup). 1500 isn’t output during my test anyway.
The garbage is a full 10 seconds before the real output appears though and it’s very quick changes so I wouldn’t have thought that most servos are confused by this. If I use MAIN OUT 8 (aka output channel 8) then I don’t see the garbage on startup.
If you could perhaps set LOG_DISARM to 1 and produce a dataflash log that might be good. I’d like to know if the board has a safety switch attached and which output is being used for the landing gear.
I’ve got a change which I hope will do what people want. It now doesn’t output any pulses until the pilot moves the transmitter’s auxiliary switch which has been setup to control the landing gear. I think this means that servos will stay relaxed (or in their current position) until the pilot moves the switch.
Now, I hope this isn’t problematic for users who may instead always want the gear to move to a predefined position on startup (i.e. startup deployed or startup retracted). If this is the case then I think we will need to add a new parameter called LGR_DEFAULT or LGR_STARTUP to allow the user to configure it’s intial state.
Could some/all of the people here give this change a try?
II will test it and report asap. I think that no pulse until pilot move switch is the best solution for all, maybe if one user need to have pulse, you will add the LGR-STARTUP parameter.
I couldn’t test this patch with my copter / landing gear as it’s an X8, so I’ve flashed a spare pixhawk and hooked it up to an oscilloscope.
I tested behaviour with the assigned RC input switch in all three positions at startup, and can confirm the patch works as expected, with PWM signal only seen after the RC input changes.
I’m sure I’ve read somewhere here other people wanting the gear to automatically deploy as soon as power is applied, so LGR_STARTUP parameter will likely be necessary.
One thing I’ve noticed (and can’t confirm if it was like this before) is that all the outputs on the pixhawk jump to 3.3v momentarily (no PWM, just a short blip) after power is applied. I will flash unpatched firmware to confirm later today.
The ‘garbage’ your seeing @rmackay9 is a single pulse around 110ms long, and appears on every servo output (including motor outputs) immediately after the board is powered up.
It’s there in all versions I’ve tried (Pixhawk 1 with AC3.4.6, 3.5 RC7 and 3.5RC7 with the no-pulses patch)
This is the output of Aux 9 at startup showing pulse immediately after power on, followed by normal PWM after about 10s
I’m not sure if this is going to trigger any unwanted response from connected devices as presumably the pulse length is far too long to be treated as PWM.
Just put the 3.5.0 release on my hexacopter. I’m running 2x Tarot ‘small’ landing gear retracts, where the gear is down (deployed) upon powering up the copter (so 1000pwm being sent to the retracts), and retracted when I flick a switch (at 2000pwm). Wirth the release version of 3.5 I am now seeing strange behaviour. When I launch (with gear down (1000pwm) I flick the switch to retract, but nothing happens. I then flick to deploy, and flick a second time to retract and the retracts work perfectly from this point onward. I imagine this has something to do with the latest landing gear changes in the code.
Mine does the same and noticed this since I started using the 3.5 release candidates. Don’t remember which one it started on, but I also assumed that it was due to the landing gear changes made in 3.5. I do like it better than the switch accidentally being in the wrong place on the ground and the retracts try to cycle as it is now a definite double flip of the switch to activate. Once activated, it works fine though.
It should trigger the landing gear to move on the first move of the switch. The problem could just be that if the transmitter switch is already in the deploy position at startup that won’t be sent until the switch is moved… so the pilot would need to move the switch to retract and then deploy again. I think if the transmitter was powered on with the switch in the retract position then the first move of the switch to deploy would make it deploy.
Anyway, sounds like, as expected, we should have a parameter to decide what to do on startup. I.e. deploy, retract or wait-for-pilot-to-move-switch.
I’m a little late in the game here, but I’m curious as to which landing gear systems are having this problem.
I have two Tarot multirotor aircraft with Pixhawk flight controllers. I have used these flight controllers with various AC3.5 release candidates. Both are now using AC3.5.0
One aircraft is a 680 Pro with Tarot TL65B44 “Small” landing gear. The other aircraft is a stretched Tarot 650 Sport with TL65S04 landing gear and a TL8X002 controller.
To date I have had no landing gear issues with either aircraft…
Mine is also using the Tarot ‘Small’ TL65B43 retracts, and Powering/Launching with these deployed (1000pwm), the retract only happens on the second operation of the switch (so flick high pwm/2000, low/1000, and high/2000 again).
Its only ‘normal’ this way since 3.5 - before 3.5 it worked differently - what I would consider normal. I simply want to be able to power up my craft with the gear deployed and flick a switch to retract it. Don’t want to have to flick it 3 times to get it to retract - how is this a good idea?
It’s a good idea because Pixhawk is controlling the gear. You can always go back to direct receiver control, but you loose automatic deployment when Pixhawk goes into Land Mode…
