I don’t think your team has anything to be ashamed of about what Brandon did. He thought of a possibility and presented it in a clear and objective manner. The original post was devoid of unreasonable accusations and was well-written. I do not think anyone thinks worse of your team due to this thread.
Edit: That being said, there are numerous reasons why robots would act erratically. My team had a match where our robot would turn right every time our driver let go of the controls, but this turned out to be a fault with our control system. I think the joysticks weren’t zeroed correctly or something like that.
At the risk of being rude, it sounds as if you might be reacting a little strongly. Blake might not (and probably does not) know the situation, but I see no reason to respond snidely to someone who is simply offering their opinion. If there is perhaps, something more to the situation, then let it go at that.
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)?
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…)
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.
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:
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).
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.
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.
“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?
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.
