Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Best implementation for e-stop functionality? #347

Unanswered
amarburg asked this question in Q&A
Discussion options

Our desired use case: Connect a joystick button to an "e-stop" functionality which stops all thrusters.

I am sufficiently muddled on the lower-levels of the stack (ROS Control -> Mavros -> Ardupilot) that I don't know where the most "reliable and bulletproof" e-stop mechanism should be placed.

Just to clarify my thinking: On the BlueROV, does Ardupilot respect "armed/disarmed" even when sending to /mavros/rc/override? In Gazebo it does not appear to respect this switch.

If "armed/disarmed" is functional (e.g. "disarm"ing through Mavros, QGC, etc will instantly stop the thrusters), then that's the preferred mechanism. Would be nice if it worked in sim, tho.

If not (if override sends commands to the RC motors regardless of ardupilot armed/disarmed) is there an alternative?

You must be logged in to vote

Replies: 2 comments

Comment options

amarburg
Nov 20, 2024
Maintainer Author

You must be logged in to vote
0 replies
Comment options

This is something that I don't have a good answer to.

Right now, the solution depends on your desired control approach. If you decide to use the thruster_hardware ros2_control interface to perform thruster-level control via MAVROS, that interface sets the thrusters to the RCPassThru mode in which all ArduPilot safety checks are disabled for those interfaces, including the arm/disarm feature. Additionally, when using the ArduPilot RCPassThru interface, PWM commands will persist. That is to say that, should you stop sending commands, the thrusters will continue to execute the previous command. If you are using the ArduSub control interfaces, without modifying the the SERVOn_FUNCTION parameters, then the normal arm/disarm functionality should work.

To abort the thruster-level control interface, you first need to stop all commands to that thruster, then send a neutral PWM value to bring the thruster to a stop. In practice, this worked fine. However, I am not fond of the extra step (i.e., sending the neutral PWM value), particularly if there is any unexpected latency in delivering the message.

Resources:

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet

AltStyle によって変換されたページ (->オリジナル) /