yes, this same model, same code, but in normal conditions - not upside down with props on the ground. it was bouncing up and down with props revving - i was afraid it will go on fire as motors almost melted. odd stuff.
here - what i hate most - see how ch8 is hit, current then goes down and again goes up? how is it possible?
i did not notice any alteration of sound or bouncing when ch8 was hit. but graph shows current tried to go down - but merely down to 20A from 66A? Odd.
plus, the fact it pumped out 66A while laying on the ground upside down trying to rip through - also odd.
I tried to reproduce it on my tiny copter and everything worked as it should.
I held it in my hand. Put it in alt_hold. Put the throttle over mid, and the motors spooled up. I turned it over and hit the motor stop switch, and they stopped.
But, my turnover was relatively gentle and didn’t trigger a crash detection or anything. Maybe that’s a factor in your case.
I’m running master from about 2 weeks ago.
thx for trying - not sure what happened in my case. i will try to torture it a bit more later, with props off. too bad nothing is clear from that log. if it was a hardware issue i would love to know what it was…
i can only imagine that cpu ran out of limits somehow and started ignoring RCIN while giving all cycles to gyro loop? but i do not think it is how it works. plus it shows CH8 RCIN - but does not show current cut off. go figure.
Hi, i have a code built from current dev master but i suspect in this area it is same as code from rc10.
https://drive.google.com/file/d/1lzttgf3t8C2GmslaU043Ewz9LXkQpxbp/view?usp=sharing
I can’t find the git hash corresponding to the firmare you’re running,
1e3310c0
This does appear to work OK in sim in master, and I tested master a couple
of weeks ago on my 250.
the scenario that just happened - a model was attempted to liftoff in the alt hold mode. for reasons not relevant - operator error most likely, or
hardware - it flipped over propellers on the floor. immediately after that ch8 was hit - with a function 31 to kill motors.
Your log drops out with just a single value from Ch8 - you don’t have
log-disarmed set - it is possible the vehicle actually detected a crash
and we have a problem with killing motor outputs somehow. Do you have a
telemetry log corresponding to this flight?
model ignored that, motors kept spinning wildly, it gave up to 80A at some point trying to spin them, fried motors a bit as it smelled - all this time ch8
wsa on, ignored, so i had to throw a rug on props, step on it and unplug lipo.it does not sound as something that was supposed to happen, i would guess?
I’d call it sub-optimal.
sorry, there is no telemetry log.
what controls a delay between arrival of a code 31 on the CH8 to kill motors and a factual stop command to a motor? i tried it several times and there is definitely a delay, a half sec or so to my perception between me hitting the switch and motors factually stopping. looking at log it also seems to be so - why RCOU does not go to idle immediately upon receiving RCIN on CH8?
or a better sample here - it took motors from 21.2 to 21.8 to stop spinning, as command was given at 21.1?
is code doing something else at that time? and at time of crash it can ignore this CH8 input completely?
there was an issue earlier with dshot spinning motors in disarmed state that was fixed - but, can it mean there are more safeguards needed to control what it does in disarmed state?
Hello,
Looking at RCIN C8, I would say there is a delay (servo speed) programmed in the RC Transmitter.
Marc
there is nothing set in the mixer on taranis for ch 8, if that was what you meant. why would it be set there for a kill switch to begin with?
The kill switch delay is present on mine as well.
I’m pretty sure I’m not imagining that the delay has changed over the years, w/ version changes. (or maybe i’m getting it mixed up w/ other software, px4, betaflight, etc… still I’m fairly sure it’s changed in ardu…)
May be, but apparent change of state (from 1000 to 2000) is quite long (0,23sec). Could be shorter (I have 0,07sec while looking my camera trigger log).
Marc
You are not seeing the reality, it is distorted by the update rate of the log. Graph simply extrapolate the values between two log entries.
The real delay for Emergency motor stop is 400mS (THROTTLE_ZERO_DEBOUNCE_TIME_MS), and it is hardcoded.
Was there any specific reason for any delay at all to be used for a kill switch? 100A at motors can do a bit of damage in 400ms.can it be set to 10 or 20mS?
I found the reason for the strange current behavior. It’s just trying to correct the sudden deviation from the desired roll attitude, so the current goes up. Your copter can’t follow, I guess because of the ground contact, so the power is increased until it flips over. Then it suddenly is free and reduces power, but of course overshoots. That’s why your current goes up again in the end.
But the interesting question is why there is this sudden roll deviation in the first place. The controller isn’t commanding it. Could it be something like a loosened prop, ESC failure etc.?
As it’s name says debouncing, to eliminate false actions from intermittent signals. With a good reliable RC system, it perhaps could be lower. But there are many users who uses AC with shitty transmitters, ratnest cabling and all other nightmares, so I see the reasoning behind a 400ms debouncing.
BTW can we move this discussion to separated thread ? Since it has nothing to do with 3.6RC10 ?
no slightest idea. there no issue with hardware on this model i could find - but i had an another flight and i saw it having issues with roll stability in the air that is self corrects. it is a small model and something is not quite right.
if you know what to look - you could see those stability issues in this log - i cannot identify the source.
https://drive.google.com/file/d/18Qae1tJZ5KVCGeJ-Z-WhMnGzbAJk-3tY/view?usp=sharing
I looked at your roll attitude data. There are super high (± 180 deg) spikes in it. That can’t be true I guess, right?
So where could this result from? I guess high vibration levels. Your acceleration values along the z axis seem pretty high to me.
And your roll problem always occurs when there is another AccZ peak.
So it seems that’s what caused your crash.
By the way: You’ve got an “Err: FAILSAFE_BATT-1” in your log. Have you seen it?
that is a different log, log of a normal flight with no crash, sorry, i was not specific enough. i have had rolls in that flight that were in my pinion similar to the crash that occurred in the log i posted initially. but during this flight model was high enough so it would self level after those rolls.
it is way too confusing, sorry about that. al flights were under 60m or so - only in stab mode i made it go pretty high and altitude in this cases should correlate with previous current drawn to see that it indeed shot up.
T650 Crash
Hi I need help with log
I upgrade my t650 to 3.6-rc10.
I looks good but when I try yaw copter just fell down…
2018-09-22 17-29-30.bin (609.4 KB)