A story about remaking the control system on one of our offseason demo robots

Several years ago, before I was on my team, we built a large air-powered t-shirt shooting robot. The intention was to use it at sporting events to shoot t-shirts into the crowd and show off some of the cool things we do…

Then we ran into some problems. The original design used an 8 slot NI CRIO-FRC, with all the extra stuff needed to make that work properly. This included the use of a Wifi router, which would come back to haunt us later.

The first struggle came when we wanted to reprogram it last year to use different timing opening the large valves. Since our license to WindRiver expired two years ago, and the new control system IDE was incompatible with the CRIO, we couldn’t reprogram it and left that for later.

The second struggle came during a basketball game. It wasn’t the first sporting event we’d ever used it on, but it was the first one I’d ever come to to drive. The previous week, we had tested out the t-shirt shooter at our school, and it had worked fine. But at the game, as soon as we tried to drive it more than 10 feet away from the computer, the Wifi lost connection and the robot stalled.

At first we had no idea what was going on. I went into the D-LINK router settings and tried to change some settings to rectify this. I hid the network, password-protected it, and set it to a new channel. My thinking was that all the people had come in and, looking for free wifi, had connected to our unsecured network. However, the problems persisted. There was just too much Wifi interference in the stadium. We were eventually able to find a relatively unoccupied Wifi channel, which still only allowed us to drive about 20 feet into the court and fire into the crowd from there. Not as impressive as we had hoped, given that this was the only game we were able to do that year.

So we have two major problems: We can’t reprogram the CRIO and we can’t use Wifi in a crowded stadium. Last year, we left off with this and as the season drew to a close, and forgot about it.

This year, we came back with a mind to fix those problems. Naturally, I was chosen to head up this. I decided to fix the controller problem by using an Arduino, which would hopefully eliminate the problem of using a computer, xBox controller, and Driver Station software, a problematic system for our purposes. I also wanted to fix the Wifi interference problem, but at that point I had no idea how.

Later, during a discussion with a friend whom I often fly quadcopters with, I almost came upon a solution: using radio control transmitters (the kind R/C planes and quadcopters are controlled with). There were still a few problems with this, namely, that most reliable transmitters use 2.4ghz, the same frequency as Wifi, so it would still be interfered with. Alternately, we could have used lower frequencies, like 70mhz or 50mhz, but these types of transmitters are old and don’t support frequency hopping, and we didn’t want a crazy 150lb robot attacking people due to interference. The second problem was that many R/C transmitters had joysticks and a few switches, but no buttons. We wanted at least one button to fire the air cannon, but we haven’t yet found one with buttons.

Recently, I was flying my DJI Phantom, and realized three things about it: The most important being that it ran on 5.8ghz, not 2.4ghz. The transmitter also has centering joysticks, which are perfect for use with our robot (we use tank drive). We could have had disastrous results driving from an R/C transmitter with a ratcheted throttle on one side. The Phantom controller, on the other hand, has no throttle ratchet, and springs back to the center instead. I also realized that the two toggle switches could be removed, and could be replaced with buttons.

I have one of these controllers for my Phantom: http://www.helipal.com/djipvp-16-5-8ghz-remote-controller-v2.html

It has two centering joysticks, two three-way toggle switches, and a variable lever on the side. This would only require a small amount of modification to use as our robot controller. I decided that we would replace one toggle switch with a panel-mount momentary button. Then we could use the up and down movement of the joysticks to control each side of the tank drive, one three way toggle switch to select which of the three barrels to fire, the button to fire, and the lever to control the lift mechanism of the barrels (we can change the angle). I may also install another momentary switch to activate our 130db truck horn, to alert people when we fire it.

Last week, I figured out how to send PWM signals to a Jaguar speed controller: https://sites.google.com/site/0123icdesign/arduino_jaguar and how to control spike relays: http://www.chiefdelphi.com/forums/showthread.php?t=95974

So that brings us to now, I have spend half the weekend programming an Arduino to decode SBUS, which is the protocol spoken by the DJI receiver module. I borrowed one out of my Phantom, and hope to get another one soon. I will be open-sourcing the code soon, with my modified version of the SBUS library.

Ok this was written several months ago, back when I completed the programming and testing of the code and control system. We have since soldered a protoboard for the Arduino to simplify wiring, and enclosed it all in a little box. If anyone wants code or more info on the connections, just ask (it’s kinda unrefined and messy…). I just recently found this file, I meant to post it a while ago.