Hello everyone. I’m running ArduCopter v4.7.0 in SITL.
First, setting MOT_SPIN_MIN to a value greater than 0.6 after takeoff causes the copter to climb indefinitely.
However, setting MOT_SPIN_MIN=0.6 during waypoint navigation does not affect flight initially, but after reaching the waypoint (wp), the copter still begins to climb.
At this stage, setting MOT_SPIN_MIN=0.15 restores the copter to the normal altitude (the preset height of the wp). But if MOT_SPIN_MIN=0.6 is set again afterward, the copter briefly climbs momentarily before stalling and crashing to the ground.
In summary, there are two distinct bugs with reproduction steps below:
(1) Bug 1 - Indefinite Climb After Takeoff
mode guided , arm throttle, takeoff 30.
param set MOT_SPIN_MIN 0.6
(2) Bug 2 - Post-Waypoint Climb and Crash
takeoff 30
Fly to Waypoint 1 (wp1 can be any arbitrary position)
During flight to wp1:
GUIDED> param set MOT_SPIN_MIN 0.6
After reaching wp1:
GUIDED> param set MOT_SPIN_MIN 0.15
GUIDED> param set MOT_SPIN_MIN 0.6
MOT_SPIN_MIN,0.6 is setting the motor outputs to 60%, normally this is above hover throttle. Climb would be expected.
MOT_SPIN_MIN is for setting the throttle percentage that motors will not go below once armed and flying. This value needs to be low enough for a reasonable descent rate, but not so low that props/motors could be stalled by descent or wind gusts. MOT_SPIN_MIN would not be changed after initial setup and tuning.
There is no bug here. The parameter is being used incorrectly.
Hi @xfacta , ok…I agree with your description of MOT_SPIN_MIN
But I think the second situation is definitely a bug, because the same input(param set MOT_SPIN_MIN 0.6
) causes two completely opposite effects (climbing and stalling). What do you think?
No it’s still not a bug - there’s no scenario where anyone would ever set MOT_SPIN_MIN,0.6 and NOT expect the copter to fly away, unless of course hover throttle is higher than 0.6 (in which case the copter is most unlikely to ever get airborne)
These are parameters that would never be changed in flight, like the Frame Type and a few others - it’s not form in-flight tuning.
The reason you CAN change it is because the size of the firmware would be excessive if checks and limits had to be placed on all parameters. It’s up to the copter builder and tuner to set these things to sane values before first flight and maybe adjust appropriately during test flights.
Thank you, I think I roughly understand what you’re saying. Perhaps we’re talking about different things.
I’m focused on testing, which means I’m more interested in identifying conditions that can cause the drone to become unstable or even crash. From my perspective, any parameter configuration or MAV command that the drone accepts can be considered input, which is how this issue arose.
As you said,
It’s up to the copter builder and tuner to set these things to sane values before first flight and maybe adjust appropriately during test flights.
these parameters can indeed be changed by me during the flight of the drone.
On the other hand, you’re discussing whether such a setting is reasonable. Maybe for someone with professional drone knowledge, it’s indeed unreasonable. But… who knows? There might be situations where this could confuse someone.
So I just want to confirm with you that, regardless of whether the input is reasonable, this does indeed cause the drone to exhibit unexpected behavior (it was supposed to continue climbing but instead stalled and crashed).
Please dont take me the wrong way, I’m glad you brought this up and we can discuss it.
Nearly every parameter can be changed even during flight, which leads to near-infinite possibilities. Only a few parameters are read-only.
As I said we can not check for a valid range for all parameters or the firmware size would blow out to unusable.
Some are actually checked during boot up, and you would see a warning in Messages.
You can make parameters read-only after you’ve done tuning, to prevent end-users from messing up the vehicle. So you could choose to lock down certain parameters, or even set new default values.
The stall and crash could be for some mechanical or electrical reason (unlikely in the Sim). Or it could have disarmed (if armed in Stabilise or Acro) and throttle was at minimum for long enough - there’s other discussions about disarming inflight. Luckily that was just the Sim.
Maybe there is a valid point you are making: there could be a warning or limit placed on setting MOT_SPIN_MIN equal or greater the MOT_THST_HOVER , but to be honest it’s still a very edge-case.
If someone wants to send mavlink commands to change params inflight, they are not a novice or will quickly learn the hard way. most would be scared to do that - just using the normal onscreen actions like “Fly to here” and so on.
Thank you! I’m really happy to discuss this with you as well. I’m using a translator to translate my messages, so the tone might not always come across accurately, haha.
Yes, for Copter, there are over 4,000 configuration parameters and more than 160 MAV control commands, most of which users can modify. This makes unexpected situations possible in some cases. In my view, these different parameters and control commands create a n*n*n*n*... number of possibilities, which are clearly impossible to test exhaustively.
So, what I’m working on is identifying inputs that could affect the normal operation of the drone. I’ve already found quite a lot, including internal errors, SITL no link issues, hit ground, and even drone crashes. I’m wondering—could this type of testing be helpful to you? Could it provide useful insights when designing or improving AP?
Some copters are sensitive to PIDs for example, and even a slight change to some PID value might cause a crash or highly unstable flight - and that’s a parameter that is typically changed inflight for tuning.
I would say all input is welcome, but what can be realistically implemented might be something entirely different.
Yes, I have filtered out cases like this. For example, I found that setting SIM_GPS1_POS_Z too high (e.g., 15) causes the drone to enter LAND mode. This is a protective mechanism, not a bug.
However, when SIM_GPS1_GLTCH_X is set to 10000.0, SITL crashes, and GCS shows “no link” (which is actually an arithmetic exception). Can I consider this an anomaly?
What I want to express is that, just like using try-except in programming, I’m only raising this issue—whether to address it or not is up to the developers.
