Rover: Safety Switch Rework

[NickNunno]

Feature request

Problem AP safety button logic was primary designed around copters which have many specific caveats.

Unlike copters, rover should have a means to support inexpensive, industry std Emergency-Stop buttons. These switches are purpose built and typically come with two individual circuit breakers that can be setup NO/NC. When pressed, they lock in position and must be axially turned in order to safely resume the default state. (Available with/without keyed locks)

1. Not all rovers have electric drives which are trivial to disable.
2. If you do have a drive, and disable it without AP knowing about it, the integrators build up and if the user enables before the vehicle happens to crash check, this is dangerous.
3. A sufficiently short crash check to mitigate #2 will result in false positives during operation.
4. Rovers tend to be larger, leading to longer wire runs to switch locations
5. Std E-stop buttons are not momentary so dont work with the current logic
6. The log 5 second or so timer is not appropriate for use with rovers.

Describe the solution you'd like Modify safety code so that:

1. I/O processor monitors two pins, one normally high, the other normally low. This helps sanity check Enable/Disable state.
2. Remove timer or lower it to an order of ms.
3. Wen disabled, I/O processor instantly kills channel output and tells FMU we're in a safety state.
4. FMU disarms and/or puts vehicle in hold etc.
5. When in safety state, FMU can not reset I/O processor state. This can only be done by the I/O processor when the pins return to enable state.

Describe alternatives you've considered

1. There are mechanical work arounds but to do this correctly, AP must be in the loop.
2. Not all vehicles have simple electric drives.
3. Its not always safe/possible to kill power to the autopilot or other hardware systems.
4. Some vehicles, like those with combustion engines, and/or with ackermann steering, hydraulic systems etc should stay online during safety state.

Platform [ ] All [ ] AntennaTracker [ ] Copter [ ] Plane [x] Rover [ ] Submarine

Failure Modes The proposed solution is not perfect but I believe it to be a substantial improvement to the current scheme which really isn't useful for ground vehicles.

The first failure mode would be the E-Stop wiring/button. This is inherent in all systems. high/low sync should mitigate most physical issues.

Second failure mode would be the I/O Processor which kills pin output. If this fails, we have a problem but I think its reasonable to trust?

Third failure mode would be I/O processor failing to communicate with FMU about the current state or FMU lock up. This scenario would be nothing but a fallback to where we are today where an eventual crash check will change modes.

[nlgilbert]

Hey @NickNunno! I'm also looking to add to Rover's E-stop functionality. Here's a description of my desired functionality:

• Accommodates up to 10 E-stops in the system - could include remote E-stops
• Feedback to the GCS for which e-stop pressed - prominent display to operator within MissionPlanner's Flight Data screen
• GCS: Physical E-stop "red button" switch (either on tablet remote or desktop stand-alone panel interface)
• Vehicle: Physical E-stop "red button" switch, panel-mounted
• Function - any E-stop pressed stops all motion which includes drive motors and peripherals which pauses the mission (engine still running). Once E-stop is cleared, mission is still paused until resumed by GCS operator.

I'm new to ArduPilot development, but I'm moderately familiar with the codebase. I was planning on adding a new sensor library AP_EmergencyStop to handle multiple E-stop buttons, basing it on the analog implementation from AP_RangeFinder. In fact, I have an existing solution which hi-jacks the the AP_RangeFinder analog implementation, but it's more of a hack than a solution and doesn't give feedback to the GCS.

What are your thoughts on the features listed above and general approach to implementing them? Do you think our interests are aligned, or should these be two separate feature requests?

[tridge]

can we put this logic in a script, with access to AP_Button?

[tridge]

1. I/O processor monitors two pins

which pins?

[tridge]

5\. When in safety state, FMU can not reset I/O processor state.

this is very hard to guarantee, as for example FMU needs to be able to reset the IOMCU to load a new firmware

[rmackay9]

I think there are three actions:

• Decide which pins we can use for the external switch to tell AP that the motors have been stopped
• Extend AP_Button so that it can read the input from the pins to set the internal armed/disarmed state
• Ensure that we don't get integrator build-up in the throttle and steering controllers when the vehicle is armed/disarmed (i'm pretty sure we don't get integrator build-up).

[rmackay9]

More discussion on this from the Partners meeting:

• we could use two of the FMU's PWM input ports
• the user could specify the ports by setting SERVOx_FUNCTION to two new options, (maybe "SafetySwitchHigh" and "SafetySwitchLow")
• when set to the above options they would be changed from PWM output to be general purpose I/O ports and one would be pulled high, the other low
• we would expect the external switch to change the voltage to these pins when the vehicle is armed (I think).

[NickNunno]

Hello Gents!

I was able to do some testing today to ensure we can reasonably expect the hardware side to work with the PWM method.

• Black Cube, R/C PWM 1000-2000 through 16awg wire will start to show some ring at 25':

At 12.5' of 16awg I see zero signal distortion. (Did not check between these lengths)

In an attempt to introduce some noise on the wire, I ran the 12.5' length through a coil being fed +/-5v sine wave and ran it up/down the full frequency range. I was unable to produce any noise to speak of, let alone noise that would cause issue's with the proposed state sensing logic.

• Pin Config - Use SERVOx_FUNCTION to assign input/output pins.
• Sense logic:
  • Output pin sends constant 2000 PWM.
  • Sensing pin expects to see 1500-2000. (dead band for good measure)
  • If signal drops below 1500 for >100ms, we trigger user defined action.
  • Ensure we freeze all integrators in this state.
• User defined actions:
  • Change to mode X
  • Arm/Disarm
• User Defined PWM actions: (Perhaps redundant?)
  • Do nothing
  • Inhibit PWM out for Throttle only
  • Inhibit PWM out for Throttle + Steering
  • Inhibit all PWM output
• Condition Override - Allow/disallow GCS to override condition. (Hmm, not sure on this one?)

@rmackay9 @tridge what do you guys think?

[nlgilbert]

Hey guys! I commented earlier about a different approach I was taking toward Rover E-stop, and then I made a separate issue #14087 for it. I didn't hear back from anyone so I went ahead and implemented my version. The functionality might be slightly different than what's being discussed here, but it seems to achieve the same effect.

My implementation involves a new library AP_EmeregencyStop, which could support up to 8 E-stop buttons (9 if you include the RC function). It currently only has one driver: AP_EmergencyStop_GPIO, which uses the FMU pins in a NO/NC configuration. More drivers could be developed for other types of E-stops though (i.e. a remote e-stop located at the GCS).

Would you guys like me to make a PR so you can consider my implementation? I'm just trying to avoid unnecessary development of a feature that I already have implemented!

[tridge]

Accommodates up to 10 E-stops in the system - could include remote E-stops

wow! can you explain a bit more about the hw you're on?

[NickNunno]

@nlgilbert sounds interesting!

Would be great to find out more info or see a PR, whether here or on your ticket.

I do feel its extremely important for this to be a digital signal rather than analog NO/NC as its far too easy to have an electrical failure.

[nlgilbert]

After a discussion with my boss and project manager, I've been informed that anything developed for the project I'm working on is considered intellectual property. Unfortunately that means I will not be able to contribute any code (at least not until our legal team figures out how to handle working with open source). Sorry to leave you guys hanging, but I wish you the best of luck in getting an E-stop that works for you!

[NickNunno]

@tridge @rmackay9 do either of you have time to take a crack at this?