 |
Project Leads: Rachel Gardner and Shrey Majmudar Contributors: Date Completed: N/A
|
The Need
 |
As we had found with the FIRST Tech Challenge (FTC) teams, FIRST Robotics Challenge (FRC) teams needed an easy way to drive their robots both in practice and at outreach events. As you can see in the pictures to the left, FRC teams have the same classic problem of needing to carry a laptop around just to drive the robot. In fact, the team at our high school even uses a special marching-band-inspired harness to carry the laptop! Not to mention, the laptop itself is so slow, it is often referring to as the “lol-top”. Given this dire need, we rose to the challenge and vowed to create a better way. However, FRC robots use a completely different controller than FTC robots, so we had to make quite a few changes to the ChapR… |
Take One: the cRIO
| When we first decided to add compatibility for FRC robots, the cRIO was the robot controller in use. Created by National Instruments, it ran the user program and controlled the entire robot. Unlike the LEGO NXT (the only robot controller we were compatible with at the time), the cRIO did not have Bluetooth capabilities. Normally the ChapR works by sending information from the joysticks (also called game controllers) to the robot via Bluetooth. To solve this issue, we plugged in a Bluetooth-to-Serial dongle to the Serial port on the cRIO. This way, the ChapR can send its custom packets over Bluetooth, then have the dongle (in this case, the FireFly from GridConnect) pick up that Bluetooth. The FireFly then converts that Bluetooth data to Serial data, which it then sends in to the Serial port of the cRIO. Inside the user program running on the cRIO, we then translate that Serial data and then use the loopback address to send it back to ourselves (aka the cRIO). As far at the cRIO is concerned, it is getting all of this information from software running on a laptop (which is called the Driver Station in FRC). With this solution in mind, we began coding the compatibility in LabView, the program our affiliated team (FRC 2468) uses. After a ridiculous amount of work, we finally got everything working! There were a few minor bugs here and there, but we were gungho to start on the Java and C++ versions of the user program in order to extend our compatibility to ALL FRC robots. |  |
Take Two: the roboRIO
 |
…and then the cRIO was phased out in favor of the roboRIO, the new and improved robot controller (also from National Instruments). Only slightly bitter, we realized that the roboRIO actually made our lives much easier. Since the roboRIO ran Linux, it was much more open to development. Because of this, we were able to create a Linux daemon (a program that runs continuously in the background) to translate our ChapR packets. This program would be entirely independent of any user code, and therefore wouldn’t have to be written in the three different languages that FRC teams use. Also, it would live on the roboRIO itself, so it would only have to be installed once. Problem was, the roboRIO didn’t have the same RS232 Serial port that the cRIO had had. Our good ‘ole FireFly wouldn’t do the job. So, like any good engineers would do, we just added some sketchy wires and tried to get it to work anyway. As you can see in the pictures, it was not pretty. We abandoned that effort pretty quickly, settling on using the USB port of the roboRIO instead. We then found out that the beta release of the roboRIO code (which we luckily got to work with as beta testers for team 2468) wouldn’t allow us to access the USB ports. So, we jumped on the beta forums and politely asked for them to be opened. Turns out, our little request made it into the release code at the very last second! With the USB ports now opened, we purchased our very own Bluetooth-to-USB-to-Serial converter, which turned out to be helpfully named the FirePlug (also from GridConnect of course). With all of the infrastructure in place, we set about decoding the new packet structure. Poor (or crazy) Rachel spent about a week with WireShark and a couple of controllers, mapping each byte to a value, as well determining the various modes and whatnot. This meticulous, yet enjoyable work can be seen in the spreadsheets at left. With everything in place, we coded up our second take at FRC compatibility. The new code worked beautifully, so we went to a local National Instruments employee to just double check on a couple of points. |
Take Three: v1 of Comms for the roboRIO
| …turns out we’d been using v0 of communications, the original version created for the beta testing phase. The latest version was v1, which was much more sophisticated (and complex). Better yet, v0 of communications would be phased out within a year. It was an awkward moment. Still, more work meant more learning, so we went back at it. This time, however, we simply emailed said NI friend to get the packet structure. It was much simpler. Our only job at that point, was to work out the cryptic wording of the email and struggle through all of the bugs associated with the entirely new concept of TCP packets. Eventually, however, we got everything working. We’re now just writing up documentation and doing preliminary testing in preparation for a (second) beta release. |  |