Quote:
Originally Posted by magnets
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. This is, in a way, an approach to get FRC to waive the fact that it wouldn't be COTS allowed!
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.
|
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!