FRC FPGA usage

[apalrd]

Today, I had a discussion with Eric Yahrmatter about the cRio, specifically the FPGA. We talked about the possibility of pushing hard RT tasks (especially PID control loops) to the FPGA, relieving the processor of the hard RT tasks and allowing it to do more functionally advanced things without worrying about bogging down the hard RT tasks.

Does anyone have opinions on opening the FPGA to teams? Opening the FPGA to hard RT tasks (like PID controls) would allow more freedom on the processor to implement processor-intensive tasks (such as vision processing) without worrying about the consequences of full CPU usage, and would make the control loops more stable and faster response at the same time.

If allowed, I would recommend that it be discouraged to teams without a good programming resource, as it could be more trouble than it is worth unless the programmer knows exactly what they are doing.

In case anyone is in the dark and has no idea what I am talking about:
-An FPGA (Field Programmable Gate Array) is essentially configurable hardware, allowing you to essentially write hardware. FPGA's can be used for very fast hard multi-threaded RT tasks, as blocks of hardware can execute synchronously - there is no single processor executing a single instruction. They are good for doing fast math operations in parallel.
-The FPGA in the cRio interfaces the hardware IO to the processor. In order to read the IO, there must be FPGA code which does the reading and returns the result to the processor (likewise in reverse). Currently, FIRST provides an image which must be used, which defines some standard IO (raw IO, PWM output, encoder/counters, accumulators, etc.)

Please note that we have not yet received our 2012 beta test information. This is pure speculation.

[Tristan Lall]

I'm not sure what to think:

1. I guess it would be nice to have an FPGA available for custom high-speed processing. Right now it's theoretically possible with an external FPGA, but the cost constraints make it quite difficult. Maybe you could run some of the machine vision on the FPGA as well.* (I'm assuming that there's lots of headroom available on the FPGA, but I don't know how many gates and I/O resources are necessary to implement common image processing tasks, and how many are absorbed by the existing firmware.)
2. It's easy to let this get out of hand. The < 20 teams that have the resources to program in VHDL are going to obliterate the competition with fancy autonomous modes, while the > 500 teams that have never had a proper autonomous mode will be that much further away from the rapidly evolving state of the art. (It could be roughly likened to giving teams large brushless DC motors, without providing a robust motor controller—but letting teams build or implement their own controller, if they can figure it out.)

Maybe the right balance could be that FIRST expands the capabilities of the default FPGA firmware in a modular fashion, while simultaneously permitting teams to combine both mandatory and custom VHDL modules (to be compiled by the team at their own risk).

*Or is vision already on the FPGA, and only being invoked by the program?

[connor.worley]

Originally Posted by Tristan Lall

The < 20 teams that have the resources to program in VHDL are going to obliterate the competition with fancy autonomous modes

I'm doubtful about this. FIRST has been leaning towards simple autonomous challenges. I don't think anyone will be able to properly implement something complicated enough that it requires the extra power, and even if they do, they're probably over-engineering things. Sure, open it up to teams, but I don't see it providing a massive competitive advantage.

[jhersh]

The FPGA is pretty full as it is today. It fails to meet timing 30% of the times it's built. There is no vision processing in the FPGA today. Given that the camera teams use is Ethernet based and not a raw sensor connected directly to the FPGA I/O, the cost of getting the image into the FPGA generally outweighs any processing benefit.

As for PID, the PWM interface to the motor controllers is so slow that the RT processor can easily keep up even when heavily taxed, assuming task priorities are assigned reasonably. The CAN interface is not directly accessible by the FPGA, so that route won't benefit either.

So far I haven't heard any compelling reasons to make the FPGA design open. However, the fact that the safety mechanisms are mostly implemented in the FPGA is a very good reason not to open the design. Potentially future technologies like partial reconfiguration would remove that concern.

I'm always open to evaluating specific feature requests for the FPGA design.

-Joe

[AustinSchuh]

Originally Posted by jhersh

I'm always open to evaluating specific feature requests for the FPGA design.

Not to hijack the thread too much, but could we get a couple more 4x encoder decoders? The actual encoder logic shouldn't be complicated enough that it uses a bunch of gates. I have known a couple of teams who have run into the limit.

[apalrd]

You don't need VHDL. LabVIEW can be used to program the FPGA.

I wouldn't mind a fairly plug and play architecture, with mandatory blocks and standard/custom blocks. To make space for custom blocks, just get rid of what you don't use (extra encoder modules, extra accumulators, SPI, etc.)

I'm not saying the FPGA should be opened. I'm asking what everyone thinks about either side of the issue.

[Al Skierkiewicz]

Joe,
Can you go into a little more depth on the safety issues with the FPGA? These are the used for field controls during a match, correct? Thanks.

[Tom Bottiglieri]

It's always seemed to me that the motors, controllers, and generally sloppy mechanical systems we have aren't good enough to warrant any control loops faster than like 1kHz. You should be able to hit that.

(assuming you think the gain in speed outweighs the risk of using the Jaguar controllers, which IMHO it does not)

[Alan Anderson]

I believe it makes a lot of sense to consider the FPGA the equivalent of the "master" processor of the old IFI system, and to keep it completely off limits for team use. It helps make the cRIO failsafe.

Right now, the only reason I would entertain for opening it up would be to let teams use presently unsupported cRIO modules.

[jhersh]

Originally Posted by AustinSchuh

Not to hijack the thread too much, but could we get a couple more 4x encoder decoders? The actual encoder logic shouldn't be complicated enough that it uses a bunch of gates. I have known a couple of teams who have run into the limit.

I used to have 8 of them, but removed 4 of them for space reasons. Part of the reason I selected them to remove is because the counters can already handle the 1x and 2x encoder cases. I think it's a good chance to teach engineering trade-offs (choosing where to allocate the 4x vs 2x decoding).

-Joe

[jhersh]

Originally Posted by Al Skierkiewicz

Joe,
Can you go into a little more depth on the safety issues with the FPGA? These are the used for field controls during a match, correct? Thanks.

The FPGA has a hardware watchdog timer that will stop all PWM, Relay, and Solenoid signals in the event that the RT processor does not indicate that the FMS is still allowing the robot to run. By keeping the FPGA inaccessible to teams, we can ensure that this functionality is not compromised and hence the robot is fail-safe.

-Joe

[Greg McKaskle]

Can the FPGA can be opened?
Yes, technically it can.

Why is it closed in the first place?
It implements the safety override, putting the robot outputs into a safe state ...
1. whenever the FTA chooses
2. whenever the drivers or coach or anyone else punches the estop button
3. in those situations when the team code is not updating outputs -- watchdog
3. when the RT communication stops receiving driver station communications

--------------

Rephrasing the topic slightly to focus on better control options.
What mechanisms would you want enhanced control over?
What sensors will provide the rapid measurements?
What actuators will provide rapid response?
What timing numbers are we talking about? -- milliseconds, microseconds, nanoseconds, or what?

I rephrased the question because plenty of RT computers don't have FPGAs. They have a realtime OS that allocates the CPU carefully using enhanced scheduling features such as priorities. The cRIO has those features AND and FPGA.

The default code really doesn't use these mechanisms by default because they are a bit more complex, but once a team has the basics under their belt, the next thing to do is to measure the performance, identify issues, and IF the problem is code latency or jitter, you reach for the RT features of the language/OS. If the problem is slop in your chain or gear train, better code timing may not be the best approach.

If there are other things you want to use the FPGA for, what are they?

Greg McKaskle

[Al Skierkiewicz]

Greg and Joe,
Is there a way to store a value in non-volatile memory somewhere. It might be a great diagnostic tool to know what command might have executed just prior to a shutdown. In the finals this year at champs one team would lose all function several seconds into the match. It did not appear that it stopped at the end of auton but just slightly after. The team was stumped as to what when on.
Al

[Alan Anderson]

Originally Posted by Al Skierkiewicz

Is there a way to store a value in non-volatile memory somewhere.

The entire cRIO filesystem is non-volatile memory. To store a value for later inspection, just write it to a file.

It might be a great diagnostic tool to know what command might have executed just prior to a shutdown.

A cheap way to do that sort of diagnostics might be to write the value to the Driver Station display. Each new value will overwrite the previous one, and the last value to be displayed will remain there until the DS is shut down. The "value" that gets printed can be a nicely-formatted, easily-understood text string.

[Al Skierkiewicz]

Alan,
I am thinking this needs to be something that can't be over-written by accident, can easily be retrieved by someone in the know or can be ported to a file on the FMS. As you know, I hate seeing a robot fail on the field with no way to determine the root cause other than to suspect a programming error by a zealous software person or an intermittent electrical problem. "Just the facts, ma'am, just the facts."
Was it a link failure, a power failure, a code failure, a hardware failure? Even if the error code can be ported to the indicator to flash a code, that might help teams (check engine flash codes). I (we) feel all too helpless when we see a robot fail match after match for a whole weekend without the ability to take corrective action. Our limit should be one failure per weekend per team. I witnessed that at every event I attended. Personally, I don't like winning when the opposition is down a robot and I don't like being incapable of helping.