FRC Blogged - The 2015 Control System Request for Proposa

[Billfred]

Originally Posted by techhelpbb

Let's frame that:

Simple as in all in one piece with no room for wiring error or simple as in connect these wires here...here...and there?

In the current system the connect time is determined more by the D-Link robot AP and field than the cRIO. Point being: where is the line between the control system and accessories that FIRST provides?

To elaborate if someone makes a system that can boot, connect, and be ready to run in < 15 seconds. Then a user comes along with say a laptop and that takes 1.25 minutes to boot added to it is that an issue for the control system developer, FIRST or the user?

What about the amount of time to upload software into the control system?

Just curious.

I can't speak for Andy, but to me, the benchmark of "a simple, robust system that connects quickly and dependably" remains the 2008 control system (with the 2005-2006 breaker panel). The cRIO era has had some pluses, but you can't beat opening the package, wiring the robot, turning it on at the breaker and being able to drive three seconds later. (You'll notice I didn't say anything about imaging, setting IP addresses, or even downloading some user code.)

I'm not married to the IFI system, but it is my point of reference on things related to (re-)connection speed and simplicity.

[Paul Copioli]

Originally Posted by FrankJ
NI does not depend on making money from us to stay in business. I imagine a smaller company like IFI would.
Common misconception. My understanding is during IFI's run of making our control system, Rack Solutions was their big money maker. With the introduction of VEX they are obviously doing more than fine without FIRST.

Cory is right. Last year FRC business (including team sales of the Victor and other FRC specific items) was about 1% of VEX's business, not IFI's business. If you include Rack Solutions and that little toy company called Hexbug, then I imagine it is less than 0.3% of the total IFI business. So we would not depend on the revenue if we decided to propose.

Paul

[AdamHeard]

Originally Posted by Paul Copioli

Cory is right. Last year FRC business (including team sales of the Victor and other FRC specific items) was about 1% of VEX's business, not IFI's business. If you include Rack Solutions and that little toy company called Hexbug, then I imagine it is less than 0.3% of the total IFI business. So we would not depend on the revenue if we decided to propose.

Paul

I love this guy!

[ebarker]

I'm kinda feeling this one

[FrankJ]

I stand corrected. I did not realize how large IFI is & certainly did not mean anything negative. They certainly have control systems that will work. If they choose to put forth a request expect it will be good.


Hard to tell the revenues since they appear to be private. But I am guessing that they are much smaller than NI. Which was my original point. Of course being private they are not dependent on market opinion....

[AdamHeard]

Originally Posted by ebarker

I'm kinda feeling this one

That's actually what I meant to link to, made a mistake in my haste.

Very potent guy for that price and packaging. Maybe with such a system we could get one in each year's kop?

[ebarker]

We have one of the VexPRO ARM9 controllers. Unfortunately we have not had that much time to use it, but we can update this thread as we move through it.

[Richard Wallace]

Originally Posted by Paul Copioli

So we would not depend on the revenue if we decided to propose.

I really hope you guys will submit a proposal. IFI has demonstrated capability to deliver systems that perform well and reliably, at attractive cost.

If an IFI proposal is selected by FIRST, I will rejoice for two reasons: (1) teams and participants will benefit, and (2) such a selection will indicate that two very accomplished and extremely innovative guys have found a way to put past differences behind them.

[Gdeaver]

I think everyone is is forgetting just how much the FPGA does on the robot controller. Most arm socs have at most 2 hardware quadrature encoder channels and limited counter timers. Also the modules that plug into the C-Rio have significant protections built in. One thing I always hoped NI would comment on was how much was lost by having the WPI layer to support Windriver and Java. If NI only had to support Labview and they had control of everything, how much different would the system be? Could we have been able to use their Can module? Would the system been more robust? This is important. If the the awarded company does not have total control of the system and there are many entities involved, then the chance of problems goes up. If the system has to support many software environments, then the problems increase and support becomes a nightmare. The power PC chip is an old man in the processor world and Intel, AMD, Via, N'vidia all have cutting edge solutions. Who in the market has a commercial product shipping today with the robustness of the C-rio and modern hardware that we can afford? I'm drawing a blank. The one thing that complicates the whole First system is machine vision. How do we support it. It's the most hardware demanding thing that we do.

[techhelpbb]

Originally Posted by Gdeaver

I think everyone is is forgetting just how much the FPGA does on the robot controller.

There's more than one way to approach this issue. The real advantage of the FPGA is it's flexibility which no FIRST team can really tap in the current system. One doesn't need to know VHDL or Verilog to get a circuit into an FPGA there are graphical tools to help with that.

The issue with things like encoders is that they produce outputs that are encoded and can do so at a high rate. There is always going to be a motivation to put something like that on a hardware interrupt. If your interrupt driven CPU is fast enough then that can work. However, in all honesty, for something state centric and subtle like that logic is just a better fit. So certainly the FPGA as a programmable logic array is a very elegant solution to providing what might be a considerable pile of gates and might need to be altered (puts down my wire-wrap gun).

Originally Posted by Gdeaver

The one thing that complicates the whole First system is machine vision. How do we support it. It's the most hardware demanding thing that we do.

I think the issue with machine vision isn't merely the question of having it exist as a function. It's a question of a team's approach to the result. One team might want sample code that works just handed to them with minimal effort. One team might want a PyGames example that just works with some need to get it running. Someone might want to use OpenCV to get to professional machine vision tools, but still others might want to tackle the problem as a raw stream of data. I'm not sure there's a reason to discard any of those approach as they lend themselves to diversity.

To me the solution is to separate the machine vision from the control system enough that they cooperate with each other very well but the diversity of the approach is not restrained. Someone could always make a 'standard machine vision module' that you could just slap on the robot for those that like the feature but can't deal with the details.

[Racer26]

The cRIO is, and has been since its debut in 2009, a sledgehammer used to drive a finishing nail.

Simply put, FRC teams simply don't require the horsepower it provides.

Further to that, its excessive horsepower has enabled teams to get sloppy with their coding, resulting in 100% cpu usage, communication failures, and more.

Many FIRSTers out there will remember the CMUcam that we used to use, paired with an 8bit microcontroller, and serial 115kbaud radio, and the impressive things teams were able to do with that (hint: robots haven't really made order of magnitude shifts in capabilities, despite the communications stream being ~540x faster, the on-board processor being ~50x faster). The only really notable capability in my mind, is the ability to stream video from the camera to the DS. Which could easily be done by a newer microcontroller on a robust 802.11 based setup, without resorting to the sledgehammer that is the cRIO.

[BigJ]

Originally Posted by 1075guy

The cRIO is, and has been since its debut in 2009, a sledgehammer used to drive a finishing nail.

Simply put, FRC teams simply don't require the horsepower it provides.

Further to that, its excessive horsepower has enabled teams to get sloppy with their coding, resulting in 100% cpu usage, communication failures, and more.

Many FIRSTers out there will remember the CMUcam that we used to use, paired with an 8bit microcontroller, and serial 115kbaud radio, and the impressive things teams were able to do with that (hint: robots haven't really made order of magnitude shifts in capabilities, despite the communications stream being ~540x faster, the on-board processor being ~50x faster). The only really notable capability in my mind, is the ability to stream video from the camera to the DS. Which could easily be done by a newer microcontroller on a robust 802.11 based setup, without resorting to the sledgehammer that is the cRIO.

While I agree, I feel like it is a LOT easier for me to use doubles with the kids and not have to do hacky-ish integer decimal place preservation stuff like I did back in the day.

At this point the students should be learning how to program and solve problems given to them, not wrestle with limitations of the hardware or learning embedded software engineer levels of optimization. I feel like making the robot work with the entire rest of the team putting everything on your shoulders "working within constraints" enough

This is all just my opinion, but a simpler controller without sacrificing the ability to freely program is fine by me.

[techhelpbb]

Originally Posted by BigJ

While I agree, I feel like it is a LOT easier for me to use doubles with the kids and not have to do hacky-ish integer decimal place preservation stuff like I did back in the day.

At this point the students should be learning how to program and solve problems given to them, not wrestle with limitations of the hardware or learning embedded software engineer levels of optimization. I feel like making the robot work with the entire rest of the team putting everything on your shoulders "working within constraints" enough

This is all just my opinion, but a simpler controller without sacrificing the ability to freely program is fine by me.

This raises for me a question...

Which do you hold more important:

1. Floating point math
2. Threading / multiprocessing

The cRIO's support for floating point math is admirable.
It surely does reduce the need to explain the basic math.

However, personally, I've found that trying to explain how to build a state machine or get threading to work is bigger challenge. Just explaining how interrupts work is an exercise in digital processor design.

If you had to trade floating point math for a clear decisive ability to do multiple things basically at the same time without having to 'fudge' it which is the greater necessity?

[apalrd]

Originally Posted by techhelpbb

Which do you hold more important:

1. Floating point math
2. Threading / multiprocessing

This is actually a really hard question.

I would say that floating point math helps the inexperienced programmers more than threading does, since threading is usually fairly complex to implement and dealing with fixed point or unsigned math is usually confusing.

On a related note, I think the PowerPC is more than adequate for our needs.

[techhelpbb]

Originally Posted by apalrd

This is actually a really hard question.

I would say that floating point math helps the inexperienced programmers more than threading does, since threading is usually fairly complex to implement and dealing with fixed point or unsigned math is usually confusing.

On a related note, I think the PowerPC is more than adequate for our needs.

What if you can get software based floating point math instead of hardware floating point math?
This would mean the library would be slower than hardware floating point math.
This would also mean you'd get a clean example of how to use the library for people new to programming.

Would you be willing to use a library for it, in exchange for a simple way to do 6 or 7 things at the same time without threading?