Battery powered raspberry pi
 

This year, we had problems with the unstable power supply for our onboard raspberry pi. I'm a little stuck as to how to solve that:

Option a) get a battery for the raspberry pi -> illegal under R34 because it is not an integral battery. Can I get around this rule, assuming it doesn't change?

Option b) use a laptop -> laptops are usually comparatively heavy and big. Does anyone know a lightweight, cheap laptop with at least 2 USB ports and Ethernet? [a 3rd USB port for an Ethernet dongle is fine]

Option c) somehow guarantee the availability of 1 amp for the raspberry pi?

Option d) can anyone else think of another option?

Thanks so much for any help you can give me!

Re: Battery powered raspberry pi
 

What did you have as a power supply for the pi?

For option b, look at SBCs (atom computers on a single board with, well, everything). Suggestion: http://www.geeky-gadgets.com/wp-cont...abyte-Brix.jpg

Re: Battery powered raspberry pi
 

I would try and use a circuit similar to this:
http://schematiccircuit.files.wordpr...ing-lm7805.jpg

That is what out team did to make our onboard PI work. Have you tried anything similar to that yet?

Re: Battery powered raspberry pi
 

My advice is a step-up switching regulator like in the FIRST PDB.
Going into a step-down switching regulator sort of like inside the cRIO.

National Semiconductor makes parts that will switch battery voltage up to roughly 20V.
Obviously because look at the cRIO input voltage.

National Semiconductor also makes parts that will switch roughly 20V down to 5V.

Each stage of regulation is both a noise filter and complements the other.

If you switch up to 20V and the battery caves to 8V the 20V suffers.
However the next stage just needs to get 5V so that 20V quality issue is damped.

Each stage will be probably about 87% to 95% efficient with switching regulation.

On the other hand a 7805 as pictured will remove the excess energy as heat.
If the battery is 14.3V depending on the current enough heat for a heatsink.
Sure you can get a TO3 metal can version of the 7805 or make an external pass transistor but it still just burns energy off as heat.
If you do build that 7805 circuit you should install blocking and bypass silicon diodes.

Re: Battery powered raspberry pi
 

We have had pretty good luck with using one of these (http://www.andymark.com/product-p/am-0899.htm) to power an onboard RPi. It is the switching power supply that comes in the KOP for the wireless bridge but it works great for powering the RPi. Another bonus is you probable have one left over from a previous year.

Re: Battery powered raspberry pi
 

What power supply did you use last year?

Re: Battery powered raspberry pi
 

Has anyone considered using one of these for your power needs from the robot battery?

http://www.dfrobot.com/index.php?rou...product_id=752
(That is the source in China)
http://www.robotshop.com/productinfo...222&lang=en-US
(They carry their products here in the U.S. and Canada)

I have several Chinese manufactured PCB with National Semiconductor regulators and when I have some time (probably in the next week or so) I will power them up and test them at 1A from 7VDC to 15VDC.

I stumbled across that because I bought one of their Relay Shield V1.2 to update my ever growing pile of Arduino swag.

Re: Battery powered raspberry pi
 

We used a second 12v-5v power converter (http://www.andymark.com/product-p/am-0899.htm). It was a problematic because if the compressor and shooter motors were both running at the same time, there wouldn't be enough power left for anything else.

I realize now that was because we chose our gear ratios terribly and the shooter motors were running very inefficiently, but all the same I wanted to try to isolate the RPi's power from the rest of the robot so it wouldn't cut out.

Re: Battery powered raspberry pi
 

The problem ultimately will be that you can't really store energy for a protracted period with the FRC rule limitations on custom circuits.

The allowance of a laptop and it's battery I think were more intended to allow teams to not have to make more electronic modifications to the laptops which usually come neatly packaged.

I suspect if you put any largish capacitor or battery on the robot within a custom circuit specifically to provide 0.X seconds of storage you'll start to have issues getting through inspection.

I would be interested to know if anyone has managed to pull off a storage capacitor or battery in a custom circuit and made it through an actual FRC inspection. You can get high Farad value capacitors at 5V that would easily provide a robust filter against short drops in the battery. However those capacitors do not generally discharge themselves and for a relatively short period of time after a power off power will remain. It is possible to make a discharge circuit for a capacitor after power off but I'm not even sure the capacitors or auxillary battery would be allowed.

Re: Battery powered raspberry pi
 

So I guess this is out of the question?

Re: Battery powered raspberry pi
 

LOL I actually have a 3.5F capacitor for automotive electronics on my test robot frame at home. It basically comes with it's own welder.

I was thinking something more like this:
http://www.karlssonrobotics.com/cart...Fcef4Aodwy0AYQ

I love that datasheet.
For tolerance it lists: -20%〜+80%
So I guess it's perfectly okay to send out a 15F capacitor instead of a 10F capacitor?
Might make the RC time constants *just a bit* longer.

BTW: With a capacitance this large one really needs to consider the currents that will flow if that capacitance is entirely discharged and someone connects a power source to it. Luckily with control system boot and robot setup times of at least 1 minute there's time to charge it slowly. Though I still doubt it is legal in FRC.

Re: Battery powered raspberry pi
 

How about a BEC used for RC cars and planes?

http://www.graysonhobby.com/catalog/3ampbec-p-786.html

Re: Battery powered raspberry pi
 

If you want ARM:
I have never dealt with them but there are netbooks like this (runs Windows CE you *might* be able to put Linux on it you'd have to try):

http://www.saferwholesale.com/catego...FUei4AodaWoA2g

http://www.saferwholesale.com/300MHZ...0mini%20lp.htm

If you want something with more performance:
Search some place like Amazon or Walmart minding the $400 limit.
You should stay away from the refurbished or open box sales because they are not available consistently to everyone.
That might put you in violation of an FRC rule as well.

For example:
http://www.walmart.com/ip/Acer-Black...Specifications

I advise you to use flash storage and not a mechanical hard drive.
It's not just lighter it will not get trashed when you smash into things.

I can tell you from experience that if you remove the display and keyboard (which you do not need if your portable computer has a display output connector...the little ARM netbooks I linked earler do not) you can get a larger netbook down around 3lbs.

Re: Battery powered raspberry pi
 

The specs for the power converter says it only operates down to 10v. I think almost any robot will draw the battery down below 10v at some point. The 7805 circuit that was posted will work down to a little more then 7 volts, which may be good enough. You can also use a low dropout linear regulator with the same footprint as the 7805 which will lower the required input voltage a little more. Both of these have the heat caveat that Brian mentioned. The 5v supply on the PDB will operate down to 5.5v and supply 3amps. This is probably the easiest, if you aren't already using it.

The gold standard is the boosting type of converters that Brian recommended, however they are probably unnecessary.

You can use the Driver Station Log Viewer to see what the battery drops to, which will help determine the required minimum voltage.

The current logic power converter works for the radio because the 12v power supply on the PDB for the radio is a boosted power supply, and will stay at 12v until the battery dips below 4.5v. The power converter probably isn't a great solution for other devices on the robot, however.

Re: Battery powered raspberry pi
 

I think you're probably right. We also were using somewhat older batteries, which would contribute to the lack of voltage. I will try to keep the 5v supply on the PDB open for the Raspberry Pi, if not I'm sure the 7805 or a switching regulator will work.

Thanks everyone!

Re: Battery powered raspberry pi
 

I suspect that tolerance is more closely related to ambient temperature than their manufacturing capabilities.

Re: Battery powered raspberry pi
 

Well Digikey sells the Nichicon super capacitors and they list +/-20% as does Murata.
BTW if you look through the high end capacitance in the Digikey component search it's pretty interesting.

A few thousand Farad capacitor anyone?

Re: Battery powered raspberry pi
 

maybe I read the rules incorrectly, but wasn't there an exemption on battery power when in came to on board computing? Laptops can use a battery. what's the significant difference in that RPI and a laptop?

Re: Battery powered raspberry pi
 

You can probably squeeze a real time clock battery under this.
However the Raspberry Pi does not ship with a battery to power it.

I've sent a question over to FIRST in private to see if they'll let a battery or large capacitor integral to an approved power conditioning device onto an official competition field. Of course getting approval is a process in itself.

Fundamentally I think the answer to why integral batteries to COTS devices are allowed but not custom circuits has to do with the chance that someone builds something strange or unsafe that leaks power into unexpected places with the potential to cause movement when disabled or powered off. Also it goes back to the rules about devices that store energy of any type. Though I grant that custom circuits are not supposed to be connected to actuators of any sort so how exactly the power gets to movement must be left to the imagination (many laptops have fans that spin in them as well but again...they are within the laptop itself).

Re: Battery powered raspberry pi
 

So you build a small battery into a case that holds a raspberry. Make enough to sell to other teams that might want one. create a little LLC to make/sell it. Presto a cots device. Fits the letter & spirit of the rules.

I think the main reason for no batteries in custom circuits is there is just not enough time to adequately inspect them & it greatly simplify the rules in this area.

Re: Battery powered raspberry pi
 

There is, as far as I can tell, no reason you can't put some significant capacitance across the power input to the Pi, so long as the capacitors are charged by the robot battery. (Dropped to 5V, of course...) The rule doesn't say that you cannot store electrical energy, only that the electrical energy has to come from the battery.

The standard way to power a Pi from a 12V battery is to simply use a car "cigarette lighter" charger. Most of them should contain a 5V switching power supply capable of delivering at least one amp.

I'd say, find an old car charger that you've got kicking around, hook it up to a variable power supply and your Pi, and slowly turn down the voltage on the power supply until the Pi stops.

Jason

P.S. My hope for the year 2040...

"Mum, why did that old guy call the power port a cigarette lighter?"
"Because people used to use that to light cigarettes, dear."
"Yeah, but what's a cigarette?"

Although more likely it will be...

"Mum, did you really have to plug your chargers in to something and use wires?"

or...

"Mum, what is 'USB'?"

Re: Battery powered raspberry pi
 

That is something worth testing the waters with as well.

The question is what a 'laptop' consists of.
Is a tablet a laptop?
If it is there goes the mouse and keyboard.
Does it really need a display?

I know we removed the display and keyboard from our laptop and it passed inspection.
However both the keyboard and display were present when we bought that netbook.

Well outside of the rules I can think of several reasons to limit the capacitance between the power supply and something like the Raspberry Pi.

The current that a high value capacitor will draw when deeply discharged needs to be limited. If that current is drawn through a 7805 regulator as discussed earlier in the topic it could cause some damage unless there is at least a series resistance between it and the regulator output. If you simply use a resistor like that it will increase the amount of time it will take for the voltage on the capacitor to reach say 5V. If the capacitor is plugged directly into the input of the Raspberry Pi that will create a strange situation where you rely on the reset control circuitry to hold off the chip operation until the input power is at the proper voltage. That could cause some issues.

On the other hand if the power supply from the battery to the capacitor is a switching power supply then you have the problem that happened other years (regarding the radio DC-DC converter) where there is a finite upper limit of capacitor you can place there before it dramatically alters the filter at the final stage of the switching regulator altering the quality of regulation.

So there are a few reasons to properly size the capacitor or use especially high value capacitance in circuits that manage their behaviors. Not to say it can't be done if in fact no one says no to it.

Add a couple of capacitors in parallel to the raspberry pi's power input. If your problem was the rippled power, this should solve your problem.

Re: Battery powered raspberry pi
 

http://www.mouser.com/ProductDetail/...2fVA l1Xs8%3d

KA278R05CTU - Used this part to substitute my power supply in senior design. Low dropout, .5v @ 2amps. Basically, keep the input voltage to 5.5v or more and your pi should work. There's also an adjustable version if you're so inclined.


Good luck.

Re: Battery powered raspberry pi
 

I think it's probably important to frame this for the reader as to the advantages and disadvantages:

1. Use a portable computing device that is designed with an integral battery:

Advantages (limiting this only to the power issue):
A1. No effort to design additional power circuits required.
B1. Complete isolation from the battery used to power the robot motors.
C1. Battery life that will exceed 30 minutes.
D1. Easily replaced year on year (performance advantages outside scope).

Disadvantages:
A2. Limited opportunities to reduce the weight of the unit.
B2. Something else to remember to charge.
C2. Limited shelf life.

2. Create a battery powered COTS version of various boards like the Raspberry Pi, Arduino, BeagleBone, Panda...

Advantages:
A1. No effort to design additional power circuits required.
B1. Complete isolation from the battery used to power the robot motors.
C1. Slips past FIRST approval process if it is legal to do at all (unknown criteria).
D1. Allows weight tuning to optiminal levels.
E1. New market territory as not many things like this exist.

Disadvantages:
A2. We don't know how far you have to go to make something like this a COTS portable computing device. You might have to include parts at the time of sale that can be removed later to reduce the weight.
B2. You get whatever you get power wise. How long is long enough to run on battery? If your target market exceeds FIRST there's a real design issue in battery run time.
C2. Cost - you are bundling the cost of the computing device into the cost of the battery package. You must absorb both costs at the time of manufacturing and stocking.
D2. New market means uncharted territory and risk.

3. Create a super capacitor based circuit to provide isolated power to whatever you connect to it:

Advantages:
A1. No effort to design additional power circuits required.
B1. Potentially complete isolation from the battery used to power the robot motors.
C1. You can provide power to whatever works within those limits increasing the target market.
D1. If a new version of a computing device ships you don't care as long as it needs the same power.
E1. Super capacitors do not contain as many nasty or volitile chemicals.
F1. Bleeding edge market opportunity.

Disadvantages:
A2. Don't know if FIRST is willing to approve something like this.
B2. Approval is a process that commits the maker to certain requirements.
C2. The cost of the super capacitors mean this will likely cost at least $15 but more likely closer to $25.
D2. Super capacitors generally will provide less run time then a battery for the same volume.
E2. Cannot be expanded with a mere pass transistor - besides it stores power not merely regulates the power.
F2. Bleeding edge markets might leave the seller bleeding.

4. Use a step-up then step-down power supply:

Advantages:
A1. Limited effort to design the power circuits.
B1. Cheap - There are piles of Chinese boards for this on E-bay and through North American / EU supply houses.
C1. The power supply maker doesn't lock you into a computing board as part of the package.
D1. When the robot is off this will not hold power very long.
E1. Can retain operation at proper output voltage down around a 3V robot battery.
F1. Someone could mitigate many of the disadvantages below just be bundling these items into a COTS item.
G1. If FIRST requires approval for this at least it has wide potential market.
H1. At least 85% efficient and easily past 90% efficient.
I1. It is possible to exploit existing power supply circuits in the PDB to achieve the first stage regulation.
J1. Good isolation but when the input from the battery is charging the output filter of the first stage noise can pass.
K1. The odds of 2 separate regulators synchronizing with the noise on the robot battery are very low.

Disadvantages:
A2. Very few COTS step-up then step-down modules prefabricated (boost - buck)
B2. Generally single stage (boost - buck) converters have lower power limits than 2 seperate systems chained.
C2. The circuits themselves are much more complex than a 7805.
D2. End user packaging is probably required.
E2. If someone bundles this into a COTS item FIRST may require approval for it.
F2. Regulation can not be expanded with external pass transistor without inheriting the disadvantages from next choice..

5. Use a simple 7805, 7809, 7812 or adjustable reference regulator:

Advantages:
A1. Simple.
B1. Generally a small circuit.
C1. Cheap - most of the car power supplies that output 5V are 7805.
D1. A low dropout version will work to fractions of a volt at the input over the output voltage.
E1. Great for limited currents.
F1. Low weight when the current limits are low but high currents require heat sinking.
G1. If you use mica insulators you might be able to heat sink to an aluminum or copper robot component.
H1. Available in various packages with various current limits: surface mount, TO92, TO220, TO3
I1. It is possible to exploit existing power supply circuits in the PDB to provide initial regulation to reduce heat.
J1. It is possible (but counter-productive) to make a circuit to bypass the regulator if the input voltage drops lower than the regulator input voltage requirements.

Disadvantages:
A2. Gets rid of excess energy as heat.
B2. Increased current demands increases the heat generated.
C2. At increased currents needs a heat sink so weight increases unless you can manage to use the robot components as a heat sink.
D2. Does not deal with highly inductive or capacitive loads well.
E2. Can sustain physical damage under high loads.
F2. Can not produce a higher voltage than available at the output.
G2. Versions that are not low drop out require at least 1V more at the input than the regulated output.

Comments or suggestions let me know.

[quote=

3. Create a super capacitor based circuit to provide isolated power to whatever you connect to it:

Advantages:
A1. No effort to design additional power circuits required.
B1. Potentially complete isolation from the battery used to power the robot motors.
C1. You can provide power to whatever works within those limits increasing the target market.
D1. If a new version of a computing device ships you don't care as long as it needs the same power.
E1. Super capacitors do not contain as many nasty or volitile chemicals.
F1. Bleeding edge market opportunity.

Disadvantages:
A2. Don't know if FIRST is willing to approve something like this.
B2. Approval is a process that commits the maker to certain requirements.
C2. The cost of the super capacitors mean this will likely cost at least $15 but more likely closer to $25.
D2. Super capacitors generally will provide less run time then a battery for the same volume.
E2. Cannot be expanded with a mere pass transistor - besides it stores power not merely regulates the power.
F2. Bleeding edge markets might leave the seller bleeding.
[/QUOTE]

I think a capacitor bank is the best idea. It is easy to wire up as well. As far as the previously mention of legality goes, I'm pretty sure it is legal. I remember team 118 used some capacitors in one of their circuits on their 2012 robot. I forget what it's purpose was. It doesn't appear to me to be illegal, so I would recommend it.

As referred in C2, what do you mean by super capacitors? Why would these super capacitors cost $25? That is a lot of money for a capacitor. In Houston I can grab a handful of these guys (picture) for $5-10. That should be enough to stabilize the power input.

Like you said there are some drawbacks to having a capacitor bank, but the issues don't strike me as major ones.

Attachment 15133

Re: Battery powered raspberry pi
 

Super capacitors are generally a class of capacitors using double layers and gold to produce a large capacitance with a high internal resistance. They are suitable to provide power to digital circuits. They are not so suitable for things like locomotion.

In this case many of these capacitors are $5 and many rated at less than the voltage required by the load. So you need to put them in series. Putting them in series works like resistors in parallel so your capacitance divides. Then you need more capacitors because your capacitance is being divided down to reach your voltage requirements.

If this is legal then there a few people that have spoken to me in the past that have been asked at inspection to remove capacitors incorrectly.

The risks of a bank of capacitors are that the current to charge it when discharged can be high. If you limit the input current then it takes a while to reach the target output voltage. Plus if you turn off the robot with a large capacitance there the power will remain.

All of this can be eliminated with a good circuit design.
However between the cost of the capacitors and extra circuitry the cost as a whole will climb.

Keep in mind that large capacitances like this were not available at these prices until recently (last few years).
It's a big problem when people say....just put some capacitors in parallel on something.
You could have 82F capacitors....are you sure you want hundreds of Farads sucking power from your battery hard when discharged?
There really is such as thing as too much or too little with this.

Ok. That is different. That way might not be legal like you said. I was just thinking of a couple if smaller capacitors in parallel to the input power. I have seen small capacitors like that on robots before. Would a small device like the raspberry pi even need a large bank like that though to stabilize the power? It seems like a lot for something so small.

Re: Battery powered raspberry pi
 

Up to about 100uF (way less than even one super capacitor) you are not proposing something unusual.

What is required depends on how badly the power from the battery is being hammered. In a well designed fully operational robot the battery might never drop below 7V and 100uF would be just fine. Actually in that case even 10uF is more than enough.

However there is the not so unusual case of a robot with some design issues or damage that draws too much on the battery in random and unpleasant ways.

Then you get into the territory where you want storage of power segregated from the main battery. You can't do that with a small number of typical capacitors. You could store this kind of power in super capacitors. However then the design requirements go up.

With super capacitors it is possible to make a circuit that could have the robot battery pegged at 1V for 15 seconds and still provide power to the computing device like nothing unusual is going on. Why? Perhaps the extra computing device is monitoring that system or taking a hit like that will make that computing device do strange and unpredictable things that could complicate troubleshooting.

Re: Battery powered raspberry pi
 

True, It would be better to use the super capacitors I guess if the robot's power is really unstable. On the other hand though if the power is truly that unstable, it might be better to concentrate on fixing the power issue before working on a power supply for the raspberry pi.

Re: Battery powered raspberry pi
 

I don't entirely disagree. However there are many cases where because of division of labor the programmers (who we all know are *always* at fault...I am a programming mentor just so you know) might want a hedge against strange issues caused by the power to their computing equipment or mechanical issues they can't deal with.

Having a COTS device capable of eliminating this issue basically transparently might be worth having. At least then if they need to use it they can put it in and see the problem vanish. Take it out and see the problem happen. If it's COTS they don't need to design it or construct it just install it. Plus it makes life easier for FIRST because it can be sealed such that the risks from the stored energy are very tiny.

Re: Battery powered raspberry pi
 

According to the glossary, drawings/plans can be a COTS item. So if the battery was integral to the COTS computing device plans (provided by some *non-team* source for free), then would the battery fall under the exception for R34?

If using a COTS battery, COTS computing device and COTS USB devices, without influencing any actuator, this would fall under the spirit of the exception as I see it.

Re: Battery powered raspberry pi
 

I disagree. R34 says no batteries except those integral to COTS devices and even that is questionable. So as long as the constructed gearbox in your example is not COTS the result of the constructed plans is not COTS either. The plans would be.

Ultimately the people to provide definitive resolution to this are at FIRST HQ.
I advise as I have done. To ask them.

If they say go for it I certainly will not disagree. Best ask early.
Things that are not specific or overlooked often take time to get answered.

Re: Battery powered raspberry pi
 

Your drawings/plans would be a COTS item. The battery box made from them would be a fabricated item & not qualify as a cots item.

The only way this would work under the rules would be having a company build a computer, ("COTs computing device with an integral battery"), using a raspberry PI with a power supply enclosed together. The overhead would not be that high since you could use off the shelf parts for the most part and order them as you need them. Of course you wouldn't know if it was legal until the new rules came out.

Re: Battery powered raspberry pi
 

I agree that lawyering wouldn't be very effective, because the inspector can disallow anything he deems unsafe. I would prefer to have this explicitly allowed or disallowed directly by FIRST.

@techhelpbb Just so I can communicate more effectively with FIRST HQ, you mentioned you already asked them. Have they sent you a response? If so, did they give a clear indication of whether they were supportive or against the idea?

Re: Battery powered raspberry pi
 

The people I sent the request to are currently at the NI event.
Some of them doing Q&A.
So understandably they have their hands full.

I would give this a couple of days.

If we get specifics I'll be glad to toss a bit of resources at some solution to this issue. Actually I already did seeing as DigiKey is shipping super capacitors to me for later this week. If they say no I'll add it to the pile with the FIRST specific parts of the control system I designed for that same bid.

BTW the name is Brian.
Like the brain in the jar as my avatar with the i & a backwards.

Re: Battery powered raspberry pi
 

Good point. I didn't really explain my circuit well. Putting the capacitors downstream of a 7805 would definitely present the problems you have illustrated. Rather what I meant was that I'd have a diode (a fairly skookum one) coming off +12, leading to a capacitor bank. Upon start-up the caps would charge rapidly. The diode might exceed it's rated specs for constant current flow, but could likely handle the brief burst of current needed to charge the caps. It would also keep the capacitor bank from being "drawn down" when the main battery voltage slipped below the capacitor bank voltage.

I'd have the voltage regulator (either switched or linear) run off the 12V capacitor bank. The capacitor bank would often be drawn down below 12V, but every time you stopped the motors and the battery voltage went back up again it would recharge. So long as the caps stayed above about six volts, the Pi would be fine.

I'd also put a capacitor across the 5V leads on the output of this circuit, of course, just to deal with any ripple from the regulator.

The main reason I'd tend to not use the caps downstream of the regulator as my "backup supply" is that they would drop below 5V very rapidly as they would only be charged to 5V to begin with!

The main point that I wanted to make, however, was that a capacitor bank would be legal, so long as it was charged by the robot battery.



Jason

Re: Battery powered raspberry pi
 

Supercaps would be the cool, but I was originally thinking of using something like this: http://www.ianker.com/product/79ANS1052-BA.

Should I send this as a separate proposal?

Pros:
- Only needs to be replaced/recharged every few matches, in case one forgets.
- Totally isolated power supply
- Technically very easy (plug into RPi and you're done, use the other port for whatever USB peripherals you need)
- Much lighter than a laptop
- Should be quite safe, with unmodified COTS cables

Cons:
- Not as cool or fun as SuperCaps
- Obviously needs to be exempted from R34

Re: Battery powered raspberry pi
 

That works fine as long as the capacitors in question are capable of withstanding 15V. The super capacitors I linked earlier would have to have at least 7 in series to make that work. Assuming a voltage rating of 2.5V to 2.7V.

Ideally I agree you'd want to regulate post storage as well but the issue with that is the Raspberry Pi in particular out of the box have RG1/RG2 post regulators on the board. I just used a 7805 as an example it could have been a 7809 or a 7812 or an LM317. With just a linear regulator (7805) outputing 5V 2 2.7V max super capacitors is possible but of course there is the in-rush current to consider so it would be a bad idea. One of the supplies on the Raspberry Pi produces 3.3V and the other 5V. The on-board 3.3V linear regulator is by default using up the extra energy as heat anyway (some people replace that for just that reason). You can operate a Raspberry Pi down to 4.75V usually but that's pushing it.

If your capacitors are not super capacitors or have really high capacitance then this becomes no issue. There are plenty of capacitors in the 25V range (just in case) you could put on the robot like that. If the robot is not really drained a short ride through should be fine. However because you have an upper limit (cost wise / design wise) on the amount of capacitance that can be used like this there is a limit to how much reserve you can really store. So if there's a serious protracted draw down on the robot battery this might not be enough.

Plus as I said I've heard people complain they were asked to remove largish capacitors from robots during inspection.
So I am in the camp that if there's an issue here let FIRST officially settle it.

Re: Battery powered raspberry pi
 

I think you should ask about it separately. It really is 2 different potential solutions but towards the same goal. If FIRST is okay with a COTS battery supply for the boards that is another simple and effective way to solve the problem. Plus items like that are available in existing local stores which is a nice bonus. The only thing I will caution about items like that is that some of those battery packs have a button on them that you need to press to get output and if the load is disconnected for a short period the output will turn off until that button is pressed again.

Besides something like that needs little explaination. There's really no serious custom circuit there.
It would be easy to ask an official question in the official question forum when the season opens.
FIRST would really only need to say yes or no to answer it like that.
That would be one not to miss.

Re: Battery powered raspberry pi
 

One of the big problems of powering the pi from the robot battery is that the pi needs to be shut down properly. You cannot just cut the power. What I am thinking is that have the Pi connected to the battery directly (through a regulator), and have the Pi watching using it's IO, the status of the battery through the switch. When the power goes down, the pi needs to shut itself down. I forgot to add, you would need to add a reset switch to the power supply of the pi to allow you to turn it back on. NOTE: I DO NOT KNOW WHETHER THIS IS FRC COMPETITON LEGAL, so if someone knows, if they verify, it will be great. We were going to place a pi. For basic I/O, the propeller quickstart beats the pi in many ways. If being used for vision processing, why not just keep the pi with the driver station and use the network connection to function. You can bridge the connection of the laptop ethernet with the pi to get wifi.

Re: Battery powered raspberry pi
 

Depending on how you configure the Pi you could cut the power.
Otherwise send the shutdown from the driver's station at match end.

You can add switches to custom circuits not to locomotion circuits or FIRST control system power inputs. Required FIRST switches like the master breaker are the exception.

Feel free to confirm this with FIRST but I have seen it done and pass inspection.

Personally if I am gonna go through the headaches revolving around all this the last thing I would want is to add the headaches of the Raspberry Pi using the field Wifi with any camera. At that point just use the driver's station laptop.

I am generally against sending critical video through the field. It has been a headache for too many people. It even previously could impact field operations. People do this every year and every year someone struggles with it. If you can process the video on the robot you should.

Feel free to disagee with my take on this but that is the benefit of what I have seen.
It is my opinion as an engineer and I am entitled to it.

Re: Battery powered raspberry pi
 

This will not work due to the high ESR inherent to Super Caps. They are only meant for applications where the current draw is much less than 1 mA. The datasheet gives values ranging from 14 to 600 Ohms. If the supercap is charged to 5 Volts, a 300 mA input current (into the Raspberry Pi) through the 14 Ohms would cause a 4.2 Volt drop giving an input voltage of about 0.8 Volts at the Rasperry Pi). We made this mistake at work when they first became available and we were able to verify this. Note that the ESR will limit the charging current just like it would limit the discharge current so there is no concern about large charging currents.



This will work the best if you use a low-dropout 5V regulator.

The regulators that are not low-dropout (78xx, LM371, etc.) require that the input voltage be at least 2-3 Volts higher than the selected output voltage. When the input voltage drops too low, the output voltage also drops, with the voltage across the regulator being in the 2-3 Volt range, depending on the regulator type and the output current.

With low-dropout types, the input voltage can be as little as 0.5 Volts above the selected output voltage.

It would still be best to install a capacitor bank and an input diode on the input of the regulator to provide "ride through" time. The anode of the diode would be connected to the battery. The cathode would be connected to the capacitor and regulator input. The diode becomes reverse biased when the battery voltage drops and "disconnects" the regulator input from the battery leaving it to be powered from the capacitor. Without the diode, the other loads on the battery will discharge the capacitor and you are no better off. It would be best to use a schottky diode such as a STPS1545FP from ST since it has lower forward voltage drop than the normal rectifier diode. With the maximum input current of 0.7 Amps for the Raspberry Pi, a battery voltage of 11 Volts, a forward diode drop of about 0.3 Volts, a minimum input voltage of 6.0 Volts to the regulator and a ride through time of 1 second, one would need a 150,000 microFarad capacitor (C = current x ride through time/ voltage change). Nichicon makes a suitable part that is 51 mm in diameter and 120 mm long and is rated at 6.3 Volts. This capacitor is rated for 15.3 Amps so one would not get very much voltage drop when discharging it. One should use an oscilloscope to monitor the battery voltage, the regulator input voltage and the regulator output voltage during high load to verify that the capacitor chosen is large enough.

http://www.digikey.com/product-searc...ds=LNR1E154MSE

There is still the problem of getting this past inspection. Allowing for a lower battery voltage, lower regulator input voltage and shorter ride through time will reduce the capacitor value required and the stored energy in the capacitor. A smaller part would be:

http://www.digikey.com/product-detai...579-ND/1882056




You will still have to deal with the ride through time issue with this scheme.

You would want to choose a step up converter with a very minimum input voltage (at the desired load current) yet still has a high enough maximum input voltage that will accept the maximum battery voltage without damage. The output voltage should be as high as possible (check with next year's rules). You may want to choose a converter that has a maximum output current rating that is several times higher than the maximum load current. The rated minimum input voltage is usually with the maximum output current and will be lower with lower output currents. To get the most out of your system, it would be best to actually measure the maximum current draw of your Raspberry Pi while running the software you want it to run since it may be quite different than what the maximum current in the specification.

You would want to choose the step down converter with a maximum input voltage that is equal to or just greater than the output voltage of the step up converter. You would also want the minimum input voltage to be as low as possible at the desired output current. Again choose a converter with a maximum output current that is several times higher than your maximum load current.

You may need to connect a capacitor on the output of the step up converter to get the ride through time you want. The step down converter may have an input capacitor that will help with this. Use the same calculation shown above. You will not need the series diode since the step up converter will isolate you from the battery already.

It would be best to use an oscilloscope to monitor the battery voltage, the output voltage of the step up converter and the output of the step down converter during high load conditions to ensure that the system is working correctly and the ride through cap is sufficiently large.

When choosing the step up and step down converters, you do not need to choose isolated types since they are usually more expensive than the non-isolated types. The input reference terminal (0 Volt) of the isolated type is not connected to the output reference terminal but is connected in the non-isolated type.

Re: Battery powered raspberry pi
 

I agree but I am not sure about the relativity of large currents.

The Nichicon super caps that arrived yesterday are rated for 200mOhms ESR.
I could have gotten them with 100mOhms at higher cost.

My intention was to charge them higher than the 5V and then accept the loss that will be present anyway because of the on-board Raspberry Pi linear regulators.

My previous example feeding from a 7805 was merely an example.

The rest is a great contribution to the topic. Thank you.

Re: Battery powered raspberry pi
 

I heard back from FIRST and they are willing to review a product using super capacitors. Of course you'd need to meet the same requirements with this project to get it on the approved hardware list as any other. Further they won't confirm or deny the rules in the future.

So there's the matter of making 10 of them.
Disclosing the testing.
Figuring out the costs.
Determining distribution so everyone can get one.
Potentially being asked to give FIRST enough for everyone free.
Explaining who your company is and what resources it has.

Of course the other take was see about making something like a Raspberry Pi laptop. Since there's no official approval for that I will now see if I can figure out how to approach that question.

In the meantime this does not solve the issue but it is neat (the plans are COTS what you build would not be):
http://blog.parts-people.com/2012/12...ble-rpi-to-go/

Further communication from FIRST representatives suggests that one could create a Raspberry Pi portable device that integrates a battery and a Raspberry Pi and it would likely fall under COTS rules of previous years. Again rules change so I am not sure how much risk someone is willing to take with this financially. I do have an idea of how to start.

Re: Battery powered raspberry pi
 

Our controls team is looking at integrating a raspberry pi with a vision system for a fall project. One question they have is on boot up time - the specs are quoting about 45 seconds. Has anyone had any issues with this, does it determine how it needs to be powered (breaker or direct), do you power up the robot in queue to give it time, and any other advice on integrating it to maintain connection through the match?

Re: Battery powered raspberry pi
 

45 seconds seems more than enough time. if you power it on when you place the robot on the field, there could be 3-4 minutes of time to boot that little guy up.

Re: Battery powered raspberry pi
 

I do agree about choosing a voltage regulator with the requirements. However, I would like to point out that there is a polyfuse. Just make sure your voltage regulator it able to put out the current of the polyfuse rating and put a 1000 uF capacitor to isolate the current spikes.

Off topic: Make sure you strip the Pi of all the software that you do not need because everything means greater power consumption and lower performance. You want to squeeze the juice out of the Pi during the few competition minutes. Put good load on the Pi, the Pi will do the work slowly but efficiently. For example: My Website run on a Pi. I have all sorts of other crapware on the pi too, but it still works with a decent result.

Also, why are you using a Raspberry Pi? It is one of the lowest power dev boards available, just better than the cRIO by a few times. You might try looking at a development board like the oDroid. The specs make it seem like a good one to use.

Along with removing the crapware to squeeze the juice out of the Pi, you might find it useful booting off USB with an HDD or even an SSD. I reduced my boot time twice by doing this. Also, SD cards die quickly when running an OS on them because that is against their nature. Booting from USB will allow you to use a more OS "Friendly" disk drive. Also, an SSD will be better becauause of the G-Forces on the drive in a moving robot. Also, how will you keep the SD card in place.

TO RDP to it, use SSH. It eliminates the requirement for an entire server like xRDP. That helps with development.

Re: Battery powered raspberry pi
 

^^Probably a bad idea to quote the entire message above! :D^^

Re: Battery powered raspberry pi
 

Hey guys,
What do you think about this:
http://www.adafruit.com/products/1385

Re: Battery powered raspberry pi
 

FWIW, the Beaglebone Black ($45) boots up in under 10 seconds using the native Angstrom Linux.

Re: Battery powered raspberry pi
 

My Pi server (devstuff.no-ip.biz) takes 1.5 minutes to boot to a point where I can SSH to it. However, it takes up to ten minutes to get to max efficiency, where it is done launching every application! Is there a way how I can benchmark the boot?

Re: Battery powered raspberry pi
 

To solve the boot time issue - perhaps put a circuit inline with the Pi's power that will use a dedicated battery until the robots mains come online? Two diodes and a capacitor will do or one can get fancy with a circuit based on something like the MAX6236.

HTH

Re: Battery powered raspberry pi
 

That addresses the problem but unless said battery was bought enclosed with the Raspberry Pi complete and off the shelf it violates FRC rules. There was a whole topic on ChiefDelphi about it this year (this topic actually so this is a restatement).

If someone wants to make such an item they need to be prepared to supply anyone that wants it to make it legal as COTS.

To get it approved outside of COTS they need to make several and go through FIRST engineering which will eat up this entire season between field testing and internal testing.

Capacitors are a grey area. For a real storage capacitor you should treat it like above. People have managed to slide high value capacitors into competition but run time would be uncertain.

Re: Battery powered raspberry pi
 

"The only legal source of electrical energy for the ROBOT during the competition, the ROBOT battery, is one of the following 12VDC non-spillable lead acid batteries:"

You missed the point of SWITCHING power sources. I'm not talking about storing energy anywhere illegal during competition. The battery (or whatever power source) used to boot the Pi is not on the robot "during the competition". You remove it after turning on the robot mains. If necessary to comply with the rules a second approved battery can be the source during boot time, similar to how many of us power the driver station or Ethernet switches (for debugging) between matches.

Re: Battery powered raspberry pi
 

I wonder if that would be considered legal. I can not say I have seen anyone do that on a competition field. Worth asking in the official Q&A though. Does address the boot time issue but not the potential for brown out.

Re: Battery powered raspberry pi
 

Agreed - hard to see how a Pi stays up in an environment where the voltage drops below 5V or so. But we should be able to approach the brownout voltage that would kill the cRIO.

Re: Battery powered raspberry pi
 

One of the last off-season tasks for FIRST 1296 is playing with the PiCam so I happened to be looking into quick boot times. Some solutions for booting quicker include using a class 10 SD card (faster transfer rates), compile kernel to use hard-float (faster math), remove all necessary services (less to start at boot time), remove unused kernel features (smaller kernel loads are faster), no DHCP (no searching for an querying DHCP servers), alternative user space startup schemes (other than sysV style), quiet console during boot (less time printing startup messages), customize/trim library contents and busy box features, etc.

The Pi runs embedded Linux and there are huge repos of advice out there to optimize the boot time. Many folks are booting Pis in 10 seconds, sometimes less. I'll post 1296 results here in a couple/few weeks.

HTH

Re: Battery powered raspberry pi
 

It would be nice if we could make the Pi boot a read only image, to a RAMDISK, and make sure that the Pi doesn't get corrupted on brownout. That way, just like the cRIO, just turn it off by flipping the switch!

Re: Battery powered raspberry pi
 

That is doable! And from other online users reports it would boot and run in 5 seconds or so using an initrd-style ramdisk.

Re: Battery powered raspberry pi
 

That would be nice! However, there is only 512 MB of RAM! It would be hard to fit the OS and the memory within the RAM, unless you get a special Pi with 3GB of RAM!

Re: Battery powered raspberry pi
 

One way to power a PI would be from the USB port on the CRIO? Since the CRIO is on the buffered 24 VDC power supply that would protect it from brown outs that the 12 volts bus is subject to. I have not personally tried this so buyer beware.

Re: Battery powered raspberry pi
 

The FRC-cRIO has no USB port.

Re: Battery powered raspberry pi
 

Silly me. For some reason I thought there was one. :o

Re: Battery powered raspberry pi
 

You can buy a USB module for the cRIO, but the FRC FPGA won't recognize it.

Re: Battery powered raspberry pi
 

For some reason I thought the 4 slot Crio had a USB port. Probably goes back to discussions about the Kinetic & old overused brain cells. By rule you couldn't use the USB module anyway.

Re: Battery powered raspberry pi
 

I think I should design a small lithium battery pack of something like 180mAh to be COTS legal. Maybe have an MCU to automatically switch to battery and send a signal to the Pi to shut down before a timeout (hard shutdown).

What do ya guys think about some system to get legal in COTS, to allow a small battery? Also, if I were to do something like this, what should be the communication? Also, note that I am aiming not for the RPI, but for devices like the oDroid, with a higher consumption. I think you'd be better off doing driver station vision than using a Pi!

So, I thought of a small LiPo Charger circuit, EXCEEDING safety standards, to charge the battery off the robot battery, or a computer mini-USB. That would go into a boost converter rated for 5V out, because a 1s battery means 3v7. Then, it powers an MCU, being the power manager, to tell the Pi to kill all processes and shut down. Then, the Pi, powered by a MOSFET will be disconnected by the MCU. Then the MCU will go into sleep/watchdog mode, waiting for the battery power to be regained, or the power switch to be turned off.

I think that if I can make something like this in the Christmas Break and get it FRC legal, probably by 2016, not before 2015, it could be a game-changer for one of the teams who wants vision tracking!


About powering the Pi/other SoC from the robot battery:
There are the power pins on the header of the Pi. There is an FRC-legal boost-buck converter with a 5-volt output. Please let me know if you would like a picture of it on Wednesday. That should do the work, much greater than what it is required because I think it is rated for either 3 or 5 Amps continuous! However, I do not know if that provides very tightly regulated power since it is a buck-boost converter, so I would put something like a 15V, 100uF electrolytic capacitor in series with the Pi to eat up the voltage sparks that could kill the Pi! That should get you rocking and rolling with powering the Pi at competitions. Other than that, has anyone tried a supercapacitor (one meant to hold a large charge and not release it instantly) to power a part of the Pi like the CPU/RAM/other important thing? This is the type of capacitor used in RTCs so they don't forget the time.

I think it is time for a modded Pi that has the ability to sleep, by turning off the processor and everything except the RAM. The RAM would be suspended to make sure it's contents stay where they are.


Also, I think there may be some ways detect when the match is over to automatically shut down the Pi. I think that may be the easiest option!

Re: Battery powered raspberry pi
 

That's a neat idea. However, you might want to think about how much work you'll need to put in for the reward you'll get. Designing and selling a raspberry pi battery pack is a lot of work, especially if you don't know that it will be legal in the future.

Instead of going through all the trouble to compile the linux kernel with hard float math, designing the battery system, and writing software to communicate between the cRIO and the pi. Something that seems as simple as the communication between the two devices can be really, really difficult and full of hard to diagnose bugs and glitches. Look at team 118, the robonauts. At week three in their build season, they have a robot that can outscore 95% of teams final robots. Their robot didn't move at all in the Einstein rounds in 2012 because of a networking issue between their onboard processor and the cRIO. Their network buffer overflowed and vxWorks crashed.

Most of the great cyclers this year (think 1114, 254...) didn't even have a camera, so you should look at vision systems from 2012. I'm not saying you should just copy somebody, but the expression "steal from the best and invent the rest" applies here. Many teams were quite successful with driver station image processing, either using the default tracking code and adapting it to run on the pc, or creating your own using openCV. 341's 2012 vision code is public, and was by far the best vision system that year in terms of simplicity, reliability, accuracy, and speed. Using a smartdashboard plugin works really well because you don't have to worry about sending data.

Coming from a team who spent a ton of time working with vision stuff, I could program 3 of our competition robots with driver station vision processing in the amount of time it would take me to design, manufacture, and program the raspberry pi + COTS battery pack.

Also, I'm not entirely sure how your battery pack will work. The rule says
"Batteries integral to and part of a COTS computing device are also permitted (i.e. laptop batteries),
provided they’re only used to power the COTS computing device."

which seems to me that a laptop, or tablet with battery is ok, but your COTS battery is not a computing device, and I don't think that you can resell a raspberry pi legally. The rule implies that the COTS part must power itself, and only itself. So you couldn't take one computing device (a laptop with battery) and power another laptop with it. Each COTS device must power itself, and there just isn't a raspberry pi with battery device.

By my interpretation of the 2013 rules, your COTS battery pack would be legal to power the MCU in the pack, and only that. No external devices can be powered.

Re: Battery powered raspberry pi
 

That's what I want to make legal. I want to make a device, only a single device, to be verified by FRC so that teams will be able to easily enable onboard computing without the cRIO! This shouldn't be rocket science. I would have to design it to make sure it is as rugged and strong as possible, so it exceeds what FRC will accept, and I would need to market it to them. My goal is to market it so well that FRC will come to me instead of me going to them!

Maybe I could start a petition to show FRC how many teams out of the ~5000 teams want this! I'm pretty sure that those teams doing powerful vision tracking would be the first ones to sign it!

By the way, do you guys think that I should use boost-linear voltage conversion, or boost-buck conversion. By boost-buck, I really mean, just boost the voltage to 5V. the later option would be more efficient and wouldn't catch fire if you tried drawing more than an amp. However, there would be quite some noise in the system! However, the first option would get rid of the voltage spikes, but send all the extra voltage/current to heat. If you input 13v2 to a linear regulator for 5v, you would get (5/13.2)% Efficiency, with the rest of the energy being directly converted to heat!

Re: Battery powered raspberry pi
 

I think you should reread the my last post.

If you're looking to have an separate processor with camera capable of processing image data and sending it back to the cRIO, then look at the CMUcam 5. It costs $69, which is way cheaper than a pi and a webcam, and I guarantee that this will be cheaper.

Also, it's a ton of work to make something like this work well, something beyond one person, or even one team could do. Just think, is it worth it to spend all the time, money, and resources of you and your team developing this solution when there are already solutions? Driver Station vision processing is proven to be as effective as onboard, and it's simpler, cheaper, and more reliable. You can't argue against any of these. When you say "it's not rocket science" it shows me that you haven't really spent much time with vision in the past. This stuff is tricky. One of the best and most technical teams in FIRST didn't move on Einstein because of a little glitch related to networking with a vision processing board, and some of the people who were involved in the development process were rocket scientists! You vision code needs to work early in build season so you have time to design your robot around it and test and tune. If you have detailed knowledge of the linux kernel, linux USB drivers, FFmpeg, OpenCV, networking, and a lot of programming experience, it is possible. Things that seem like straight forward and simple like installing the OpenCV libraries can be difficult and more time consuming than you expect.

Also, how do you plan on building the power supply? On a printed circuit board? Coming up with a good layout is tough. Trust me. If you don't know what you're doing, and you don't have a good design with an effective ground plane to isolate interference, all your electronics will be plagued by random freezes, resets, and other unexpected behavior.


If you're really set on using onboard vision, why not use a beaglebone? Or, wait until 2015, and use the dual core ARM processor in the roboRIO.

Re: Battery powered raspberry pi
 

I agree with the fact that driver-station vision processing is a great approach. However, there are still latencies. The comparison between onboard processing with the Pi and the DS would be totally dominated by the DS. However, if you were using something much more powerful, e.g. the oDroid, if the team is able to conquer doing it, that seems like a better option!

I am posting in this thread because this problem is not only in the Pi, but in many other SoCs that are suitable for this.

Of course I don't have much experience. After all, I'm just a student. However, I am very curious and try to research and learn everything I come across. This is another reason why I come to CD! I'm just like a human octopus! :D

I agree that without a plan, things will get out of hands quickly. Before I start anything, I brainstorm it and go through an engineering design process. Then, I draw a block diagram of what will happen, followed by a drawn diagram of the parts I will use and how they will be hooked up. From there, I will move to CAD and create a schematic. I first use something like Fritzing because that will help me breadboard things. I will fix errors that I find, then. Finally, I will CAD the thing in DipTrace, get the schematic down and then finally use DipTrace to generate a PCB layout. Finally, I make the PCB and then populate it with components. Then, I test it to make sure it works. I then start marketing it. I start a KickStarter, work on improving on it and raising popularity in it. Then, I will work on making it much more robust, by adding an aluminum case, over-rated heatsink and all sorts of other safety measures. Then, I will finally report the final product to FRC. Note: I have been calling it a product. It will be a product to be possible sold somewhere like AM or VexPro, but it will be non/little profit!

I actually have looked at the CMUCam KickStarter and really liked it. However, it doesn't seem powerful enough to work well!

I like to go with simplicity. I was thinking about a MOSFET-triggered, inductor-based step-up/down converter to slowly fill a capacitor to just 5v, +-.1v! I think that is in the working range of the Pi, and it should be a no-problemo, using a microcontroller to trigger the MOSFET. I wanted to use PID to do the voltage-holding!

Re: Battery powered raspberry pi
 

This is true, but you haven't done any research to prove the latencies have any effect. For instance, a 10 foot ethernet cable will be every so slightly slower than a 9.9 foot ethernet cable, but in the scale of FRC, it doesn't matter.

I guess what I'm saying is that you need to try driver station vision processing before you dismiss it as slow. It's slower, but it's barely measurable, and if definitely won't impact your robot's responsiveness, speed, or accuracy. You won't notice the difference. In fact, I'd be willing to bet that the pi will actually be slower. Most of the lost time isn't in transmitting, it's in encoding. The USB drivers for the pi are pretty sketchy, and even if you're using the axis cam, you'll need to play around with FFmpeg and compile it yourself for the pi in order to get any decent amount of response. The pi isn't really that much faster than the cRIO, especially running the distro of linux included with it. vxWorks (the OS of the cRIO) is pretty darn optimized in terms of networking with the camera/DS, unlike the sketchy USB and TCP stuff going on with the pi.

Re: Battery powered raspberry pi
 

Just one moment, before you get carried away. Now, I'm going to issue the standard disclaimer that last year's rules are not this year's rules, or next year's rules.

Under last year's rules, such a system would NOT be legal, or if it WERE legal, it would be impractical. Last year's R34 (should have) made that VERY clear: ALL electrical energy had to come from one of the two legal types of robot batteries, UNLESS the battery in question was integral to a COTS computing device, and only powering things connected directly to said computing device.

Now, there would be a potential loophole, if you happened to completely drain the battery pack before each match and charge it very quickly off of the robot main battery during autonomous--but that quickly goes south when you realize that the charging is going to take time, probably more time than the match.


Let me make this even clearer: As few as 3 seasons ago, maybe 4, the COTS computing device battery exception did not even exist. It didn't exist until AFTER a team managed to get a computer onto their robot under then-current FRC rules that extremely limited such items.


tl;dr: This ain't gonna be legal, or you're gonna be building and selling quite a few of them. And, as pointed out earlier, engineering only looks easy--get right down to it, and you'll have enough obstacles popping up to make you wonder why you ever got into this project.

Re: Battery powered raspberry pi
 

I agree. I'll have to say that the DSP on the Pi sucks too! I boot from a harddisk and I am barely able to graze the available speed! However, as I mentioned, even though I use a Pi as my WebServer, I'd hate to use it for vision processing. The DS would beat it by many times with the FPS you can vs the Pi!

But, I really don't see too much latency in using a communication method like RS232/I2c/SPI/CAN/DIO/Parallel/UART (similar as RS232, for those who don't know about it)/etc.

I have a good idea!
let me have a linux laptop acting as a router, running in school, running on the greatest-used channel. That way, I might be able to simulate the network conditions in competition. Note, there are many APs in school, so tons of WIFI interference is available.
The Linux computer should be running BackTrack-Linux, testing all the network parameters, like signal quality, etc. and recording it in a file. The Linux computer should also be running iftop, netstat and other utilities to measure the throughput etc. On the DS, the response times should be recorded to be analyzed. That would give a birds-eye view of what's going on!

Re: Battery powered raspberry pi
 

I might be wrong (about which topic) but I am pretty sure that a few pages back in this very topic I related that I communicated with FIRST about bundling a Raspberry Pi with a battery as a COTS product entirely outside of FIRST. They can not stop you from doing that. It does bypass the approval process that FIRST would require for the product to be specifically FIRST approved. If you try to pass through the approval process you will get a delay while it's tested and you'll have to provide free product (actually they would really like you to provide all of the items for all of the teams for free...I doubt that is conducive to being sustainable).

It would have to be designed to be safe because now the market in question is going to exceed FIRST (liability). Production would have to be demonstrated to be adequate for not just FIRST but the general market. The Raspberry Pi would have to be bundled as part of the product and it would have to arrive at the team assembled. As a start you'd have to address with Raspberry Pi the use of their name. I am pretty sure I have all the schematics and PCB layout for that board so you could clone it but again I don't know the legality of that with regards to the Raspberry Pi license (ask a lawyer I am not a member of the bar).

I disagree. If the bandwidth to the driver's station was in fact 100% reliable then it would dominate. The fact is there are multiple complications getting data to the driver's stations to analyze it. Bandwidth limits, potential wireless errors and other avenues for strange complications. Therefore there is ample handicap for the driver's station approach even with a lower performance system on the robot. Not to mention this makes the driver's station laptop even more a requirement for your team's robot so if something happens to that laptop your team might be setting up a crisis for a very expensive and potentially hard to get piece of equipment (I've seen teams get in deep trouble with powerful driver's station laptops).

Keep in mind your team does not control the field. If your team can't get your data to your team's driver's station and can not figure out why: you are out of luck. You can entirely simulate a vision system contained on the robot regardless of the presence of the field during development.

Using a PID like that is a bad idea. The surges alone will outrun your PID loop. You want to go over the voltage required for the Pi then step that down or linear regulate the extra voltage away as heat.

Re: Battery powered raspberry pi
 

Another option. Get one of the laptops on First Choice. They would be by definition legal since they are KOP?

Re: Battery powered raspberry pi
 

I was just in the middle of responding to something on the same point so I will quote this and that response below.

I am confused by why you would encode on your Pi if the Pi is doing the machine vision. Are you suggesting turning the Raspberry Pi into something similar to a Slingbox?

I admit to building an OmniVision CMOS camera with a ARM CPU built into it as a camera with integrated machine vision and some ability to stream samples back to another device over UDP. However the whole point was to do the machine vision at the camera. Think of it like the Axis cameras but more customizable.

(This next response also address's FrankJ's post above.)

This is a valid concern. When Team 11 first approached this problem this sort of additional complication was why we put a netbook on the robot. Drove it back and forth over the bump in the field a few hundred times with an SSD in it. Used a full copy of Ubuntu to attach to our USB cameras running a unnecessarily high frame rate (cause we could...it was more proof of concept and acceptance at FIRST competition on the field than anything we really needed for operation so we removed it mid-season). So far Team 11 has done this directly to V4L via Python and Java and via OpenCV. When you have the whole package with a really high performance processor and no obligation to get crazy making things it sort of makes more sense to use the package. The most important limitation is the price. You had to stay under the $400 cap. Good thing that the computing industry is constantly pushing down the envelope by quantity to the point we could get dual cores at several GHz, the SSD and plenty of RAM for that price.

The bigger question is: is the cost of this Raspberry Pi with the case and battery *really* all that good a decision for the price? The Raspberry Pi is cheap alone, but we are adding a lot to the package and that may just make it barely worth while. Though perhaps that's the challenge someone accepts and then they ignore that concern which is their right.

This is a faulty comparison. The cRIO because of the way it is developed for FIRST can not really deploy it's full performance for this application unhindered. I respect that FIRST did as they required to meet their criteria but as a result the cRIO is not offering your team it's raw and untamed performance.

This is the equivalent argument people used to bring against mainframes. Sure your DEC Alpha might be 1GHz and my Tandem Cyclone mainframe (CPU cabinets) is a mere 33MHz per CPU (times 20 CPU). However that Alpha is not using a VME system with a single large base of assignable interrupts it's using hard assignments with priorities you can't change. The Alpha is running a huge OS with a single disk system that won't evolve to the challenge. The DEC Alpha is not a true parallel system: it can not be fully partitioned to be asynchronous (where as a coprocessor on a FIRST robot is). There are many cases where a true parallel system can much more efficiently assign resources to simultaneous task than a single core or even cores in an SMP design.

As a result a mere clock speed comparison (which is almost never a valid comparison to start with between architectures) is going to be flawed badly. A purpose built computer only needs to serve the intended purpose as best as possible. A general purpose computer will always do a lot of things and make compromises as it goes.

The cRIO as implemented by FIRST is not specifically configured to be the best machine vision system it can be. It is an adequate machine vision system for a lot of circumstances meaning it's application in this regard is more general. It is notable that it can do this function, but honestly, can someone show me a working Java code example with an Axis camera (there is a piece of code but it does not work and I've had 10 people try to make it work)?

As stated previously: I prefaced this concern earlier by contacting FIRST engineering directly.

I've contacted them in the past about making several things for FIRST: electronic motor controls, robot based oscilloscopes, the 2015 FRC control system. FIRST's requirement for a COTS device is that production is available to be adequate for all takers. There is no line to blur. You want to claim something is COTS you are then selling it to *anyone* with all that entails.

If the design is done properly, if the intent is to form a proper business venture, then FIRST based on the current rules and the conversation I had with them earlier this year would be hard pressed to reverse course. Does not mean they can't but so what if they do.

Regardless: FIRST has no business telling anyone what business they are in. For example: I own several business and am an Assistant VP in a huge corporation. FIRST can say whatever they like about me or anyone else. The only thing they can do is throw mud as long as I am a responsible business person. I doubt FIRST will ever stoop to that or it would be very ungracious professionalism.

I bid on the 2015 control system. FIRST said they were going to pass. I put that technology to use in 3 other fields using my existing ventures. In the process of that bid I exposed information about my design and key points of development. In doing that I gave FIRST access they could use to wander off with those ideas. I knew what I was doing and I, as a business person and inventor, managed that risk.

If someone is willing to accept the challenge of creating and maintaining a venture to makes this, approach it outside of the FIRST circles and whatever FIRST does becomes >irrelevant<. So what if they won't let you put whatever you made on the robot. The entire point of FIRST was to achieve goals larger than FIRST itself. So whoever does this has a venture that sells sealed battery enclosures for the Raspberry Pi. I am willing to bet there is a market for that regardless of FIRST and if not you diversify (welcome to small business put on your safety gear it's a bumpy ride).

Major points of FIRST are to inspire and to educate. If that creates:
1. A new business with potential employees.
2. A student who is interested in learning about manufacturing and all it entails.
3. An avenue to incubate ideas.

Then FIRST has achieved the goals it set forth.

Course Yash101 really has to ask if this huge challenge is something worthwhile to pursue.
Cause soon enough you will be dealing with: lawyers, the State, the Feds, insurance companies and real deadlines.
Do not underestimate the pressure or the complications: good businesses and people fail all the time.

The good news is that with a finite scope of the project outlined, examples elsewhere of similar attempts, this is something a student could aspire to do. Though I grant all those with concerns: mind the safety aspects and do not underestimate the technical challenges (I have built several charging systems for electric vehicles, electronics and military application there are many crucial subtle details that must be considered and all of them are irrelevant to the casual onlooker - it may not be all that interesting to the onlooker but engineers need to be concerned with it).

Re: Battery powered raspberry pi
 

Added emphasis, as this is a point I'd like to address. One reason in particular that FIRST would be fine with having extra batteries integral to COTS components on the robot vs. teams fabricating their own devices with "integral batteries" is because there is already an element of safety to COTS devices.

A laptop or tablet manufacturer will have already designed out the risk to the lithium batteries in their device; they will have dropped and kicked and abused the devices to the point of failure many times over to ensure it is safe for the end user. While putting their device on a FIRST robot might not have been their intent, the forces involve should be pretty similar to the abuse the device will take in the real world.

The manufacturer is confident enough in their device that they're willing to take on liability when selling it.

Yash, you might be excited to take on the challenge of designing, prototyping, manufacturing and selling this device. You need to appreciate how dangerous lithium batteries are. Even if you pick a different chemistry, safety is still a very real concern for any electrical circuit. So much so, that you may even succeed in everything you do - build a working prototype, design it for manufacture-ability and all that, only to find that no one wants to take the risk in selling your device, so it never becomes COTS.

Just a heads up.

Re: Battery powered raspberry pi
 

Yeah. Thanks. I was thinking about starting with NiCad/NiMh, because it is hard to overcharge them to the point of explosion. I can have an MCU charge the battery to 95% and then put a very small amperage into the cell, to top it off slowly! I think that it still would be better to use a supercapacitor, with a tie resistor to discharge it automatically! I would like to test safety by: running it in a nitro rc car at top speed and ramming into steel (Bye bye, expensive RC car :(), and hitting it with a hammer with a force greater than any robot would receive! Also, I would like to short it out and see what will happen. Also, I wish to seal the case with some sort of rubber or teflon, etc. so no metal shards will get in. Also, there will be a fuse soldered onto the battery pack!

Basically, I want to torture the device with a greater torture than what could be received by the device under the worst case!

I just thought, how should the power be transmitted to the SoC? Should I have a USB port? A miniUSB for the chip, debugging and configuration (like output voltage, preset to 5V), and a USB A Female to power the Pi?

Re: Battery powered raspberry pi
 

With appropriate safety and supervision:

Throw it down the stairs into a concrete wall.

Bake it in the oven (not a microwave) while on and charging to say 120 degrees to simulate a hot desert day. Freeze it in the freezer.

Operate it near an open flame.

Put your wireless near it, put your phone near it, put an AM/FM radio near it.

These sound really dumb but your can find a lot of problems like that:
RF emissions
Temperature sensitivity
Mechanical sensitivity
Production of hydrogen gas from charging

Re: Battery powered raspberry pi
 

Even better, I can just toss it outside on a regular sumer day. I left my iPod out for 30 minutes accidentally (during a robotics presentation only) and the solder on the inside nearly melted! I will check for hydrogen production, but I doubt it will produce any. Using a NiCad, as previously suggested, it should be not problem. However, let me do a little research on the material. I have 4 WiFi routers and an area just full of wireless communications devices. That could probably help see if RF is any problem. Mechanical sensitivity is going to be there. I am going to try to make it more durable than CIMs, which work for multiple years!
Oh and yeah, they aren't really dumb. They are really just another way of saying, "the fact" or how to do a true safety test!

I'm right now working off a Propeller chip (I know it is a dumb idea, but It's good for prototyping until I get a PIC). I was thinking of a 1000uF electrolytic cap, shorted with a 1Mohm resistor, to slowly discharge it after the power is disconnected. A step-up-down circuit will bring the voltage to 3v, by storing the 12v in a capacitor to make it only a quarter full. This will then go to the battery. This will all be controlled by the MCU to make sure nothing bad happens. There will be a transistor controlling the charge going to the battery. A reverse-protecting diode will be on the battery pack. That diode will make sure the power goes back into the 5v boost converter in one way. The MCU will do the boot-converting too! After I draw the block diagram, I'll post it on CD or my server!

Re: Battery powered raspberry pi
 

Wow, that must have been a hot day. The solder in your ipod melts at 400 degrees Fahrenheit.

Re: Battery powered raspberry pi
 

It's nothing big! I live in the middle of the desert. Also, that is just in the summer! I just put it in the shade and it was good after 5 minutes, though hot to the touch! At least the magnets behind my iPod weren't demagnetized! Neodymium magnets demagnetize under high (read:low) temperatures!

Also, what about placing it charging inside a 500 watt subwoofer cranked up to full? I think that would be a good test, while being dangerous. However, it would get my neighbor's nerves!

Re: Battery powered raspberry pi
 

Here's my design so far. I need to now create a pats list and CAD a schematic! Time for DipTrace! Check out the block diagram, and let me know if I am missing something!

Re: Battery powered raspberry pi
 

I think you forgot to attach your design.

Re: Battery powered raspberry pi
 

Sorry. I didn't notice that CD doesn't support TIFs! I uploaded it, but I get CD rejected it! Here's a new version (PDF)!

Re: Battery powered raspberry pi
 

This is KINDA related so I hope folks will not mind if I ask this here. If people think I am hijacking the thread, say so and I will start a new one.

Sensors on arms, fingers, .... are always a pain the in the eye. I love them but pots seem to always give me fits.

I have an idea for putting incremental encoders on the motors (quad input, 2 pulses per motor rev.). Using these incremental encoders, I can have something like an Arduino keep track of absolute position. But, that means we have to zero the count at some point. Okay fine. We do that in the pits when we are always calm, cool and collected (kidding). But we often have to cycle power on the field. Not only that but we often have to move the arm or finger or whatever while the robot is powered off. There goes the zero point for the CPU that is keeping track of the position.

Yes, we could have a switch on the mechanism that gives a zero point but do you want to do that at the beginning of autonomous? probably not.

So... ...I want to have a laptop or some such that has an integral battery that could stay alive during the power cycles on the robot and could also be a USB host for the Arduino(s) that are counting pulses and also act as a bridge from USB on the Arduino(s) to the some ethernet protocol (UDP I suppose?) to get data to the cRIO.

It seems to me that this would be legal (assuming the 2013 rules apply in 2014).

What does the Chief Delphi community think?

Joe J.

Re: Battery powered raspberry pi
 

I think you are getting more complicated than the original problem of make a good mount for your transducer. I would only go down that road for a set of really good reasons. :]

Re: Battery powered raspberry pi
 

COTS laptop on the robot was legal in 2013, if under $400.
USB on COTS laptop to power another device like a camera was legal in 2013 (if that device is interfaced only to the COTS laptop).

Personally I'd use the Parallax Propeller for this, it has USB and the cogs lend themselves to reading encoders nicely, that said using that or the Arduino as a custom circuit should have been legal in 2013.

Keep in mind you are going to add at least 1 pound of weight doing all this.
Perhaps you can manage this with an Android device?

Re: Battery powered raspberry pi
 

Why not use the flash memory in the cRIO periodically save the position? The preferences class in C++/Java would be great for this. You'd have to choose when to save the data carefully, to avoid hitting the flash memory 100,000 write cycles. It could be as simple as press this button then power off the cRIO, or as complicated as saving it each time it stops moving.

Re: Battery powered raspberry pi
 

Maybe you have an example of this, but I'm drawing a blank as to when you're going to set your robot out onto the field without starting in some sort of standard configuration.

Have there been situations where you can't move parts on the robot without power?

Re: Battery powered raspberry pi
 

With regard to moving the robot with power down this happens all the time. But even if it happens only once in a while, do you want to be the team that has its auton mode freak because a field reset requires you to turn your robot off and on.

The problem with using a "know position" at the start is that this is a pretty squishy position in a number of cases. Not accurate enough to reliably shoot frisbees last year (at least for the one robot that I worked with, 3958)

The idea of writing to flash periodically, this solves many problems (especially just a quick power cycle without moving the robot). But it doesn't really solve the move while the robot is off problem.

I THINK that folks are saying this is legal. Is it wise? not sure. Time will tell.

Joe J.

Re: Battery powered raspberry pi
 

So far as I know you can leave a COTS laptop on the robot powered up and even if you couldn't it is easy enough to get flash storage on the laptop to suspend it.

It's not going to create a safety situation because the cRIO must be in control of the motors on the robot so having a laptop like that on the robot is not going to move anything with the cRIO powered down (otherwise it will not pass inspection).

Re: Battery powered raspberry pi
 

Nothing solves the "move while the robot is off problem" if you don't have an absolute position sensor.

What's the real reason for avoiding potentiometers? There are also magnetic angle sensors that serve the same purpose but lack the mechanical/electrical wear issue, and some of them don't need a physical connection to the rotating shaft.

Of course, one of the easiest solutions to the problem is to use an actuator that doesn't require feedback for it to go to a known position. Plenty of teams use pneumatic cylinders with very good results. You do need a problem that lends itself to that solution, however.

Re: Battery powered raspberry pi
 

Yes and no. If I can set the zeroes of the encoders in the pit and not have to turn off the laptop then I think I am all set because the laptop (and its children processors that are doing the quadrature decode) are keeping track even when the robot is powered off.

As to why? encoders on the motors are so much nicer from a controls point of view. With no backlash to worry about, you can have a nice tight loop controlling motor velocity, then have a slower loop controlling position. At least that is the theory. Once you have encoders on the motors, it seems like a waste to have to put pots on the joint as well. But, it is also a waste to have to put a PC on the robot just to keep your sensors alive so... ...it is a trade off either way.

It is an interesting idea (says the ME who doesn't have to implement the software or the electronics to make it happen!)

Joe J.

Re: Battery powered raspberry pi
 

Do you guys have a suggestion of a low-power MCU to use for the controls? I am currently thinking about using the propeller, but that isn't exactly low-power. It can draw as much as 300mA, running all 8 cogs at max, and all I/O at max threshold!

Re: Battery powered raspberry pi
 

If there is a similar rule about batteries integral to COTS parts, it merits asking the GDC if your idea follows the spirit of the rule, since your extra battery is powering more than just the laptop.

Also standard caveat applies - opinions on CD are just that, and they won't hold any weight during an inspection.

Re: Battery powered raspberry pi
 

If GDC says no they changed their minds. Team 11 asked for me years ago officially and actually had USB cameras on the robot powered by the laptop during competition. Neither year we needed the vision system. We expected different people to interpret the rules differently. So rather than take anything for granted we tried. So if FIRST rules against this now then they've changed the game and very likely we won't waste our time with a vision system again unless the RoboRIO in 2015 offers a better working example of Java performing this task.

FIRST could alter the rules to disallow custom circuits connected to the COTS device but in doing that you now have a can of worms for the connection between the COTS device and the robot. FIRST could clarify the rules about the COTS device being powered on or off but that invites an issue where the students now have to link the power to a battery or non-battery equipped device to the main breaker. A Spike relay for example driven by the cRIO to comply with other rules, and therefore extending the boot time of the COTS device with the cRIO boot time. FIRST could say that only COTS devices could be connected to the USB ports of a COTS device but then what if you need to cut the cord on the USB camera to route it around inside the robot? If you can't power the custom circuits for a COTS device from the COTS device are you allowed to splice power from the PDB into the USB device referencing a common ground (that could be a risky issue so probably not). Can we connect to opto-isolated devices and power them from the robot mains (there are opti-isolated USB cables). So obviously this opens the door to many other questions that will beg official answers because the window to alter the 2014 documentation is pretty much past closed at this point.

If the goal here is to interpret the rules so that there are no sources of power on the robot then that is not possible. Even if the main breaker is disconnected the robot battery and the wires to the main breaker are still very much live.

Also, back to an earlier point in this topic, if GDC now says the COTS device can't power accessories like a USB camera then someone needs to ask in the official forums about bootstrapping the power to the COTS device external to the robot with a FRC legal battery before the mains is turned on. I've never seen someone bootstrap power like that on a competition robot and so it should be asked anyway.

That sounds like terrible power draw but it really is not.
If 28 I/O pins are sourcing or sinking 10mA each that's 280mA.
As the circuit designer you completely control that aspect of the external circuit design.
So unless you as the circuit designer demand 10mA per I/O pin it won't exist.

So what you are really asking is for 8 processors with power management turned off (because there are power saving features in the Parallax Propeller) and windowed static RAM with 28 I/Os that offer a lower maximum current.

Keep in mind that the 1st generation Parallax Propeller is 3.3VDC so it's already demonstrating a common solution to powering that device from batteries (reduce the voltages and often the currents follow per Ohm's law).

So I would be interested...apples for apples...what is a better choice? 8 of the smallest lowest power MCU you can get plus equivalent circuitry will draw more current max. The only way I can think of to reduce the power further is strip features or further reduce the voltage and at some point you'll loose 5V tolerant I/O and then you'll need level shifters which draw power.

Re: Battery powered raspberry pi
 

Yeah. I did point out worst-case scenarios, but I think the Prop may draw 100mA at lease, commutating a boost converter. I'd have to set up an entire core to do a PID loop, when the voltage goes lower than 4.9v, pulse the boost converter. When the voltage gets higher than 5.1v, wait for it to drop to 4.9v, then pulse the boost converter. Running this a couple hundred times a second, with a pretty big Capacitor (5,000uF), that should be a good enough speed to give a very stable output of up to, maybe 5 amps!

The Propeller is quite picky about voltage, and requires an LDO regulator, because of their very high accuracy. Most other microcontrollers, like PICs, and some AVRs have quite some tolerance and will work from 2v7 to 5v! That would make the design process more headache free! Also, the Propeller has no built-in memory, something that even the BASIC stamp has! That means more chips, a higher price and more failure points! It also means that you will have a bigger board size! 28I/O seems quite overkill for a UPS, unless I make this an integrated lighting controller as well :D. But yeah, the Propeller's video generator means that We could have displays on the sides of the robot showing advertisements*, etc.

But yeah, that would be unnecessary fluff and would be 100% un-required for most teams!

You can already buy integrated lighting controllers, or maybe even individually-controllable ones to control from the cRIO!

I am looking for an MCU series that can be programmed in C. I'm in high school, so I don't have the time to learn ten different Assembler languages. Also, around 8-12 I/O would be nice, and a 4 channel 12 or 16-bit ADC would be nice, allowing me to ditch the MCU3204!

*Stuff about your team, not the stuff that comes on your TV!

Re: Battery powered raspberry pi
 

You can do that with an operational amplifer as a comparator you do not need an MCU for that. In fact some MCU I have used in power supply systems have integrated voltage comparators.

If your regulation is that loose you can not expect to measure voltage.
In fact you will not get close.

It has ROM masked for Spin and the lookup tables. There is no way 8 chips with the windowed RAM is cheaper or smaller than the Parallax Propeller QFP with crystal and external flash. Plus even the BASIC Stamp has external flash memory.

Even with 2 chips you still need a crystal oscillator and other parts and you might need a reset controller with something like the 8051.

As far as failure points you would have to mess up pretty bad to be better off. Unless you use the internal R/C oscillator in a cheap low end 8bit Microchip or Atmel AVR chip. Plus the external program storage means that if you kill that storage you save the MCU itself. Not so big a deal for an experienced user but an issue for the inexperienced or eventually it will become an issue.

Plus there's the whole: potentially needing a chip programmer issues you are overlooking unless you use some form of ISP (In-System-Programming). Never mind the potential need for a debugger which the Parallax Propeller to some extent already offers.

The QFP version of the Propeller is pretty small. There are smaller MCU but even the BASIC Stamp has an onboard regulator, external RAM and the crystal which will make the board bigger. Since most of the Parallax parts fit on a board that's about 600mil across to fit a 600mil DIP IC socket I bet you won't make this smaller without cutting some corners.

For example an R/C time constant will make your timers temperature sensitive and will drift.
Fine for something not timing sensitive but not so good if you need the timing of something predictable.

You do not need an MCU for this purpose. How is no I/O :).

If you don't need all the features of the Parallax Propeller then look at the 8bit Microchip PIC (like the older FIRST systems) and Atmel AVR controllers (you probably know them as Arduino). You probably don't want to learn how to use an Intel 8051 architecture or 6800 architecture so that is off the table because that tends to involve a lot of interconnects and extra parts. (There are about 1 dozen less frequently mentioned MCU I could put here but I won't because as a high school student you'll drive yourself nuts learning it just to discover it's not as standard in the industry). I will mention the Hitachi H8 because of the older LEGO Mindstorms RCX bricks. The lower end Microchip and AVR parts are even less expensive but in all cases you will be doing everything by sharing time on that single processor system. Expect to make choices with peripherals because to stretch that single processor further they add peripherals to offload specific tasks into logic within those MCU.

https://sites.google.com/site/propellergcc/

I believe previously you wanted to program in Java but here you go.
There are 100 or more other languages or ports available on the Propeller as well but that's neither here nor there.

Single ended or differential?
Muxed or unmuxed?

Muxed A/D inputs let you switch analog inputs but you can't read them all at the same time.
Differential inputs allow you to lift the monitored circuit ground.
The cRIO analog bumper is single ended, ground is the system ground, and even the cRIO uses an external ADC.