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.