EPO Latch

Submitted by il diavolo on Fri, 04/27/2018 - 22:25

Forums:

Occasionally when I have a software crash on the Pi (which is quite often, as I mostly program on the fly), the Reverse board keeps powering the motors, sending me running after Diddy to switch off the batteries before he scratches the sideboard - not to be recommended when the Pi is in an uncertain state as it risks corrupting the SD card.

If I fit a non latching switch instead of the jumper on the Reverse (with a big red button on the top of Diddy) will this stop the motors? If so, will I then have to reset the EPO latch ("Start" on the PS3 if Bluetooth has survived the software crash)?

Or - is there something I can do to my code so that the Reverse board automatically shuts down if the Pi crashes?

piborg's picture

piborg

Sat, 04/28/2018 - 09:13

The good news is that PicoBorg Reverse has a builtin function for this, a communications failsafe which shuts the motors down if it does not get messages from the Raspberry Pi frequently enough.

There is one command to call towards the start of your script / session in order to enable it:

PBR.SetCommsFailsafe(True)

Once enabled it will stay enabled until the PicoBorg Reverse is powered off (i.e. no 3V3 from the Pi) or you call the same function with a setting of False instead. You can check if it is currently enabled by calling PBR.GetCommsFailsafe().

When in this mode you will need to call any library function at least 3 times per second. For example regularly sending new motor power levels (even when they have not changed) is what we tend to do, but reading a status such as PBR.GetEpo() would also do the trick. As long as you keep sending messages the PicoBorg Reverse will behave completely normally.

When the board does not get an update for too long it will decide something has gone wrong and do the following:

  1. Set both motor outputs to 0
  2. The LED will flash to indicate it has detected a problem

As soon as another message is received the LED will stop flashing and you will be able to start the motors again as though nothing had happened :)

As for the EPO button option you are quite correct. As long as the EPO pins are disconnected for a short time (less than a second) then the board should disable the motors entirely until the PBR.ResetEpo() command is called.

If the robot running away is a large problem for you there is no reason that you could not do both. For example the EPO is a good way of dealing with a script error where it is continuously sending the wrong motor output, while the communications failsafe would stop the motors for you if the script crashes for any reason.

If you take a look at our original DoodleBorg PS3 source code from when we were using PicoBorg Reverses you can see that we actually did do both, plus an extra check in code to see if we had stopped getting updates from the controller.

il diavolo

Sat, 04/28/2018 - 20:36

I can see where I went wrong. I've been modifying your scripts for different projects for some time but I now see that in my current project, which I have tried to strip down as much as possible, I didn't cut and paste the failsafe section from your code. That explains why the problem of Diddy running on has only recently become a problem.
The up side of this is that I now understand how the EPO works thanks to your very clear explanation. My sideboard is still in danger, but only from my grandson when he drives Diddy around the house!

Subscribe to Comments for "EPO Latch"