NI releasing/designing new controller for FRC

[Oblarg]

Can they just make an arduino a FRC-legal robot controller and be done with it?

[mman1506]

Originally Posted by Oblarg

Can they just make an arduino a FRC-legal robot controller and be done with it?

As Arduino lover myself I can say that would suck. The C-Rio's FPGA is much faster than a Atmega 2560. You would not be able to do on-board vision processing and code would have to be optimized to run quickly. It also would alienate all current FRC programmers (Arduino code is not C++, BTW)

[Hypnotoad]

You can't do proper vision processing on a crio anyways, so nothing is lost by using an arduino. I ended up just doing it on the driver station since the image had to go there at some point anyways.

[Gdeaver]

So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. Every team has the expertise to implement a low level ISR and can drop down and write directly to the hardware at the register level when needed? Your going to take a 9th grader and throw that at him? I think allot of people do not realize the power we now have available to us. Even the old IFI controller had two 8 bit pics in it. The vexters at least have an arm chip to play with. The only way teams accomplished complex things with the old IFI solution was some excellent low level code done by Kevin Watson. I can't believe the number of people that want to go backwards. There is a place for an Arduino in First. One of our students used an Uno and some leds to make a heads up targeting system for the driver. Got an award for it. We are using a Uno to read a 3 axis accelerometer, gyro, and magnetometer to make an IMU. Reading the 9 16 bit values over I2C and doing a bunch of triangle math is saturating the Uno. Yes, Arduinos do have a place in first. They make good coprocessors.

[dellagd]

Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.

[gluxon]

Originally Posted by dellagd

Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.

It does, and I talked to another person earlier in the year that claimed it did (yes, I would say he was reliable). Kinect's USB protocol is pretty open, so even if WPILib doesn't support it in 2015, I bet it will in a later year or someone will write a library to communicate with it.

[Hjelstrom]

Originally Posted by dellagd

Correct me if Im wrong, but does that poster say USB will be available on the "Athena"?

Naturally, hoping this unlocks the possibility of using the kinect without any extra computing hardware on the robot.

agreed! This was a big hope i had for the next controller and it looks like it will be possible.

[fb39ca4]

How about something like a BeagleBone or UDOO? They both have the i/o capabilities of an Arduino, but also have 1Ghz ARM CPUs (quad core in the latter) and Ethernet.

[mman1506]

Originally Posted by fb39ca4

How about something like a BeagleBone or UDOO? They both have the i/o capabilities of an Arduino, but also have 1Ghz ARM CPUs (quad core in the latter) and Ethernet.

The problem with the beaglebone and others is that they do not have a Real time operating system. This means that there is a delay when inputting data and things don't always work in real time. This becomes an issue for safety and a number of other things as proccesing can become delayed as you can not expect it to processe an input in a certain time frame.

While they do have I/O doing something simple like PWM generation requires special scripting.

[techhelpbb]

Originally Posted by mman1506

The problem with the beaglebone and others is that they do not have a Real time operating system. This means that there is a delay when inputting data and things don't always work in real time. This becomes an issue for safety and a number of other things as proccesing can become delayed as you can not expect it to processe an input in a certain time frame.

While they do have I/O doing something simple like PWM generation requires special scripting.

There was an alternative system that could handle that presented. What FIRST wanted was a company to be essentially already be in NI's/Vex's educational market with FIRST. So basically from the release date of the RFP to the time they made their decision you had to be in thriving production with a client base (less than 6 months).

I helped submit one of the bids and engineer the solution presented. The solution survived the bid. I would not waste this kind of time and money doing something like this if I did not have other plans for it (especially since it entailed writing a graphical language framework). I've not heard from the other team that put the Arduino Kickstarter up about my offer to simply hand them the same donation I gave them by the defunct Kickstarter.

Originally Posted by Gdeaver

So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. Every team has the expertise to implement a low level ISR and can drop down and write directly to the hardware at the register level when needed? Your going to take a 9th grader and throw that at him? I think allot of people do not realize the power we now have available to us. Even the old IFI controller had two 8 bit pics in it. The vexters at least have an arm chip to play with. The only way teams accomplished complex things with the old IFI solution was some excellent low level code done by Kevin Watson. I can't believe the number of people that want to go backwards. There is a place for an Arduino in First. One of our students used an Uno and some leds to make a heads up targeting system for the driver. Got an award for it. We are using a Uno to read a 3 axis accelerometer, gyro, and magnetometer to make an IMU. Reading the 9 16 bit values over I2C and doing a bunch of triangle math is saturating the Uno. Yes, Arduinos do have a place in first. They make good coprocessors.

I've been programming since before I was 10 and one of my very first embedded platforms was the Intel 8051 and yes I spent many an hour writing assembly interrupt service routines. So yes *if* someone had to do it there are people out there that could step up with examples as you also pointed out.

That being said not every processor needs to have interrupts. In point of fact I helped present a non-interrupt centric solution to FIRST for this RFP. You could put interrupt capable devices into the system but you did not need to. It worked by basically polling which normally would be very resource intense but you could cheaply put so much processing into what we presented it was not an issue. There was still plenty of opportunity to implement custom logic via programmable logic in the system if a very sensitive timing constraint arose.

Again neither here not there, The system we proposed is currently being prepared for use in a non-FIRST commerical hardened real time application.

[dtengineering]

Originally Posted by Gdeaver

So a little 8 bit controller with no fpu, no fpga, no native lan, no RTOS, and etc etc etc, can replace what we have now. ..... Yes, Arduinos do have a place in first. They make good coprocessors.

Based on my observations for the majority of FRC teams an Arduino... and I mean an UNO, not even a Mega or Due, would be more than sufficent to meet their programming needs.

The vast majority of teams would have difficulty convincing me that they really needed more processing power than a Due could provide.

Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway? It just makes you lazy! Sheesh.... grump grump grump.

(Where's a balding, greying smiley when you need one?!?)

Jason

[Michael Hill]

Originally Posted by dtengineering

Based on my observations for the majority of FRC teams an Arduino... and I mean an UNO, not even a Mega or Due, would be more than sufficent to meet their programming needs.

The vast majority of teams would have difficulty convincing me that they really needed more processing power than a Due could provide.

Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway? It just makes you lazy! Sheesh.... grump grump grump.

(Where's a balding, greying smiley when you need one?!?)

Jason

Except for that whole image processing thing...or all of the libraries that are needed. Arduinos don't have THAT much memory to put robust enough code on.

Think of all the stuff WPILib has in it. None of that would be available just because of memory restrictions.

[Jim Zondag]

Originally Posted by dtengineering

Back in my day a 1MHz 6510 CPU was just a good excuse to learn some assembler! What do you kids need all this new-fangled gadgetry for anyway?

My first robot used an Intel 8748 as the CPU. 64 Bytes of RAM...WooHoo.
This was cutting edge at the time.



Despite the modest hardware, we could do some pretty cool stuff...Sonar ranging, odometry, programmable course input, full autonomous functionality, etc. This was more complex than many FRC robots today.

[nuttle]

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!

[apalrd]

The only reason it's so darn hard to do stuff now is because of inefficiency in the current system - The WPIlib in LabVIEW is so unoptimized that it's nearly impossible to run code that uses IO calls faster than 20ms task time without saturating the CPU.

The fact that we're currently saturating a 400mhz PowerPC amazes me. I don't like the idea that we should just throw more power at it to deal with it, since there's no reason to need anything near a 400mhz PowerPC.

I have a project I'm working on right now that uses a bunch of unoptimized floating-point math, a whole bunch of interpolations, and runs in two high-speed tasks (TDC and 200hz - TDC is ~5ms at 12000rpm) plus a few CAN interrupts (Jaguars should learn about CAN interrupts...). Bandwidth on a 56mhz PowerPC (MPC536) is extremely low, last time I checked it was under 30%. PWM IO is done on a PWM/timer on-chip module (MIOS), angular IO and angular synchronization are done in another on-chip module (TPU) which I did not write code for, which is essentially an optimized match/compare/timer module with microcode engine to autonomously reschedule matches and trigger ISRs. Between the MIOS and TPU, all of the current FRC FPGA non-analog functionality could be implemented with similar host-side overhead. Code includes some high-speed PI and bang-bang controllers, and LOTS of table interpolations. I did no real optimization on the math, it's about as much code/math as a complex FRC robot.