Possible FLR Hacking?

[BrandonD-1528]

Originally Posted by Andrew Schreiber

Mr Ketron, I agree that your student probably jumped to conclusions but I have to wonder if this isn't something we should look into. What safe guards are in place to prevent such an occurrence from happening? What would the reaction be if it did occur (as far as FIRST goes)? How could it be proved (or disproved)?

Aaaand bingo, this was the aim of my post, to bring this to people's attention in case something similar happens. Thanks.

[Matt Krass]

Originally Posted by Chris is me

I believe the burden of breaking WPA2 alone is great enough to prevent this from being an issue, ever.

As mentioned prior though, some careful digging or social engineering might jump that hurdle.

After that, I'm not so convinced the system is that safe, it's worth looking in to. I don't think this particular instance is evidence of that, but I think it highlighted the fact it may be a problem. So far everyone has said that there was no hacking incident based on several plausible, likely explanations for the events that occurred. Other than relying on WPA security I haven't seen much counterargument about the 'hacking' not being possible.

Maybe I'm just paranoid, but that's my $0.020000000000000001 (Sorry, using an Intel...)

[BrandonD-1528]

Originally Posted by Matt Krass

Maybe I'm just paranoid, but that's my $0.020000000000000001 (Sorry, using an Intel...)

You sir have just made my day.

[BrandonD-1528]

I do enjoy eating cheese, or something...
[Post removed]

[Chris is me]

He was trolling. Ignore him.

[Matt Krass]

Originally Posted by Chris is me

He was trolling. Ignore him.

Agreed. You should probably edit the post and toss that log, its giving him the attention he wants.

....am I in your signature? Nice.

Matt

[BrandonD-1528]

Yeah, I figured as much. Pity.

And to Mr. Troll: My hair being red? Not so much

[Siri]

I'd just like to add that Sab-BOT-age isn't thinking this was malicious either. Yes, we had some drivetrain problems, but with a independent driven & steered, continuous turn swerve drive, there are a lot of possibilities as to why. It wasn't consistently debilitating (we were semifinalists), and in fact, our current theory is a mechanical issue.

Robots are complicated, and running 6 at once through FMS certainly doesn't make it any simpler. Things go wrong at every regional - no reason to assume maliciousness, though prevention is also an important consideration.

FLR rocks! Good luck to everyone identifying and fixing their Week 1 issues and see you next year.

[pfreivald]

I am inclined to blame all this on Secret Subroutine C.

Secret Subroutine C exists, independent of programming language and regardless of care, deep within the depths of all robot command structures, no matter how simple or complex, no matter how foolproof or failsafe.

You cannot find Secret Subroutine C.
You cannot eliminate Secret Subroutine C.
You cannot control Secret Subroutine C.
The best you can do is try to prevent Secret Subroutine C from executing, and minimizing the damage when it does.

Translated from machine code into English, Secret Subroutine C reads only one line:

"Run amok and destroy your masters."

[boomergeek]

I'm curious about the monitoring of errored packets and intermittent loss of connection.

Is that information categorized in the FMS by team number?

I think it would be nice to know if bad D-Link placement was giving some teams a significant disadvantage.

Since radio is essential to control and control is essential to safety. One might argue that radio functionality on the robot should pass some hurdle as part of robot inspection.

Team 241 had intermittent control problems at GSR- we were looking to blaming our own software or use of the CAN with the Jaguars or other things- it was only after the competition was over that we thought of actually moving our D-Link to a more radio signal friendly position on the robot.

If the problems don't show up at home base or in the pits or on the practice field, but show up on the competition field, it can be quite maddening. The problems seemed minimal on Thursday but got worse on Friday and Saturday.

As to robots moving and the joysticks not: it sounds to me that MotoSafety and/or watchdogs might be set to very long times( or removed) and connection to the DS was lost (or software took a long circuitous run through a loop).

[BrandonD-1528]

If I recall correctly, radio signals, including wifi, are blocked by metal. Teams should definitely not have their radios inside the metal frame of their bot, especially since the new radios have significantly lower power.

[Mark McLeod]

Originally Posted by boomergeek

I'm curious about the monitoring of errored packets and intermittent loss of connection.

Is that information categorized in the FMS by team number?

I think it would be nice to know if bad D-Link placement was giving some teams a significant disadvantage.

You can ask the FTA to monitor that for you and tell you after a match what kind of latency they saw. Ask before the match starts though. It's a lot more convenient to watch it than dig it out after the match. If something unusual happens on the field it's much easier to correlate.

Average trip (ms) is probably most important. You want this value below 20ms.
If it's higher, then you should relocate your radio.
The Missed Packet metric is not terribly useful, because it gets high when the Driver Station is on a long time before the robot or vice versa. It's not missed packets after communication is established.

[boomergeek]

Originally Posted by BrandonD-1528

If I recall correctly, radio signals, including wifi, are blocked by metal. Teams should definitely not have their radios inside the metal frame of their bot, especially since the new radios have significantly lower power.

Here is a random internet search for DAP-1522 performance...
http://evergbitswitchdome.blogspot.c...t-gigabit.html

"I noticed that the orientation of the DIR-655 and DAP-1522 made a difference in reported signal strength and data rate as shown in the DIR-655 console. So to make things work, do not forget to run some experiments to determine the best position of the devices to get the best possible performance... I am purposely trying to get my wireless sharing of my neighbors, and DAP1522 unusable, and I'm not exaggerating, 30 meters away. To be honest, there are 3 (not often, natural wood) between the walls and DAP1522 laptop - but still 30 feet? On the other hand, it could be a major selling point of fear that your neighbors might steal your wireless signal? Just buy a DAP1522! If you have a big house, or coverage area, is not going to cut it. But if you live in a small apartment, this thing is perfect."


The FRC competition field is a much more hostile environment than a typical apartment.

As far as I know, FIRST did not explicitly warn competitors this year that the new radio was weaker than in previous years. My guess is suboptimal radio placement on the robot that worked (well enough) in previous years does not work in a useable fashion with the DAP-1522.

Does anyone have any actual signal strength graphs as a function of orientation comparing the 2011 radio to the 2010 or earlier radio?

[boomergeek]

Originally Posted by Mark McLeod

You can ask the FTA to monitor that for you and tell you after a match what kind of latency they saw. Ask before the match starts though. It's a lot more convenient to watch it than dig it out after the match. If something unusual happens on the field it's much easier to correlate.

Average trip (ms) is probably most important. You want this value below 20ms.
If it's higher, then you should relocate your radio.
The Missed Packet metric is not terribly useful, because it gets high when the Driver Station is on a long time before the robot or vice versa. It's not missed packets after communication is established.

Mark,
Thanks very much for the reply. The issue is: if you are a team that already suspect your radio signal is a potential problem in some matches, then you already have already planned to move the DAP1522 to a more optimal location on your robot. Its really the teams that don't suspect that they might have a problem that need their attention brought to it: otherwise, they might assume their problems are sourced in other places.

It would be a nice enhancement to the FMS to get it to only report dropped packets that occurred during the timed autonomous and teleop periods. And that problems are available for all teams to peruse. Radio geeks can set out on a mission to rid all lost WiFi packets from FRC competitions:

Team 241 has gotten WiFi radio signal religion based on a maddening three days of debugging during a regional. I'll be instigating other teams to get their radios in more optimal positions.

Also interesting, the picture you show has two competitors with voltages under 10.25 volts.
Anything in that range should be flagged red and the data stored on an web or phone app. Then, both the Battery geeks and the Radio geeks can spread the word about their respective areas of expertise to teams that are clearly not understanding the trouble that they are tempting.

[Mark McLeod]

Originally Posted by boomergeek

Also interesting, the picture you show has two competitors with voltages under 10.25 volts.

That's where context becomes important.
Voltages bellow 10v are common during competition when the motors are all pulling the battery low.

The photo was taken during a match and the robots were on the move.

If the battery voltage is that low before the match begins, then teams will typically get a warning from the FTA/FTAA.

This is also why it's important to have your voltage feedback working correctly.