Anyone interested in a Linux-based robot solution?

[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