Shutting Down a Robot-Mounted Pi

Hi all,

We’re planning on using a Raspberry Pi on the robot this year, but we’re having trouble wrapping our heads around how to properly shut it down when the robot shuts off. Linux systems HATE having their power just pulled, so we’ve been trying to find a way to prevent corruption every time we shut off the robot.

We’ve been trying to get the Pi to mount its filesystem as read-only, but when we do that, networking disappears (and we need Ethernet working). Neither Stack Exchange nor the rest of the internet seems to have any remedy that has worked for us.

Teams that have used a robot-mounted Pi, how have you made sure that the Pi doesn’t get corrupted when the robot power is turned off?

Honestly I have never had a problem. The RPi shouldn’t be doing any critical system tasks when processing vision stuff. I’ve shut it down most of the time by pulling the power.

Sure, there are risks involved… but think about it this way. What does the RoboRIO run? What about your home router? (Answer is Linux).

Most of the time we just pull the power on those and expect them to come back up. I expect no different from the RPi.

Here’s one way

Our team is using a Pi on our robot this year and found that issues with corruption don’t exist, as long as the Pi isn’t reading/writing important files when the power is pulled.

Your statement about Linux systems “Hating” having their power pulled is generally false. Think of all the devices in your life that run Linux that have their power pulled and never skip a beat…wireless routers, car computers, the RoboRIO, phones, Smart TV’s.

I know for certain the RoboRIO OS is hardened to be able to accept a sudden shutdown, and I’d assume any decent home router was designed with the thought that they shouldn’t expect a graceful shutdown.

Raspbian has corrupted SDs on me in the past, but if teams haven’t had issues with FRC-related tasks, I guess it’s worth a try. Thanks!

Is there a specific reason you want the Pi to be powered off when the robot is turned off?
I read the rules as you would be allowed to have an additional battery on the robot to power the Pi alone.

According the R31
“Additionally, batteries integral to and part of a COTS computing device or self-contained camera are also permitted (e.g. laptop batteries, GoPro style camera, etc.), provided they’re only used to power the COTS computing device and any peripheral COTS USB input devices connected to the COTS computing device and they are securely fastened to the ROBOT.”

Can you show me where you bought a Raspberry PI with an integral battery?
Integral means like the battery that comes with your laptop.

This topic has been done extensively elsewhere on the forum.
Adding a battery to the Raspberry PI violates the rules unless you can buy a package from somewhere that has the PI and the battery packaged together. That source (store) needs to be able to sell to the general public.

This only applies when the battery is “integral to and part of a COTS computing device”. Most (perhaps all?) COTS raspberry pis accept a power plug, and do not have an integrated battery. If you could somehow make the case that a USB power pack was a computing device (or camera), you could use it to power the pi over USB.

Did you consider the swap file when you wrote this?

The file system on the SD card does have a chance of being corrupted if there is a power loss during a write operation. Just because “we did it one time and it worked” doesn’t mean it’s a good solution. Also, *nix powered things like phones, routers, and others have features to protect from this type of corruption that the Pi doesn’t have, so it’s not a good comparison.

The issue is not with linux but the SD card. R-Pis have a tendency to bork the SD file system if shut down at the wrong time. I recommend to my students to have a complete clone of the working system SD card, which NEVER goes in a Pi. If the one in the Pi gets corrupted, reclone the master copy on to it, and everything is exactly as it was.

the master is made by taking the latest working pi card and shutting down properly before cloning to master. when doing software updates, have two masters. one is the last working rev, and the other is the current working rev.

Also, faster and more expensive SD cards tend to corrupt less (anecdotally)

Lastly, to answer the OP, I’d send a signal from the roboRio to the Pi at end of match to request a clean shutdown, then it will be powered down by the time you get to your robot during field reset. Most other cases can be covered by the onboard power switch linked to above. You still will have cases of unexpected power loss, but the less often it happens, the better.

knowing how long your electronics take to boot and shutdown nicely is really important.

Yes, most of the guides I followed on how to make the file system read only said to disable swap in the boot config.

All of these teams have 3D printers and are not interested in a revenue source entrepreneurs award.

If nobody wants to jumps on this I’ll start a company tomorrow to sell you one.

Need a website and other stuff to prove you have a proper business for the general public. It’s not actually that hard: I just am too busy with other things to sell an assembled Raspberry PI in the case with the battery to someone.

Worse there’s nothing stopping someone then from placing a really big order which means unless you have a large pile of the Raspberry PI handy…

I searched, where is this discussion? Where’s the QA question?

http://www.chiefdelphi.com/forums/showthread.php?t=117989&highlight=battery

Also this from me in that topic:
http://www.chiefdelphi.com/forums/showpost.php?p=1287141&postcount=45

See later pages there are others on the forum about this.
I don’t have my fingers on the old official QA you’d have to dig that up and look but I meant this forum when I wrote this:
“This topic has been done extensively elsewhere on the forum.”

If I really need to I am sure I can dig up that old e-mail from FIRST headquarters.

I literally typed the title of that thread and it didn’t come up. Wow, thanks.

So you say I’m almost guaranteed to sell a few hundred to prove I can keep up with demand? I’m not hearing the problem.

Adafruit will sell me 85 per order

I don’t know the RoboRIO ecosystem, but I do know Linux and Java.

ssh user:password@rpihost 'sudo shutdown -h now'

You’re possibly better off putting the shutdown command into a shell script so you can attempt to kill the processes ‘nicely’ first, then issue the shutdown - all within the script. The script would live on the raspberry pi, so your RoboRIO code doesn’t have to care how the R-PI stuff shuts down, ever.

Add this when you detect end of match presuming you go the script route:


java.lang.ProcessBuilder processBuilder = new java.lang.ProcessBuilder("ssh", "user:password@rpihost","/path/to/script.bash");
java.lang.Process p = pb.start();
p.waitFor(); // WARNING - will block this thread.  Also, will *only* block this thread.
System.out.println("R-PI shutdown executed");

What are you waiting for :smiley:
Are you done yet? (quoting an old college professor 10 minutes into every test)
Can we buy one?

Remember you need a way to charge that integrated battery as well.
If you sell this under COTS there’s no minimum sale requirement - just that people in general can buy them.
If you take this product into FIRST approval that’s a more complex and lengthy process you will not complete this season.