Robot Rodeo - fixing control problems

First, please read my post in this thread about how great the rodeo was:

I wanted to start a different thread to see what ideas there are about solving the problems using the field - we’ve had some kind of problem all 3 years such that we couldn’t use the field controls for start/stop and autonomous. We got in 4 qualifying rounds with 13 teams - if we’re going to grow this competition we’ve got to do better than 20 minutes between matches. If all 30 teams came that were invited we would have only had 2 rounds per team. It’s frustrating to get up at 4:00 am to get there at 8:00 for practice rounds that didn’t start until about 9:30.

The regional competitions have budgets of $100k’s to get up and running, work out the kinks, etc. - we’ll never have that luxury in an off-season but I’d like to hear what anyone has done or if anyone else has had problems with the field for their competitions. We had someone one the phone the whole time and could never get there - still don’t know if it’s hardware or software. The primary computer would never boot up to where it would run the program, and the field wouldn’t run off of the backup computer. Do we need to up the registration fee to pay for someone to fly down and work it out?

As a backup, next year SPAM is going to make a dongle box with a timer that we can plug into the competition ports for all 4 positions so we’re all using the same setup - that should help but it’s just a workaround. What can we do differently?

I think Innovation FIRST has done great with helping FIRST… but one issue I’ve always seen is that they have a tendancy to love to make their products work with only their products. Anybody who worked with a scoring computer this year knows what I’m talking about.

One of the major issues that Andrew Rudolph and I agreed on was that the electronics box and the scoring system were from 2 seperate fields. This caused major issues when working together. At the best-functioning point we had LEDs and E-stop buttons working on one side of the field, but nothing on the other and never any ball drops or sensors (they didn’t even get power) for the 10 point balls.

Here are a list of recommendations from what I’ve seen that could be done to improve things:


  • Simpler is better, having a backup system is a good step in the right direction, but by having so much stuff in the scoring computer (routers, custom-made electronics boxes, etc.), when one thing goes it all goes. For example, the router had issues this weekend but FIRST can only log in if the internet connection goes through the router built-in for some strange reason.
  • Create a simple override for the “brain” boxes on each side so that if the scoring computer DOES go down at an offseason event or something, you can still have timers work in-sync from one side of the field to the other… with 4 plugs, 1 for each driver station that will do the normal override to give each team it’s own radio channel… and have the timer automatically run autonomous and swap to driver control after the 15 seconds. This could easily be built by teams I’m sure, and like Gary said… coming up with something like that would be a great idea.
  • Ball release solenoids, just a plain bad idea… they always had issues


  • I think more time is needed for the programmer of the TacOps program to be able to debug. By the end of the season the software was running beautifully, but I know those first few weeks Rick Petty (I think that’s his name) was going crazy trying to fix 5 or 6 competitions on his own working 24/7.
  • Give more trust to the competition people themselves. For anything to be fixed, we had to provide an internet connection to allow FIRST to connect to run diagnostics, update team lists, add competitions, etc. At the UCF regional we had to run a really long phone line and sit there a few hours to update the software, and at Robot Rodeo we ended up running a 120ft cable trying to get an internet connection. It would be much much much better if there was a way to run diagnostics at the actual competition, as well as to be able to add team numbers and such… because it’s just a plain pain in the butt to connect to the internet with those things all the time… and if you can view the problems there you can fix them saving so much hassle.
  • I think Linux is a great OS, but I would much rather see a windows-based scoring program again. The reason for this is at Robot Rodeo we had issues with Linux on the primary computer so we couldn’t even get to run TacOps. I think most people that work with the scoring computers in the league have much more background in Windows than Linux (I know I certainly do) and can fix errors with Windows much better than Linux. Linux can be very fidgity at some points and if it dies, it’s hard to fix… especially at the competition site when you have no administration rights and need to get into Linux in the first place to establish an internet connection with FIRST.


  • Definitly need to work on compatibility when having field equipment inter-mixed. When FIRST ships a scoring computer from one field, and an electronics box from another, they should be able to work together smoothly. I think this also focuses again on simplicity and keeping everything consistent from box to box.

Best thing I can recommend is have one member of your team volunteer as field crew for a regional. After most regionals, a number of volunteers will stick behind Saturday night and help break down and pack up the field. There’s no better way to learn the internal workings of a FIRST field than to help the professionals tear it down. You’ll see where every part goes, and how it’s plugged in. I believe all the fields are standard to each other, so it shouldn’t have mattered that you got the electronics box for another field. I’ve been to Beantown Blitz and Battlecry@WPI, and everything runs like clockwork once you get used to working with the fields.

If possible, it’s also a good idea to set up the fields a full day in advance, because there are quirks that can take some time to iron out. That way, you can run a number of test/dummy matches the night before, and again the morning before to make sure everything’s working properly. And if there are problems, you can call someone in the afternoon instead of very early in the morning :slight_smile:

<edit> TacOps runs off FreeBSD, not linux. Both are Unix-ish systems, but there are some differences. Personally, I think it’s better off that way, running in a minimalistic X environment where not much can be changed. Yes, it’s hard to troubleshoot (for the non-unix oriented anyway), but it’s also a surefire way to keep people from playing with the system between matches.

The two people we selected to run the field did just what you suggested. Both of them volunteered at the Florida Regional; I think another really good idea is have the field delivered earlier so you have more time to de-bug; also it would probably be a good idea to hook up the electronics first thing while people are setting up the field to make sure all the sensors work; we were even going to test the field with our robot to make sure everything was working, but we were never able to get to get that far.

I also agree that the registration fee should be increased to bring in a professional person like they do at IRI.

Just my two cents worth.
Nathan Pell

Hmmm, there seems to be a common misconception about field failures and IFI.

As far as I know…
IFI has nothing to do with the scoring console, TacOps or any of the field control systems.

Though the console IS built in a RackSolutions cabinet (IFI’s Mechanical Side) but I’ve never seen any mechanical console failures, so I guess they did their part adequately…

Something to keep in mind.
Field Problems/Field Control Problems are NOT Innovation First Problems.

Yes, that is correct; we called Innovation FIRST not knowing anything and they told us the entire control “box” was developed by FIRST and they nothing to do with it.

Nathan Pell

OK i will add in to here for what sounds like your major failure was. The “tower” units for each end of the field have 2 controller connections on them, one of the is a true controller connection while the other is a no connection port. when looking at these boxes from the back where all the connections are, the upper right controller port is the NC. While these all started labeled correctly, some had NC written with sharpie but others had sticky labels. After time i have seen these sticky labels come off and either completely not be replaced or stuck on the wrong connection in a quick boxing after events. So if you have the connection on the NC port, while some things will still work, it will register as the e-stops on that side being “on” among some other problems. As i have said before i am more then willing to help out at events and having seen problems occur now at Robot Rodeo for two year going, i have talked to some of the people down there and next year if i don’t have anything conflicting on the time of RR in Florida, if it occurs again, ill be more then willing to come down and help out for the time.

Dez, I swapped them back and forth many times between the N/C and the true controller connection. That wasn’t the issue.