FRC Blogged - The 2015 Control System Request for Proposa

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

[Ether]

Originally Posted by 1075guy

its excessive horsepower has enabled teams to get sloppy with their coding, resulting in 100% cpu usage

I have a modest proposal: Can we use a phrase other than "100% CPU usage" to describe the situation where the code is not meeting its deadlines?

Many well-designed safety critical systems use the CPU 100%: They have a low priority background task which uses all available CPU when none of the higher priority foreground tasks are running. So "100% CPU" is not necessarily a bad thing.

Perhaps the phrase "throughput margin" captures the intended meaning.

http://www.nasa.gov/centers/dryden/p...ain_H-1860.pdf


http://www.chiefdelphi.com/forums/sh...d.php?t=107733

[Jon Stratis]

And other well designed systems are designed to use extra CPU power for useful purposes, such as SETI@HOME, or any similar distributed-computing projects that look at a variety of computationally-intensive problems.

100% CPU usage can be an indication of poor coding, but it's not definitive. The real issue is, as Ether indicated, a question of being able to process critical tasks in a reasonable period of time.

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

[Hjelstrom]

In my experience with students, having to deal with integer math limitations and the details of hardware interrupts on the old system was a constant problem. On the cRio, they have gotten by just fine with simple single-threaded code. Also, this depends on the language. For example, multiple parallel tasks seems pretty simple in LabView.

Anyway, I would pick the fast cpu and fast floating point over multi-threading/etc.

[Gdeaver]

Real Time. The old IFI controller relied on the skill of the programmer to implement a real time structure. Very difficult for the beginning high school student. Just part of the job for a embedded engineer. Labview and Windriver are RTOS and we have watch our programmers learn the real time mentality. I doubt we could implement our swerve code with out the niceties of labview. Our student are pushed to the max but do manage to get the robot functional. I can't see them having success with out the high level support we have now. For our robots it's not cpu utilization that is important. It's that certain processes are executed exactly when we expect them to be. A RTOS and multi-threading Makes this Easier.
Machine vision. we need to have support and a plan for it going forward. Memory, CPU cycle, bandwidth, Co-processing system. If support isn't built in we are going to see all kinds of problems going forward.

[Greg McKaskle]

Perhaps it is useful to make a clearer distinction between the concepts and the implementations.

A SW library and a HW library for floating point are interchangeable provided they meet timing requirements and give the same answers. In fact, the PPC is RISC and does some float math in HW and some in SW. Even CISC processors will not do everything in HW. Both are implementations of the concept of numerical math operations on continuous number line approximating real numbers -- useful stuff.

A given computer can carry out at most N instructions in parallel. N is a hard limit imposed by the HW design. For a single-core, N is one. For a multicore, it is 2, 4, or maybe a higher number, but this is the upper limit. It is up to the SW to keep the cores busy but still produce the correct results. Threads, interrupts, and other concepts can act as SW work-arounds to the HW limits and even with these, multiple cores are often under-utilized.

So similarly, multi-tasking can be implemented in SW or HW, or more likely a combination. But in a time period, say 20ms, it can swap tasks numerous times and effectively get a number of things done. If the swapping is fast enough compared to the time period we are measuring, it is indistinguishable from HW parallelism -- gives the same results -- useful as well.

So my answers would be ...

I want easy access to mathematical operations that make robotics clear and accessible. This includes floating point math and IMO includes vector and matrix math.

I want to easily specify operations that are sequential and those that are parallel and the synchronization points. The FPGA already does many tasks in true parallel, so this lightens the need for this, but plenty need remains.

Editorial Comment:
Comparing implementations, threads are a gory and primitive way of specifying parallelism -- IMO. They are rather standard, but also very error prone. Even if you are going to implement in threads, it is nice to be able to think and specify operations in a higher level abstract language so that you can have a clearer design. And yes, I think this is one of the strengths of the data flow approach that LV adopted. I believe I am a better user of threads, semaphores, and the like because I know LV.

Greg McKaskle

[Jared Russell]

Give me a hardware FPU before you give me threading...every day of the week.