|
Re: NI releasing/designing new controller for FRC
Sorry this is a little long, it is basically my thoughts on the control system. I want to get this out in case it is helpful in some way or stimulates discussion. I hope this isn't too late to be relevant.
Personally, I'd like to see the control system become more open. This could only happen if safety was ensured in a way that couldn't be compromised and if it didn't complicate things for teams that didn't want or need to make things more involved.
The main requirement around safety is having a fail-safe way to guarantee all output devices go to a known state when there is loss of contact with the field or driver station or when either of these things is used to disable a robot. Any sort of failure between the field/driver station and the output device must result in the output device becoming disabled.
To keep things simple, you really want something close to plug-n-play for a minimal robot control system, but that doesn't constrain what you can do to expand the system. This has parallels to how some teams do vision processing, using the CRIO, adding an onboard dedicated system to do this, or running this on the driver station (or simply not doing it at all).
I'd approach this by having smart modules that communicate over CAN (I know there are a lot of people who are uneasy about CAN, but this is more a reflection of what has been available in FIRST rather than the technology itself -- another topic, as another technology could be substituted if it were determined to be a better fit).
The CAN-based pneumatics module presented by CTR is a good example of this approach. A big piece of the puzzle here would be an excellent replacement for the Jaguar, a CAN-based smart motor controller. More on this later...
To round things out, you'd also have either something like a CAN-based digital side car or perhaps a CAN-based PWM output module and another module to provide general purpose digital I/O and analog input.
The next piece of the puzzle would be something similar to the 2CAN, but with a little more to it. On the Ethernet side, this would connect to the radio and provide bandwidth monitoring and management (including prioritization, particularly for upstream data) and would have several ports for local Ethernet on the robot (camera, PC, NI Athena, Arduino, etc.).
It would also be the interface to CAN (like the 2CAN) but would additionally provide the safety function and an output for the robot signal light. This would be totally closed with no user code. Safety heartbeats would be sourced from the driver station (or the field through the driver station) and flow via CAN to all control modules, probably using a dedicated line, as described further on for the smart motor controller.
This would allow the control module firmware on the smart modules to be opened up. A minimal system might only have a radio, the 2CAN-like router/safety device, and some number of controllers, plus power (you might even have power for the radio supplied by the router/safety device). The driver station could send commands that would be routed over CAN to the control modules to run such a minimal robot.
A more typical configuration would have a compute device of some sort (NI) and this would communicate with the driver station and the control modules. Other CAN-based modules that might be nice additions are an IMU and a high-current LED driver. The driver station would remain NI and not need to be changed much. In fact, the most typical robot configuration would be essentially as it is today, except that the I/O capabilities on the NI really wouldn't have to be used (they certainly could be though).
I'll skip to some detail on the smart motor control module, as this illustrates how the safety function is implemented. Again, sorry about the length! The rest of this is fairly detailed proposal for what is essentially an improved Jaguar (including more detail on how safety is provided), starting with some requirements:
- Master/slave mode where more than one motor can effectively be run by a single controller acting as the master and sending messages that determine H-bridge duty-cycle for slave(s) (for things like drivetrain with more than one motor being controlled using a single encoder for velocity or position feedback, avoiding the need to send encoder data to more than one controller; this depends on safety scheme described below to be safe/legal)
- Return position, velocity, and acceleration and allow these to be used for closed-loop control, same for output current and voltage (return only of input voltage and temp. as well)
- Properly handle indexed encoder (for position control with index providing position reference)
- Traction control (limited acceleration, cut power when slipping/too much acceleration or pulse power similar to ABS braking on command or when slipping)
- Can replace Spike relay module (might not be cost-effective, but should be able to control same loads and legal in these uses, including replacing two relays when reverse direction is not needed)
- Non-volatile configuration (remembers not only CAN ID but also mode and various settings so these are there from power up or reset; this replaces configuration jumpers)
- Setting that governs current limit that is based on list of legal motors (plus option for manual specification of this value, or no limit -- this protects the motors, the controller handles anything up to what it takes to trip the breaker)
- Consider reverse-polarity protection
- Support PID and bang-bang control algorithms (possibly others as well)
- Good status indicators (LEDs)
- Personally, I'd like to see the firmware opened up (again, safety considerations would require care here, see below)
- Really nice doc on theory, how it works, etc. (to educate and inspire users, plus allow people to work on the firmware)
- Consider using WAGO connectors (to match PDB)
Some possible parts:
- Infineon TLE7182EM H-bridge controller (there's a nice evaluation board available for this part and also some great FETs and other parts from this supplier)
- Fairchild FOD0710 Optoisolator (for any input that could involve a ground loop, not needed for sensors that only connect to controller -- used for the safety input, for example)
- LSI/CSI LS7366R Encoder handling with SPI I/F
- I didn't get to the point of selecting uC, but PSoC or uC with support for generating PWM, CAN, and SPI would be a good fit, also needs inputs for sensors, etc. (preceding part handles encoder, leaving limit switch inputs, potentiometer, and internal needs -- I used something more expensive and powerful than required in a prototype, there is a lot of flexibility here, something like Microchip dsPIC30F4012 would do nicely)
Other thoughts:
- Consider not including PWM input (if other controllers in product line have this covered)
- Safety uses H/W watchdog chip and resets H-bridge controller only (but not uC, or just gates off H-bridge inputs) and uses either the PWM input only for heartbeat, or possibly include a dedicated safety line on the CAN cable for this purpose (this is the cleaner/preferred approach, the safety line just carries a square wave from the router/safety device that directly feeds the H/W watchdog, causing it to trip if the signal is lost for any reason)
- There are parts that do H/W watchdog, power on reset, provide power for uC and external sensors, etc. (automotive parts are a good fit because they run on 12V, are high volume, and solve the a similar set of problems in a robust way)
Thanks for reading!
Last edited by nuttle : 14-06-2013 at 21:41.
Reason: some minor clarifications
|