ArduPilot / ardupilot

ArduPlane, ArduCopter, ArduRover, ArduSub source
http://ardupilot.org/
GNU General Public License v3.0
10.92k stars 17.42k forks source link

Copter should not arm if ESC's are not ready when using OneShot #5667

Closed andyp1per closed 7 years ago

andyp1per commented 7 years ago

Issue details

When arming with OneShot or OneShot 125 there can be significant delay in the ESC's being ready but the copter will still arm. Ideally the copter should not be allowed to arm unless the ESC's are armable. So for instance there can be a 30s delay between each of the ESC's arming. It's difficult to tell whether they are all in a ready state without arming - IMO the copter should refuse to arm until they are ready. No idea whether you can tell this from the ESC!

Version

3.4.4

Platform

[ ] All [ ] AntennaTracker [ X ] Copter [ ] Plane [ ] Rover

Airframe type

X4

Hardware type

AUAV-X2, BLHeli 14.9, RG 20A

Logs

rmackay9 commented 7 years ago

Yes, I think we don't have any feedback from the ESCs so I don't think we have a way to know if they're armed or not. It would be nice to know why they're not arming though. I suspect the reason is that the pwm value we are sending them when disarmed is slightly too high. Can you tell me what your RC3_MIN parameter is?

OXINARF commented 7 years ago

@rmackay9 Why do you have that suspicion? @lvale in his tests found a workaround that looks like that may exactly be the cause: he calibrated ESC with a value above the MOT_PWM_MIN and that way it worked.

rmackay9 commented 7 years ago

@OXINARF, my understanding is that the OneShot ESCs have a fixed pwm range that they accept but in our oneshot handling code we don't use a fixed range but instead use the RC3_MIN ~ RC3_MAX divided by 8. This is the same thing if the RC3_MIN is 1000, RC3_MAX is 2000 but I think we should instead consider using the known fixed range if OneShot ESCs are selected. This is all a bit of guesswork because I don't have OneShot ESCs but I could get some if someone's got a link. I'm sure @tridge or @lvale could tell me which ones to buy.

andyp1per commented 7 years ago

RC3_MIN - 1097 RC3_MAX - 1901 The ESCs have: MIN PWM - 1120 MAX PWM - 1908 I know this because I connected to each one to verify and made them all the same. Interestingly the ESC that arms first has the same values as the one that arms last. I'm happy to play around with different values and report back if you can suggest things to try.

rmackay9 commented 7 years ago

I'm guessing but how about setting these parameter values in Copter to make it match the ESCs: MOT_PWM_MIN 1120 MOT_PWM_MAX 1908 In particular it's the MOT_PWM_MIN that likely matters.

it's also possible that MOT_SPIN_ARM value is important. by default it's 0.1 but perhaps it needs to be a little lower (0.08) or a little higher (0.12).

I'm really guessing though.. I don't think I've seen a video of what the problem looks like.. or anything really.

@lvale probably understands best.

andyp1per commented 7 years ago

Ok, will try tonite. Will also try and produce a video. I'm surprised that the ESC calibration came up with different values for MIN/MAX from the RC calibration. I will try recalibrating the RC and see if that helps.

andyp1per commented 7 years ago

BLHeli also has a "disable PWM input" setting. This is doc'ed as preventing going into programming mode, but some stuff I have read makes me think it might affect oneshot arming as well. So I will try this also.

geofrancis commented 7 years ago

PWM input is only for converting brushed machines to brushless, it means raw PWM not servo pwm, i think your talking about the disable stick programming checkbox at the top of blheli config program.

my escs are doing the same with oneshot enabled, but normally if i power cycle it they all arm instantly. with oneshot disabled i was getting twitching on motor output 1, it was definately the motor output because i swapped the signal wire with another esc on the quad then it started twitching but that went away when i enabled oneshot.

for monitoring the escs this looks promising but im not sure how far away it is or if it will work with more than one motor but its something to watch for the future: https://www.rcgroups.com/forums/showthread.php?1907690-BLHeli-serial-monitor

the kiss escs with their integrated telemetry and current sensor are interesting but i have seen too many blow up to put them on my stuff, but its only a matter of time before the esc telemetry is mainstream then all sorts of failsafes could be done if you knew the exact status, current and rpm of each motor.

lvale commented 7 years ago

I have the video of my fight with the ESC's here:

https://www.youtube.com/watch?v=w5QLcQU7Xro

geofrancis commented 7 years ago

@lvale thats the twitching im getting on my hex with oneshot disabled, it stops as soon as i enable it.

i rememebr reading somewhere that you shouldnt calibrate it with one shot enabled.

andyp1per commented 7 years ago

Setting MOTPWM* has no effect. My video of the delay: https://youtu.be/qqd_WOu1Nnw

geofrancis commented 7 years ago

as soon as you hear the first esc initialise disconnect your battery and power up again and they might all initialise at the same time, or atleast they do on my hex with littlebee 20a escs.

andyp1per commented 7 years ago

Ok, I tried modifying just one ESC. Tried the following, in this order:

ESC1 MIN-MAX == RC3 MIN-MAX (1097, 1901) ESC1 MIN-MAX == default (1148, 1832) MOT_PWM_MIN-MAX == (1148, 1832) MOT_SPIN_ARMED == 0.08 MOT_SPIN_ARMED == 0.12 MOT_SPIN_ARMED == 0.00 MOT_PWM_MIN-MAX == (0, 0)

Just when I thought I was getting somewhere I would try it again and get random results. I really believe that these settings are having no effect on the oneshot arming and that there is something else going on. It feels like its affected by when you press the button and when the copter is ready to arm - i.e. if you catch the loop at the wrong time it takes a long time, even then it seems pretty close to random. I already have PWM input disabled on the ESC's so that's not it.

andyp1per commented 7 years ago

My only other input is that if I calibrate the ESC's and then try arming, they all arm immediately. If I power off and leave it for a while I am back to square one.

geofrancis commented 7 years ago

does the RC_SPEED make any difference? i think its default at 490, what about lowering it to see if it syncs faster.

andyp1per commented 7 years ago

Doesn't that depend on the ESC? Also isn't that only relevant if you are not using OneShot?

geofrancis commented 7 years ago

https://github.com/ArduPilot/ardupilot/issues/1825 one shot is based off pwm speed o the ESC speed is 1000Hz, The test results were:

RC_SPEED = 50 = No motor drop-outs but "skitty behaviour" (1/20th ESC speed). RC_SPEED = 100 = Still a bit skitty (1/10th ESC speed). RC_SPEED = 150 = Drop-outs worse (misaligned with ESC speed). RC_SPEED = 200 = Smoother but occasional drop-out (1/5th ESC speed). RC_SPEED = 250 = Perfect, rock solid, responds well (1/4 ESC speed). And of course the default RC_SPEED is completely misaligned with the ESC speed.

rmackay9 commented 7 years ago

@andyp1per, that sounds very much like the ESCs are not saving their calibration... so that wouldn't be an ardupilot issue in that case. a workaround would be to try and figure out what the min/max values the ESC accepts (before calibration) and then set MOT_PWM_MIN/MAX appropriately..

andyp1per commented 7 years ago

@rmackay9 it definitely is saving it's calibration as I am using BLHeli suite to set the values on the ESC's and when I reconnect/reboot they are set to the correct values.

andyp1per commented 7 years ago

@geofrancis the ESC speed for RG20A is not documented so not sure how I would pick the correct value!

andyp1per commented 7 years ago

@geofrancis the RG20A is based on the F330 which processes at 25MHz, it seems this processor is good up to 2Khz refresh, so I'm not sure why 490Hz RC_SPEED should be a problem? But I will try 250 tonite to verify.

andyp1per commented 7 years ago

Something very strange going on here. So I set RC_SPEED to 250 and tried safety switch - maybe a bit quicker to be ready but not convincing. With the battery still connected and safety switch on, but the copter not armed, I changed MOT_PWM_MIN-MAX to (1120,1908) and the propellers started spinning. This is without the copter being armed. I then had to gingerly disconnect the battery with the props still spinning as this was the only way of stopping them. I then cycled the power, pressed the safety switch and I got the low tone but not the high tone from the ESCs. They refused to fully arm despite me waiting for a long time. With the battery still connected I then set MOT_PWM_MIN-MAX back to zero and got the high tone. Cycled the power, tried again and they were ready to arm within seconds with the safety switch pressed. So RC_SPEED definitely has an effect, but I am struggling to articulate exactly what that is.

geofrancis commented 7 years ago

you should test with props off.

andyp1per commented 7 years ago

Of course you are right, but the risks are fairly low.

andyp1per commented 7 years ago

@geofrancis the part you are quoting from #1825 is before oneshot was implemented and for a user who was experiencing filtering related wobbles. However, that got me thinking - what exactly determines the cycle time here - is it RC_SPEED? If so then we should go higher rather than lower, so for instance a cycle time of 1Kz seems fairly common so RC_SPEED = 1000? @rmackay9 is this right? I tried RC_SPEED values of 500, 1000 and 2000. Maybe the ESC's were ready a little earlier on the higher values, but nothing definitive. The motors would arm eventually and spin at all values. One more observation - if I push the safety switch before the ready-to-arm ta-da-da the ESC's all arm almost immediately together and reproducibly. If I push the safety switch after the ta-da-da then the usual delay ensues.

geofrancis commented 7 years ago

i disabled the arming switch to get all mine to mostly arm at the same time.

andyp1per commented 7 years ago

The need for this goes away with 1bfbf0d fc675a1 032bfad fixed in 3.5rc5 I think this can therefore be closed