[techhelpbb]

Originally Posted by FrankJ

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

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

Originally Posted by magnets

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.

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.

Originally Posted by magnets

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.

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

Originally Posted by magnets

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.

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)?

Originally Posted by EricH

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

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.

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