Rover 4.2.0-dev GPIO Behavior (possibly dangerous?)

ArduRover Rover 4.1
1

I’m revisiting a 4.2.0-dev upgrade this week and I’m so far stuck for solutions regarding proper GPIO behavior on the Cube Orange at boot time.

@rmackay9’s previous reply included:

We think if you set SERVOx_FUNCTION = -1 (GPIO) for the relevant channels then you’ll be back to the old behaviour.

Following Randy’s advice, I was able to get close to “normal” behavior, but it’s still not behaving well.

My original relay board was active low. With it, under 4.2.0-dev, all of the relays were briefly triggered at boot for about 2 seconds until the transmitter was able to command them to their proper off state. Worse, if the transmitter was off/out of range, the relays stayed engaged.

I was never happy with the active low relay board, so I took this opportunity to replace it with a better quality board that has proper active high inputs. The new board’s behavior is WORSE! After checking and double checking that I’ve reversed the settings used for the previous board, upon boot, the relays are all triggered for about 2 seconds, then flicker twice before finally switching off as intended. Thankfully they stay off at that point, regardless of transmitter state.

Under previous firmware, I think I solved this by setting the RELAY_DEFAULT parameter, but it has no effect with 4.2 (or I am mistaken about its purpose).

As of this moment, the only way to safely boot my flight controller is to disconnect the power connector on the relay board until the boot sequence is complete. If I do not take that precaution, the ignition, starter, PTO (mower blades!), and driving lights all trigger immediately and repeatedly upon power up, which is incredibly unsafe.

I’m happy to provide parameter files or logs if you think they will be helpful. I hope I’m just missing a simple setting in the parameters.

Additionally, after the 4.2 firmware flash, RELAY_PIN2 was set to -1 rather than saving my 4.1.0 setting of pin 55. The other relay pin settings were unaffected.

This particular topic is probably best discussed in a Rover 4.2 category, but I guess I’m a little ahead of the forum for that…

2 Likes
2

I have the same problem, hope it can be addressed as seems no way to get around.

3

Hi @Yuri_Rage,

Sorry for not responding sooner on this, I’ve been away on vacation for the last 10 days. I hope to investigate this soon.

4

Thanks much, Randy.

I upgraded the power module and rearranged some power distribution wires today (an overdue upgrade), which eliminated the flickering that I mentioned. The flickering was caused by somewhat poor power distro design on my part but never really mattered because I never intentionally trigger all the relays all at once.

However, all relays are still triggered for 2-3 seconds prior to full initialization of the flight controller, and no amount of parameter changing seems to improve the behavior.

I have discovered another workaround for my own system, since the relay board no longer receives power through the flight controller - I can boot via USB power, and once the initialization tones have played, apply power to the rest of the system. Then I can remove the USB cable. Still far from ideal…

1 Like
5

Any update on this one? I hate to be a bother, but I’m also not enjoying the workarounds at present…

6

Hi folks, a solution would be to add a “master” Pololu RC relay controlling the power feed to all your other relays - either the COM, or the power to the actual relay board.

The Pololu has a validity check before it engages (you have to send it a valid “off” PWM before it will switch “on”). With the PWM output behaviour presumably working in Rover, you could use that as your master enable for all your other systems - either through an RC channel or MP. It would also give you an RC Tx master kill switch.

Even if the GPIO gets fixed, it’s probably not a bad safety feature.

1 Like
7

Funny you mention PWM relays as a potential workaround - I have a few of them and have been considering exactly that. It’s a good idea and quite safety minded, but I dislike the idea of adding more electromechanical complexity while using up another RC channel and output pin.

8

I’m looking into this today… hopefully I’ll have something by the end-of-day…

2 Likes
9

So this is really a long standing issue and I actually investigated it many years ago as well. The autopilot is holding all pins high during startup, before the main ArduPilot code even starts running. I think this is happening in the bootloader.

My guess is that this was done as a safety measure for multicopters which could have PWM consuming ESCs connected to these channels. If held low then an ESC might interpret any small glitch in the output of these channels as a PWM value and start the motors. A short glitch from high to low (and back to high) would likely not be interpreted by an ESC as a PWM value though (because they always look for a rising edge followed by a falling edge 1ms to 2ms later).

The bootloader does not have any way to know how a pin will be used because it does not have access to AP’s parameters.

The bootloader is really outside my area of expertise so I will ask @tridge to see if he can help.

By the way, I noticed these other issues during testing:

  • While upgrading from 4.1 to 4.2 relays stop working because the SERVOx_FUNCTION needs to be set to -1 (GPIO). We may be able to set these parameters automatically if we look at what the BRD_PWM_COUNT value was.
  • The “Relay[1] pin 55 invalid” message could be slightly improved. We should probably change it to “RELAY_PIN invalid” or something similar. Those square brackets in the message are unusual.
  • There is a small short glitch in the relay output if RELAY_DEFAULT = 0. Strangely this glitch does not appear if RELAY_DEFAULT is set to “1” or “2”.
    rover-gpio-relay-glitch
    rover-gpio-relay-glitch1684×574 36.7 KB
3 Likes
10

Thank you, Randy. I suspected the bootloader as well but found it confusing that the issue could be overcome under 4.1 but not 4.2.

I will probably employ the RC/PWM relay solution for now, but I appreciate any further investigation that avoids the use of an entire channel and pin just to overcome a brief bootup anomaly.

DETAILED EDIT:
I have successfully employed the RC/PWM relay solution using a Dimension Engineering BattleSwitch connected to SERVO 8. I did not have to use an additional RC channel to implement the workaround. I use RC5 to switch the ignition on RELAY2. There is no need to power the relay board until I want ignition power, so I simply set SERVO8_FUNCTION to RC5IN (effectively doubling RC5’s function), and everything behaves nicely.

The BattleSwitch has the same safety feature as the Polulu one mentioned above, so it goes into a “standby” mode of sorts until it sees valid PWM which prevents errant relay operation before the autopilot is initialized.

Alternatively, one could use a bank of these RC/PWM relays instead of a relay board and just use RC passthrough to all of them instead of GPIO.

Despite having a successful workaround, I would like to see this issue remain open if possible. Unpredictable and/or undesirable GPIO behavior during boot seems like a reasonable issue to solve.

11

I guess I’d also argue that having a separate power switch to enable all those things after boot-up would seem to be a sensible precaution. That could also be your emergency switch to kill them.

  • Connect battery
  • Turn on power switch to autopilot and comms
  • Verify behaviour and state
  • Enable power to spinny bits.
12

I won’t argue directly against your point - it is certainly sensible.

I will, however, make the counterpoint that such a safety interlock should exist to prevent anomalous behavior rather than protect against known, unwanted behavior. We should be able to trust the autopilot NOT to actuate/enable systems during normal behavior (to include boot up).

Additionally, the method you suggest in your last post (assuming a separate physical switch) would prevent me from doing a remote reboot of the system, which is something I often find necessary during testing. If I want to change an enable parameter, I’d strongly prefer to feel reasonably comfortable rebooting the system via a remote MAVLink command (with no one near the vehicle) rather than having to run back and forth between the GCS computer and the mower.

The PWM relay I’m using now does allow for a remote reboot, and I will keep it in place until I find a need to repurpose that pin, even after a potential fix is released (again, because I do agree with your sensible approach to having a such a safety interlock).

I do have two external kill switches that remove power from the entire system, and I have RC channel mappings for disarming, disabling the PTO, and killing the ignition. Until recently, that has been sufficient.

1 Like
14

Fair point on the remote reboot. Hadn’t considered that.

15

Are you still on the same setup?

16

I have this same issue on my ESP32 based automation controllers where some GPIO pins go high when the chip is restarted so i ended up having to add a MCP23017 i2c GPIO expander chip that handles the GPIO that way its immune to any random behaviour if the main controller decides to go haywire. come to think of it, yuris lua i2c Arduino sensor board could probably be programmed to do the same thing.

17

I continue to use a “master” relay that must see a valid servo PWM signal to supply power to the main relay board on my mower. It’s a robust solution.

@geofrancis has some reasonable suggestions as well.

18

Hi, do you have until now the same problems, i also noticed this.
I use a power switch from Pichler with Cube Orange, in Main outputs works fine but in Aux outputs it powers on during initialization for about 4 seconds.
Do you have any ideas how i can fix this?
Thank you!

19

Try one of the several mitigation suggestions mentioned above…