Anyone interested in a Linux-based robot solution?

[biojae]

Originally Posted by Greg McKaskle

The deep diving, at least in LV is the NIFPGA interface. This exposes accumulators, triggers, and other raw forms of I/O which the general and wading layers are built from. It should allow for alternate implementations, alternate frameworks, and external sensors and actuators to be added in. At the moment this is as deep as the pool can go since the FPGA implements the safety mechanisms, and it doesn't seem appropriate for teams to modify the safety layer. Ideally, that layer will be opened up too, showing how to do encoders, PWM generation, triggers, integrators, etc on an FPGA.

Is there a way that any of the implementation can be exposed?
Maybe only the things you mentioned (encoders, PWM, triggers, etc.) without comprimising any of the safety layer.
Even a screen shot would be better then the virtual "black box" that it is now.
Some knowledge of how the system works would help diagnose some issues, even if they can't be directly fixed (indirectly through bug reports).

[Greg McKaskle]

If you are pretty convinced there is a bug in something, I suppose we could give out a screenshot to help get to the bottom of it, but again, since this is the safety protocol, we wouldn't want any enterprising team to "optimize" it, resulting in someone getting hurt. So whatever we'd do we'd keep FIRST in the loop.

Trust me, NI and especially Xilinx would like you to have access.
Greg McKaskle

[biojae]

Originally Posted by Greg McKaskle

If you are pretty convinced there is a bug in something, I suppose we could give out a screenshot to help get to the bottom of it, but again, since this is the safety protocol, we wouldn't want any enterprising team to "optimize" it, resulting in someone getting hurt. So whatever we'd do we'd keep FIRST in the loop.

Trust me, NI and especially Xilinx would like you to have access.
Greg McKaskle

I haven't noticed any bugs, at least in what I have experimented with,
but as a non-FIRST project I would like to start working with a FPGA.

I understand the concern for safety, though it shouldn't be in every VI especially in the ones used for input (Accumulator, encoder, etc.).

Could the ones that wouldn't comprimise the safety layer be released somehow, or somewhere(Firstforge)?

[Radical Pi]

Not intending to derail the topic, but I guess it is somewhat related.

This is mainly to Greg: Is the possibility of including the FPGA module of LabVIEW in the FRC edition being considered? Even if FPGA code mods aren't allowed by FRC rules (similar to how the grey jags were made with CAN capabilities that weren't allowed in 09), it still would be put to use by teams doing off-season stuff with the cRIO that require FPGA changes (using different modules comes to mind). Even if it isn't FRC legal, the learning and experimenting with it (something I love to do) is great for the programmers (and great marketing too ). And on the safety problem, what about just giving us the regular code with the safety things stripped out of it?

[Greg McKaskle]

Personally I think the FPGA tools would be a great addition for offseason projects.

Perhaps you want to measure gas exchange in your local rain forest, or connect it to your neighborhood hadron collider, make an engine controller for your motorcycle, or send it up in a rocket to perform flight control, ... just as long as it doesn't involve driving somewhat powerful robots without the appropriate safety mechanisms.

At the moment I'd say your best bet is to write a letter or build a presentation explaining why you'd like the tools and asking for a license. Treat it like a fund raising event. If you need additional ideas, poke around on http://www.ni.com/solutions/. Send the request to either your local sales representative or to someone at NI corporate in the academic department. If you can't find someone, send it to me.

Greg McKaskle

[taichichuan]

Can anyone provide some idea of what types of safety protocols are provided in the FPGA? I don't need the specifics of the code, but if we're trying to simulate the system in software, we need to have an understanding for what safety we're trying to implement. Is it like a current limiting governor, or a sample rate limitation or what? And, did we implement any of these safety interlocks before the cRIO came into the picture? if so, how did we do it before the slick FPGA?

TIA,

Mike

[AustinSchuh]

I'm going to give my best educated guess, which will be pretty close.

Before the cRIO, the IFI system had 2 CPU's in it. One CPU dealt with communications and the safety protocols. Eg: if it didn't see a packet from the driver station within a set amount of time, it would put the robot in disabled mode and disable all the motors. We weren't allowed to change the code on that CPU, and could only change code on the other CPU in the system.

On the cRIO, I'm pretty certain that the FPGA kills the motors if it doesn't see a packet from the Driver Station within enough time, or gets a disabled signal, or gets an e-stop signal. So, it's serving the same purpose as the IFI system's second CPU. It probably also implements the watchdog. This makes it so that if we totally mess up the software as users, if someone tries to kill the robot, the robot will stop.

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

[taichichuan]

Originally Posted by AustinSchuh

I'm going to give my best educated guess, which will be pretty close.

Before the cRIO, the IFI system had 2 CPU's in it. One CPU dealt with communications and the safety protocols. Eg: if it didn't see a packet from the driver station within a set amount of time, it would put the robot in disabled mode and disable all the motors. We weren't allowed to change the code on that CPU, and could only change code on the other CPU in the system.

On the cRIO, I'm pretty certain that the FPGA kills the motors if it doesn't see a packet from the Driver Station within enough time, or gets a disabled signal, or gets an e-stop signal. So, it's serving the same purpose as the IFI system's second CPU. It probably also implements the watchdog. This makes it so that if we totally mess up the software as users, if someone tries to kill the robot, the robot will stop.

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

OK, that can be dealt with easily enough through a uP like the ATMEL ATMega. Also, Xilinx has recently announced some hard-core ARM and PPC440 processors w/ 10000+ FPGA gates on them that could be used for the safety and still run Linux. I was just trying to make sure there wasn't something more sophisticated.

Thanks,

Mike

[jhersh]

Originally Posted by AustinSchuh

To sum it up, you want to have some sort of safety system that won't rely on end user code (that can have bugs in it) to stop the robot when it looses comms, gets a disabled signal, or an e-stop signal.

You got it.

Originally Posted by taichichuan

OK, that can be dealt with easily enough through a uP like the ATMEL ATMega. Also, Xilinx has recently announced some hard-core ARM and PPC440 processors w/ 10000+ FPGA gates on them that could be used for the safety and still run Linux. I was just trying to make sure there wasn't something more sophisticated.

It can certainly be done on a different hardware platform... in fact the new Xilinx parts sound like a pretty similar architecture.

[Greg McKaskle]

Rather than go into the details, not sure that I'd do it very accurately anyway, find a way for the "dangerous" outputs to have a trusted element that can shut them down when things aren't updated or when the field explicitly requests it.

On the cRIO, there are several trusted pieces that pose challenges to each other to make pretty sure they are legit. The FPGA ultimately controls the PWMs, relays, and solenoids, CAN doesn't go through the FPGA, but includes info from the FPGA to generate the keys for the jag heartbeats. If/when this project goes further, ask for more details.

Greg McKaskle