COTS Raspberry Pi with Battery

In order to have a device powered by a separate battery, per R37, the battery must be “integral to and part of a COTS computing device”. I could not find a Raspberry Pi that was sold COTS with battery.

I was thinking of setting up an Amazon Seller account and offering the following combination as one item:


https://smile.amazon.com/AmazonBasics-Portable-Power-Bank-600/dp/B00LRK8IV0/

I figure if I get an order, I will place an order with Amazon to ship it to the buyer. I think the terminology is to have Amazon Drop Ship to the buyer.

I think I can qualify as a Vendor per section 8.1. A 5,600mAh should power a Pi for about 45 minutes (1.5 amp draw)

Any thoughts?

The Integral part of the rule would make that illegal in my eyes. Now if somebody was to print a case and sell the entire assembly already assembled, I could see an argument. But just selling the 2 separate items in a combo would not satisfy the integral part of the rule, at least in my eyes.

While you might be able to qualify as vendor, the battery still would not be a part of the raspberry pi, it just happened to be sold with it as a package deal. It is also not integral to the raspberry pi as there are alternative and relatively easy ways to power it without the battery.

The main use case I see the allowance of batteries would be teams who use cell phones as they are definitely integral and apart of the COTS item in that case.

“one piece” with “integral” are not necessarily the same.

If the definition is “one piece” then I could sell it with this battery and case:

https://smile.amazon.com/gp/product/B01MY72ZWT

It is also not integral to the raspberry pi as there are alternative and relatively easy ways to power it without the battery.

The main use case I see the allowance of batteries would be teams who use cell phones as they are definitely integral and apart of the COTS item in that case.

You can run a cell phone without the battery if it is plugged into power …

I am in the process of receiving a laser cutter.
I intend to do the same as you - create a COTS device with an integral battery.
It may have a PCB for compute seperate from power but some cellular and tablet devices also are integrated like this.
I have spoken with FIRST about this in the past.

I feel it is important that someone offer this, with adequate charging and safety controls to FIRST for evaluation.

My Jamieson 18"x24" laser cutter will be in my shop by early April. This is a minimum profit effort from me so I would be willing to work with others.

I am not just interested in doing this for the Raspberry Pi either.

But why do you need a battery for the pi? You can just plug it into the VRM.

The main reason I was looking for a battery powered pi was to prevent hard shutdowns, which could be damaging to its file system.

If someone sold a RPi with those two accessories pre-assembled into one unit with a name along the line of “Mobile Rechargeable Raspberry Pi based computer”. I think you’d have a pretty good argument that the battery would be integral to the device and removing the battery shield would make it no longer a COTS device as it will not preform it’s listed function.

As an additional thought to my post:

Make sure your business is properly insured.
FIRST put these rules in place to mitigate their liability for any issues as they relate to batteries.

When I get to the point that I am doing this I am likely to opt for NiMH batteries at first because lithium chemistries can be quite dangerous especially in the smallest configuration (see Samsung). I figure RC toys have been using the NiMH batteries for some time and without major incidents detracting from the market.

It’s fairly straight forward to see you’ll need to manufacture the item and somehow sell it to the general public. However you’ll also want to be sure that if there are problems you have adequate insurance.

Hence when I do this - I will likely be drawing from other designs but not necessarily simply bundling the product until I get a chance to assemble the 2 and literally toss them down a flight of stairs a bunch of times as a test.

I agree with FIRST that one should treat batteries with proper respect. I also recognize that it will be likely take several iterations of design to get to a best in class product. A $7k laser cutter, acrylic and my existing tools (3D printers, 2 LPKF PCB milling machines, a custom pick and place rig) should remove all barriers to prototyping and design.

Ultimately, though, I want to transition from merely providing a Raspberry Pi with a battery/charger. To the Raspberry Pi/battery/charger -AND- I/O solutions such that the Raspberry Pi could stand alone as a robot controller outside of FIRST. I suspect there’s more market for a proper mobile robot controller based on this popular design (Raspberry Pi) than there is for co-processors with self contained power in FRC.

This rule is absolutely stupid and should go. Enough already.

I do hope someone does develop this product and start selling it purely because of this rule but it shouldn’t be like this, this rule needs to be updated.

Effectively what this rule has done is put a very high cost barrier in front of these opportunities to advance.

If you are a student using incubation resources from a school you probably lack the financial resources to make delivery. Worse it will be hard to sell a business plan to garner investment for such a limited market (it’s a market less than the size of all FRC participants and the entire angle is potentially negated by creating an adequate power source from the robot battery - which is very possible but often not as straight forward as one might think).

If you are a company without incubation resources to do this you need to build a quick turn prototype facility that may not fit your primary markets (driving probably $30k-$50k in cost). So a large number of companies in nearly related fields would probably ignore this.

In short - I really think this rule dramatically limits the people that are in a position to actually create and submit for evaluation solutions. In the end the only reason I am willing to even consider attempting this is because I ultimately want to prototype for market opportunities outside of FIRST (and beyond robot controllers) - any bearing it has on FIRST is merely incidental. In short my $7k+ laser cutter, my $20k+ of LPKF machines and my $25k+ in 3D printers are not here specifically for the benefit of only FIRST. If my attempts at this fail - I still had other, even better - reasons to acquire this tooling capability.

So: as much as I can understand why FIRST ended up with this rule - it’s driving down diversity in their war chest of field legal options.

If you’re worried about this, just make a backup SD card. There is absolutely no reason that you should have your pi battery powered, and the rule is what it is for safety reasons.

Referring to the concern about filesystem damage, just to clarify.

I can think of some great reasons one might want to power a co-processor separately from the robot. Including in the event of a power failure, logging while the robot is disabled and to operate sensors and other non-mechanical peripherals regardless of the FMS control state.

Also - if your robot looses power in the field - how are you planning on installing that SD card?

Of course one can step-up the voltage, then step-down the voltage and keep a co-processor running fairly well - such that the voltage of the battery will eventually be too low to make the robot fully operational anyway. However there are standing examples in the mobile robot design field (beyond FRC) where the controllers are on separate power from the mechanics.

So while it is not exactly vital there are cases where it has value.

One possibility: You know precisely how long the match is going to be. Send the PI a signal at the beginning of auto that starts a timer. 3 seconds before the match is scheduled to end, have it flush the disk cache. That takes care of 95% of the problems. (The other 5% are when your robot loses power mid-match).

We’re planning on setting up the PI with a read-only root filesystem to help avoid this problem, but I still think the correct answer is a battery-powered Pi.

How about just sending the Flush command when DisablePeriodic is called.

My coprocessor has a built-in charging and discharging circuit for batteries and I can’t use it. Not only that but I can’t just pop an SD-Card in and out because that’s not where my OS is stored.

It’s 2017 and rechargeable USB power supplies are abundant and plenty safe, this rule is what it is because of legacy, not because of safety.

There is a COTS kit for the Raspberry Pi called the Pi-Top. It converts your RPi into a laptop. It includes a battery and charging controller, as well as a display, keyboard, etc.
https://pi-top.com/

I do not know how this would be viewed by an inspector. The Pi-Top would need to have some portions removed to fit in the robot.

If you assemble the final product on delivery - not have it delivered assembled - it’s thin ice.

I’ve had this conversation no less than 20 times over the years since the COTS computing devices concept existed in the FRC rules.

Basically when they say integral they mean you got the 2 items assembled together. Like your laptop is shipped to you with a battery that sometimes you can remove but was probably in the laptop when you got it.

It’s also not clear that Pi-Top warranties the safety of those units in an application such as this.

Though I do know you can dismantle a commercial netbook and put it on an FRC robot legally removing: the keyboard, touchpad, display and part of the shell. So - if the Pi-Top comes to you assembled you could make the case you are simply doing that. I know this because the first year this rule existed Team 11 did that with a Gateway netbook. We wanted to prove 2 points - 1. We can actually do that. - 2. That the netbook will continue to operate despite claims that such use would destroy it (we proved that to my satisfaction the harm is minimal with a basic attempt to protect it and using an SSD).