Possible FLR Hacking?

While it’s hard to not blame the FMS connection with the robot for being consistently pathetic as it has in years past (waiting for 3 hours in the stands to connect for a match), one unfortunate thing I have come to know in the last three years of FIRST is that not all of the thousands of teams go about competition the “right” way.

Also we found that before each match, the driver station computer should be restarted and booted up only in the driver account. this prevents any other programs from running. we has issues with the developer account which when started up didn’t always shut down processes.

We saw very similar behavior to what was described here…

…maybe Anonymous is coming after FIRST…

I realize that 10 volts is low (someone on our team put the wrong tag on it), but it was a little unusual to see a robot lose connection right at the beginning and regain it immediately when the match ends.

To everyone else, I know the hacking theory is a bit out there, and it is possible FMS was being a total butthead of a system. On the first day of practice matches they almost made us switch to the 2009-2010 gaming adapters because the field failed to connect to the new ones for a good 8 hours.

Of course, it turned out that the wifi in the gym there was interfering with FMS.

And to anyone who was at FLR, I really hope none of you tried to connect to the “Free Publlic Wifi” adhoc network.

Two points here, first, as mentioned earlier at 10V it would be very easy for the startup current of a robot coming to life to cause the radio to suddenly lose power, and the radios restart and reconnect time is roughly the span of a match. Its not unusual at all, it’s somewhat expected. Plus a battery at 10V after robot start is probably very near dead and is giving you ‘false hope’ readings because its under very little load. I can understand why at first glance, this doesn’t seem to be a problem, but I assure you it is a problem.

Second point, I’ve seen wireless networks with 20+ computers on them, actively operating in very close proximity for months at a time (ever see what happens on a college campus?) with no interference problems. The WiFi system employed by the field and robots should not succumb to the presence of one local ad-hoc network, it would never have been so successful in the household market.

Unfortunately I think at this point you guys have to suspect a problem on your end, I know it’s not pleasant. I’ve been in the shoes of “it couldn’t possibly be our fault, the field/wifi/arena/other team is messing with us” but I can assure you every single time the culprit has been less sinister. I urge you to take this experience and try to fine tune out any bugs in your system, and do whatever you can to make it more robust. This is the first contact for many of these systems and weird, new bugs are expected.


To everyone else, I know the hacking theory is a bit out there, and it is possible FMS was being a total butthead of a system. On the first day of practice matches they almost made us switch to the 2009-2010 gaming adapters because the field failed to connect to the new ones for a good 8 hours.

Of course, it turned out that the wifi in the gym there was interfering with FMS.

The volunteers at an event work with limited data. Calling them out for making you switch controllers is pointless. If you want to check every level of a problem do it yourself, if you want your robot working as quickly as possible cut some corners.


I am almost 100% sure this is the cause of your issues. Many of the components in the electrical system do funky things under low voltage, especially the jaguars and radios. Charge your batteries, you were playing on a dead battery which is never a good idea.

Uhhh… I’m not sure he was calling them out, I read it more as a “The field was acting up and they were trying some crazy things out of desperation”. Also, cutting corners? I’d never advise a team to do that, it never actually saves any time.


I was indeed saying this. Their theory was that the 5v radios FIRST supplied were too underpowered to be reached by FMS, which I personally didn’t believe. They ended up not switching to the old radios, because the problem was indeed fixed by RIT shutting down their wifi access points (there were like 20 of them in there). The volunteers did the best they could with what they had.

As for the battery thing, I’m aware that it was likely the cause of the issue. I just mentioned it because the robot didn’t seem to power down, though I now realize the bridge probably died on its own.

And once again I mention that someone on our team mistakenly marked that battery as charged, and we didn’t have time to check it before we queued.

I didn’t mean to sound harsh, sorry if I did, I just wanted to make it clear that as much as it might seem helpful to blame the evil forces of the field/etc, its only going to lead to more stress later. I hope you have a good season, and remember every time something breaks, it’s a learning experience ::ouch::

We were doing some testing with last year’s robot today, and it’s in pretty hurting shape. Even with a full battery, some very weird stuff can happen due to motors stalling. It is configured as a long-base 4WD tank drive with grippy wheels on front, slick wheels on back, and riding on carpet. Clearly, this configuration is really bad at turning.

Example of weirdness:
When we move the joystick full left or right, the robot sometimes shoots forward or backwards. We eventually figured that this was because one of the motors would trip its fuse while trying to turn, and the other one would then power the robot full-speed forward or backwards, depending on your direction of turn. So it ends looks like something un-commanded is happening, when in fact it’s an interaction of the underpowered battery, fuses, and environment.

This configuration should have no trouble turning unless it is direct driven by CIMS.

Everyone knows that every event does not get finished without a couple unsolved issues. One of those issues at the FLR was the few events were some robots seemed to be doing things on their own. I have seen similar things at other events every year. Is this worthy of being called hacked?** No.** Do I think my student jumped to a rash decision and posted this thread before he thought of what it is implying? YES Hopefully he has thaught of what he did so when we talk about it he will have learned a lesson and this will all be over.

FLR, was a great event. Thanks to everyone that put in a lot of long hours to make it a success. This was the first regional that the students on my team have attending and they had a great time. Lets give congrats to the winners, praise the great job that every team did and learn from our mistakes and get ready for the next week.

I realize that this was likely not hacking but it was still a possibility. I was trying to gather opinions with this thread, nothing more. FLR is still the best event I’ve attended outside of the Championship thus far, and I have nothing against any of the teams or volunteers that were there. Sorry if it came off otherwise.


The original post was coherent and well-written.

The discussion since has been calm, thoughtful and informative.

The topic is one that is always present and does not need to be kept locked away in the attic.

You are reacting very strongly to something, but I’m not sure what that something is. However, using only what is written in this dicussion thread as a guide, I see nothing troubling.


This too happened to team 3467 on Friday. The reason for this is when the voltage drops too low the cRIO will shutdown and restart to conserve battery power. We were out for about a minute before we started moving. This is one of the reasons that I will NEVER hit the stop button unless the robot is smoking or running about erratic.

Our team found similar issues both on and off field at FLR. We’ve traced control lockups to overuse of the cpu on the cRIO (or possibly the network stack), although we have no explanation as to why this would cause the code to fail without watchdogs tripping and all controls zeroing after a disable-enable cycle.

One other thing you might want to check out is the I/O board. We found that it occasionally goes crazy and crashes if the classmate is plugged into wall power (but never occurred on battery power).

For example, team 843, X-CATS, and Sab-BOT-tage all had their robots act oddly

Hey, I am the coach for 191 (X-CATS) here and although we did experience some issues (largely on thursday though), we never experienced any issues with our connection going in and out and the drives being altered during the competition. Not sure why our team is mentioned here. We have absolutely no suspicions of us being “hacked” during the competition.


Sorry about that. I didn’t think you guys were one of them, but I was told you were.

Well we noticed with us personally, that our autonomous was at fault for our disabling.

Sorry about that. I didn’t think you guys were one of them, but I was told you were.

Yeah its fine. The field staff did come and talk to us at one point after a match as they thought they saw our connection going in and out, so I’m guessing thats where you got it from which is understandable. It was kind of funny their reaction when we were telling them that everything worked fine and the drives went perfect (“you sure everything was correct? nothing at all went wrong? you sure?”). It sucks that that happened to you guys though, I would hate to not be able to preform on the field because of something that was out of your control.