FRC FPGA usage

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