Hi,
Using ver. 4.6.3 and using an aux switch (ch8) to arm/disarm, I have noticed following problem:
After starting rover all is as expected. Then disarming is also fine.
However, any subsequent attempt to arm again will not provide any signal output. Yet ground station will show “Armed” and everything, including LED’s show all fine and armed.
Only way to get signal output again from FC is to reboot system.
FC is a Pixhawk 6C mini
Hi @Karl_S,
The issue may be with the ESCs on the vehicle rather than with ArduPilot.
It might be good to look at the RCOU messages in the AP logs (after setting LOG_DISARMED = 1) or to attach a servo to the throttle output so that you can physically see how it moves.
@rmackay9 Will have a look at the RCOU messages.
The odd thing is that steering doesn’t work either.
It is not a regular drone ESC requiring a pulse signal to “stay alive”. This one will activate anytime a pwm signal is provided.
…..I may have to go through the safety settings again, perhaps somethoing triggers the motor safety when disarming. But would have expected steering to work at least.
Ok, …have to wonder if it is linked to the angle the vehicle is in at the time of second armimg.
I use it on a steep hill side, and just had a problem with a mission and one particular waypoint, at which I have a 30 second hold position set. Yet every time it reaches that waypoint I get a “Mission aborted. Crash detected.” popup.
Anyway, here is one log which relates to the arming issue.
Your log only shows “MANUAL” mode. But you said this happens during a mission which I assume must be “AUTO” mode.
If I understand the wiki correct in “AUTO” mode a chrash detection is possible
But this also can be disabled by FS_CRASH_CHECK = 0. In your case it is set to 2
Maybe its a try
Thanks for your reply.
The .bin file is in regard to the odd arming issue I am having.
You are correct the other issue happens in AUTO mode. But here is the thing:
I would like to keep the crash check active and I would have expected if you use a WP with a Hold delay set ( like I have done in WP2), that any crash check will be disabled automatically as the stopping is intentional. –> Yet in doing so all 4 elements of the crash check are achieved and this will trigger the auto crash detection.
@rmackay9 Isn’t such an arrangement rendering the WP Hold setting useless for AUTO missions in a rover?
….but to extend on this a bit further,….if I set CRASH_ANGLE to ….let’s say 40°, then is it possible to run a mission with a WP and HOLD successfully without triggering the crash detection, providing vehicle doesn’t exceed the 40° ?
If that is the case, then the crash detection would useless below 40° ?
So I can have one or the other, but not both?
Thanks
Hi @Karl_S,
Thanks for the log, I had a look but I don’t see the Crash check being triggered. If you have a log of that I’m happy to look into it further. I can imagine that we have an issue because it is quite old code. I’m not even sure that triggering the crash check when the vehicle is stuck is the correct behaviour.
In my quick SITL test though, setting a waypoint command with a delay did not cause the crash check to trigger
Turns out I uploaded the wrong .bin file.
Anyway, rather than trying a soon to be outdated version, I’ve decided to upgrade to the 4.7.0 beta version.
–> Unfortunately same thing on both issues.
I will now submit new logs in that category.
Keep the logs in this topic. We can move it if needed.
Well,….already reported one on Github.
Here is the log in regard to crash indication when reching a WP with Hold function set:
Here is the log in relation to the arm/disarm issue:
OK. –> Resolved the arming issue:
Had previously a GPS unit with safety button. So it obviously was configured accordingly.
However, recently changed to Ublox F9P, which hasn’t a safety switch.
So I’ve changed BRD_SAFETY_DEFLT=0
One would think this will turn off all safety switch related functions.
But as it turns out, because BRD_SAFETYOPTION was set to “15” it refused to arm when trying to arm again after initially arming after starting FC.
Solution: Setting BRD_SAFETYOPTION=0
@rmackay9 Shouldn’t that setting be ignored if BRD_SAFETY_DEFLT=0 ?
…..I have observed this behaviour in v.4.6.3 and 4.7.0 beta
Hi @Karl_S,
Great that you figured it out and thanks for the feedback.
I’ll check with the other devs re what they think about this. I can imagine some might think this is the correct behaviour because the BRD_SAFETY_DEFLT parameter doesn’t actually disable the safety button, it just sets its initial state. On the other hand, we don’t want to make the system difficult to use and safety buttons are out-of-fashion these days. Hardly any GPSs have them anymore
Txs again.
Perhaps the documents may have to be slightly changed then. As with current description it appears that BRD_SAFETY_DEFLT= 0 will disable all safety switch related settings.
“BRD_SAFETY_DEFLT = 0 to disable the switch for systems not equipped.(BRD_SAFETYENABLE in older firmware versions)”