FRC Blogged - The 2015 Control System Request for Proposa
 

FRC Blogged - The 2015 Control System Request for Proposal, the cRIO, and Beta Testing

Blog Date:
Wednesday, August 29, 2012 - 15:51
Hello Teams,

What a busy week for the blog! A few more things to share:

2015 Control System Request for Proposal

We have recently opened the search for a partner or partners to provide a control system solution for the 2015 – 2019 FRC seasons. This is not in response to the Einstein issue – we started preliminary work on this project in 2011. Also, this does not mean we are dissatisfied with National Instruments! They continue to be a wonderfully supportive partner to FRC, and we wouldn’t be what we are now without their enthusiasm, hard work, and technology. However, our current agreement with National Instrument ends with the 2014 season, and we have a responsibility to cast our net broadly as we look for a new control system for 2015 and beyond. National Instruments has been very supportive of this process, and we expect them to be one of the companies responding to the Request for Proposal, which you can find a link to here: http://www.usfirst.org/roboticsprogr...pplier-toolkit

This Request for Proposal was developed with input from our Woodie Flowers Award winners, our Control System Advisors, our Control System team, and other key volunteers. We thank them for their effort and ideas.

The cRIO

Some folks have asked, with potential changes to the robot communication system for 2013, if the cRIO itself will still be used. Yes, it will. 4-Slot and 8-Slot cRIOs will still be used for the 2013 FRC season.

Beta Testing

Deadline for applying to be a beta tester is September 7th, at Noon EST. You can learn more about the process, and how to apply, here: http://www.usfirst.org/roboticsprogr...c/blog-8-16-12

Frank

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Wonder if they will still be using the DLINK radios

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Hopefully we can at least get a higher powered radio.

EDIT: This was on the page linked by the blog:

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

This.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Just read through the RFP. Looks like they aren't asking for much in the way of increased functionality over the current control system (other than a USB 2.0 host on the robot controller...and I'm sure I've overlooked other small details). I think that is smart - the current system is very, very powerful.

There aren't a lot of set-in-stone requirements when it comes to user friendliness/simplicity, packaging, environmental robustness, physical connectors, etc. Let's hope that the proposers really knock it out of the park in those areas.

The other interesting thing is the projected number of FRC teams each year, which to me is comically optimistic:
2015: 3,600
2016: 4,000
2017: 4,700
2018: 5,400
2019: 6,200

Then again, I'm sure these err on the high side just to make sure a supplier can hit "worst case" volume demands.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Am I the only one who misses the original Linksys gaming bridges? I find it silly that we have a radio that takes longer than the crio to boot...

-Nick

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Reading through the RFP, I had a couple of possible concerns:

Doe this mean it would be integrated into the robot controller? This would place a limitation on robot design, as the gyroscope needs to be as close to the center of rotation as possible to avoid drift.
In other words, we could end up with a control system that doesn't support current languages. How many teams would struggle learning a new language or interface if the one they're familiar with isn't supported?

How would an integrated solution work? For example, can you imagine the design challenge if the radio was integrated into the cRio? My team's design this year, with the cRio buried in the middle of the robot directly between the 4 CIM motors for the drive train, would not have been very effective.


Of course, all of these are very specific to the solution they end up going with. It's entirely possible that none of these are an issue.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

external antenna?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Programming is more about the thought process and problem solving than the syntax. That being said, a controller without some sort of C-like language would probably be a very low possibility.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

pBASIC is no longer supported. When I began as a mentor the control system was basically 2 Parallax BASICStamps. One did the communications and held it in buffer and the other was available to be customized with user programs. You had to occasionally read from the communications Stamp.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

They are also looking for 60ish laptops to support the Kinect station.

Did we already know this?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

It was said (by Bill?) that we should practice our Kinect over the summer because it would be "more important" next season.

(Kinect doesn't even play video games well :p )

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

While this is true (I've been programming longer than any student on my team has been alive, so I'm very familiar with process vs syntax, and have probably forgotten more languages than any student on my team actually knows), the syntax is usually a major hurdle for beginner programmers. There are also some significant structural differences between many languages that can provide serious problems for students if they try to switch. What if you're used to Call by Reference being the default in one language, then switch over to Call by Value in another? Someone who has only had a year or two of limited experience with one language would have trouble switching their thoughts over to the new paradigm.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

A couple interesting requests for the new controller that I noticed

Those would all be nice improvements to our current robot controller.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

The current cRIO does have user accessible flash memory.

The current cRIO can send all that information via visual means connected to GPIO or I2C on the robot even when disabled.
Someone would just have to make something to do it. Display devices could easily include: LEDs, a backlit LCD, light bulbs, low voltage electro-florescent displays.

There is no USB 2.0 Host support on the cRIO but you could put a COTS device on the robot like a laptop. However, I'm not sure that part is really a slam dunk. USB has 3 common modes: Human Interface Device (HID), mass storage, and CDC (serial communications). Each mode is rather complicated. Generally when you plug devices into a host port there needs to be a driver for that device. No driver means no support. So even if you could make a USB 2.0 Host port you'd need software support in the control system to make it work with devices. That's *a whole lot of devices*. Usually things that don't run Windows/Linux/BSD/Mac OSX have to be selective about the USB hardware that actually works. After all what's the benefit to the device manufacturer to make drivers for your unusual low sale volume platform (<10,000 teams...Microsoft can give that away and basically did with the Kinectx).

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Ought to be interesting to see if IFI is interested in once again being our control system supplier.

I'm sure many FRC mentors would rejoice at that concept. Sadly, I have a feeling that wont happen, either because IFI isn't interested anymore, or because FIRST might categorically reject a proposal from them. The old IFI systems were much faster to boot than even the 2009 cRIO-based system, which was the best one yet.

I also wonder if FIRST will be transparent with the FRC community about who is proposing?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I really can't see them being transparent in the process. I can't imagine the "you know what storm" that might erupt when a few thousand FIRST volunteer engineers each with their own pet companies and ideas debating this on CD.

Think Mac vs. Windows debate to the 10th power!

Things like this must be done with a limited committee of dedicated individuals.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Why imagine:
http://www.chiefdelphi.com/forums/sh...ntrol+proposal
http://www.chiefdelphi.com/forums/sh...d.php?t=105531

I'll be selling shovels ring side...

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

We still use ours for practice robots.
Even after a robot landed on it in 2010 and dented the case.


On topic, I am interested to see the possible solutions. I hope all of the developers will focus on simplicity before optional features, as I would much rather have a simpler system that always works than something even more complicated than what we have now that also has a USB2 port. That said, I would love more features if they are reliable and don't cost too much in terms of weight/complexity, especially if they're optional - such as a smart PD board that can optionally be connected to a CAN/LIN bus or left unconnected.

I also wish FIRST would give up on processing vision on the RC itself. Dashboard is fine, coprocessor is fine, just not the RC itself. It's already busy.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

They did not say they where changing just the contract was up, and doing they are doing due diligence. NI does not depend on making money from us to stay in business. I imagine a smaller company like IFI would. If not NI I would expect First would want another company with similar resources take up the challenge.

For reference look up a single seat license for the pro version of labview costs.

What bridge or other wireless solution gets used is a totally separate subject from the robot controller.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Maybe this research could be beneficial. I haven't tested it, but preliminary results are fascinating.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

No, I didn't read it like that. "Support" does not equal "integrated".Yes, in theory, but what other languages are there? A company promoting their product using some obscure language (FORTRAN 77?) isn't going to see a lot of business. Reality is, you will know at least one of the languages. (And if not, you learn. Like real life) No, I am having a difficult time imagining that. Seems trivial to me, but that may be just me...
Absolutely, and I truly hope they don't get all transparent on us in this case.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

And what is wrong with FORTRAN? My first programming language was FORTRAN IV

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Before there was National Instruments, with their fancy cRIO system for test and automation ..... There was the HP1000, a real time test and automation system that ran ... yes, you guessed it... FORTRAN

HP1000

Yes indeed, FORTRAN on the 1000 predated NI and the cRIO.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Don't be appalled by the lack of "required" functions and the many that are "suggested". That's to draw more options, so that one issue doesn't derail an otherwise capable system. Just remember, if it's not better than the cRIO, we won't be changing systems. The system will not get worse.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

So we go back to Fortran. Anybody have a card reader with a USB port? ::ouch::

We could go with a GE, Fanuc, AB, Siemens, ABB, ..... a host of others. They all have their own graphical language as well.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Sorry, let me rephrase. Most game developers at this point are not using Kinect very well. I am not sure if this is a limit of their time and budget or of the Kinect technology. However I have a hard time believing that a lot of FRC teams can do better with Kinect than the developers of a AAA video game (Steel Battalion).

http://www.theverge.com/gaming/2012/...y-armor-review (Might have strong language, I didn't re-read it too closely)

Although Steel Battalion has a bunch of problems aside from the Kinect control, the Kinect controls it is using are relatively simple and apparently fail to work well enough for that stuff.

Not to say that some developers aren't using Kinect well (see Double Fine's Happy Action Theater/Sequel): http://www.giantbomb.com/quick-look-...equel/17-6467/ (This one most likely does have strong language but I did not re-watch it)

Notice that the Happy Action Sequel mostly just uses detection to paint things on the scene and record the players.

Again, it's one of those things that is possible, but unless the bonus is VERY high, most teams will use that time to improve their in-robot autonomous, or spend more time in driver practice. If the bonus is very high, then you have the high disparity between teams who could get it to work and have enough experience, and those that couldn't.

Rereading your post, I think you probably weren't trying to refute me or anything, but after compiling the post I figure this is good information for everyone to see anyway.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I have an RS232 card reader and an FTDI adapter.

Therefore I have a card reader and punch with a USB port.

I also have 8" serial interface floppy diskette drives and a reel-reel tape unit.

You'd be surprised why I still have this stuff.

It was amusing to me that I have PDP-8 parts to fix things in museums.

Hey this RFQ askes for nonvolatile storage that'll hold data for 3 days.

Digs up my core memory...you asked for it!

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Oh, come on if we're going to go to tried and true systems, I vote for my first imbedded experience. An 8080 with numeric keypad programmed in hex and managing a 2K memory stack. Or my first closed loop feedback system on an analog computer programmed with jumpers. :ahh:

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

This thread has officially jumped the shark!

the old guy shark :)

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Hey I'd love to see new features that go beyond that RFQ that people want.

Let's see who can think out side of that box (hopefully within the galaxy).

BTW: I'm only 36 but I've been told I'm going on 80.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I'd love to see a simple, robust system that connects quickly and dependably.

Andy

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Probably the main problem is that the Kinect has enough latency to make it not very suitable for direct control of a robot (e.g. using your arms as the joysticks). Games have the same problem. The games that seem to work best are the ones where you are mimicing an action rather than directly controlling something. Kinect will probably be utilized nicely in a game design like 2008 where you can choose between specific goals or tasks.

I'm excited to see USB support being considered for the robot controller (lets get kinects on the robots!) and I still think there is value to doing vision on the robot.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Under the COTS rules you can put a laptop with it's own battery on the robot. That laptop could connect to a Kinect right now. You don't even have to run Windows there is work underway for Linux. It really doesn't differ in any way from the way the existing fields connect to the Kinect.

The issue with adding Kinect to just any USB Host, even if it has the hardware, is that you need the software for it. If you have say OpenEmbedded running you can get drivers. However, then you're back to robbing CPU time from the rest of the control system to process video. Also there are usually compromises made to reduce the resources of Linux to make it fit into a smaller package. For example uCLinux which doesn't need a memory controller. You still get something that is basically Linux but what do you compromise on in the process?

I guess it comes down to how bad do you want a PC on your robot before it just makes more sense to put a PC on your robot?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I think he knows that.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I am entirely against the Kinect as a robot control system. The processor of the driver station is a direct contributor to latency, and it conveys a large advantage to teams who can throw down a large chunk of change for a high end laptop. We already have one, so i don't say this out of self-interest. It's for the hundreds of cash strapped and rookie teams that will be put at a large disadvantage if it is forced upon them. Kinect in the robot could be very interesting assuming they provide the software on the crio side so all the teams can make use of it (assuming again that it's essential to the game as had been suggested).

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

It looks like FIRST is trying to help improve the Kinect "experience" for the 2013 season.

As other people have stated, I think that the correct implementation of the Kinect will be similar to the 2008 Hybrid mode. Where the game will have a Randomizer to determine the location of a game piece and the only way to tell the robot where it is located is via the Kinect or on board sensors.

-Clinton-

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I love this guy!

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

I'm kinda feeling this one

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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?

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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.

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

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

Re: FRC Blogged - The 2015 Control System Request for Proposa
 

Could you please elaborate a bit on what you meant by this?