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?

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

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!

Re: Shutting Down a Robot-Mounted Pi
 

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."

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

Did you consider the swap file when you wrote this?

http://raspberrypimaker.com/adding-s...e-raspberrypi/

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

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

Re: Shutting Down a Robot-Mounted Pi
 

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.

Re: Shutting Down a Robot-Mounted Pi
 

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...

Re: Shutting Down a Robot-Mounted Pi
 

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

Re: Shutting Down a Robot-Mounted Pi
 

http://www.chiefdelphi.com/forums/sh...hlight=battery

Also this from me in that topic:
http://www.chiefdelphi.com/forums/sh...1&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.

Re: Shutting Down a Robot-Mounted Pi
 

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

Re: Shutting Down a Robot-Mounted Pi
 

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

Re: Shutting Down a Robot-Mounted Pi
 

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

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:

Re: Shutting Down a Robot-Mounted Pi
 

What are you waiting for :D
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.

Re: Shutting Down a Robot-Mounted Pi
 

In 2012 we used a linux single-board computer on our robot and had to solve the shutdown problem. There are some details in this document:

http://www.chiefdelphi.com/forums/sh...ght=Kinect+987

Our final solution assumes that you've written a program on your vision processing computer that can respond to packets it recieves from the RoboRio or other computers. Our robot computer (crio at the time) sent a packet to the vision co-processor which caused it to run the shutdown script. We triggered all of this with a button on one of the joysticks at the drive station. For what it is, it was a lot of work to get right but we didn't want that 1 in a million chance of our vision computer corrupting its file system at the wrong time.

Re: Shutting Down a Robot-Mounted Pi
 

Has anyone looked into the legality of this?

http://www.modmypi.com/raspberry-pi/...dules/ups-pico

I'm going to ask on the Q&A myself tonight.

Re: Shutting Down a Robot-Mounted Pi
 

What worries me about that is the battery does not appear to have a fuse between it and the rest of the system. So that's the sort of battery I wouldn't want to overload and there are exposed pins that could overload that battery all over the place.

Re: Shutting Down a Robot-Mounted Pi
 

I await the Q&A response, but I expect this would not be legal, as it's not integral to the cots computing device. It's an add-on, but I suspect it is just outside the line. Could be an interesting option if they rule it legal.

Re: Shutting Down a Robot-Mounted Pi
 

That statement regarding Linux systems is fasee. If anything, Windows cares about having its power pulled. Linux couldn't care less. I have dealt with a variety of Linux distributions, and have unplugged, forced shutdown many of them. Linux doesn't care, it just works. Linux FTW.

Re: Shutting Down a Robot-Mounted Pi
 

/sigh. No computer system that I've used from mainframes to Raspberry Pi, from MCP to Unix, including Windows and Linux deals well with hard power off when there are IOs in process. You've been lucky.

Lots of people have borked the SD card in a Raspberry Pi. The OP asked a good question, and people are trying to help. Your "whistling in the dark" isn't productive and I predict that someday you will either spend the night hand sewing inodes to restore a file system, or spend most of the day hoping your backup system really works while you boss yells at you about lost orders.

Re: Shutting Down a Robot-Mounted Pi
 

Please don't give out misleading information on the internet based off of personal experience. The raspberry pi has documented issues that occur when power is cut, and it runs Linux.

The issues is more about hardware than software. The FTL (flash transition layer) will remap storage on the fly as part of its wear leveling feature. If you kill power during a remapping, you pretty much lose the whole disk. This is different from flash storage on something like a roboRIO or a wireless router, which doesn't have that additional layer of abstraction.

Linux does care when its file system is no longer usable.

Hmmmm... Let's see, first, was referring purely to the software when I made those statements, not the hardware, and yes you can run into issues dealing with the SD card if the power is suddenly cut, IN SOME CASES. If you have set it up, correctly, and are using it as a vision co-processor, all you are doing is cutting the power while a programme is running. I have done exactly this hundreds, actually thousands, of times, with a Pi B+. I have used it for vision, and just unplugged it to turn it off. Every time, it booted correctly the next time I needed it. Of course, during setup, I made sure to never to that.

So please folks, don't question my intelligence.

Re: Shutting Down a Robot-Mounted Pi
 

Sorry to quote myself, but this thread has devolved a bit and I really do wonder if a software solution is plausible. This 'ssh' works well for a few things at work, but I don't know if the RoboRIO/R-PI setup allows for it (firewall/sudo permissions/etc).

We're toying with a few auto-shutdown features in our own code, but detecting the end of match (rather than disabling of robot) is proving a little tricky.

Re: Shutting Down a Robot-Mounted Pi
 

It is possible if you are running Arch Linux with the swap file OFF that your systems will only be writing to storage when and if your application writes to storage. Raspbain quite often has swap enabled and written to the SD card. Depending on how swappiness (yes that's not made up it's a real thing) is setup your kernel may or may not use that swap if the memory space of your application starts to use up too much of the system's actual RAM.

This is not to question to you, or anyone's intelligence, just a point that currently I have 50,000+ copies of Linux online and running in various public and private clouds and datacenters. The smart thing to do is do a proper shutdown unless you know for a fact you've controlled the risk or have no better option.

For example I used to take Dell OptiPlex systems I had as leftovers from upgrades and put Ubuntu on them. Mess with the disk settings to spin down the hard drives and spin them up only on demand or every 6 hours (which ever was first and then spin them back down in 5 minutes). I would increase the write cache large enough that casual writes would come back from memory. I would remove the swap so that would not qualify to spin up the hard drive. Most of the drives lasted beyond 8 years and those that did not were already questionable (had de-allocated bad sectors that weren't mapped at the factory). These systems were used for print server farms like a giant version of the HP JetDirect driving down the cost of the printers because we could print to CUPS raw queues from Windows happily.

So again - there's plenty of simple ways shown here to accomplish this task from using a button and a script or SSH.
Why run any risk you don't need to?
Unlike other applications out there you really might take the chance you have an issue in the next match that hurts your competitive edge.

Re: Shutting Down a Robot-Mounted Pi
 

As long as you never write the SD card, then the SD card's wear leveling feature shouldn't try to move blocks around.

This requires:
-Disabling swap entirely (it's generally a good idea to disable virtual memory entirely on real-time systems anyway)
-Mount the SD card as read-only
-Mount the temp directory onto a RAM disk

There are some tutorials on the internet explaining this, there are a lot of nuances since a number of automatically installed packages will try to write to disk (including syslog and fake-hwclock among others). Once you take care of all of those, you can set the fstab to mount the partition as read only so no program can write to the disk.

It's certainly possible for a carefully designed system to be turned off by pulling power. Virtually all embedded systems including the roboRIO operate in this way.