View Single Post
  #8   Spotlight this post!  
Unread 12-04-2014, 19:21
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,793
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: Errors at Colorado Regional

In general, scouters and anyone sitting in the stands for that matter are really bad sources of random data on robot/field troubles.
I used to be one of them and I remember how wrong it all looks from the distance of the stands.
All they ever take notice of is that a robot isn't moving (yes/no).

Folks in the stands can't know the difference between a drive team choosing not to move (strategic, threw a chain, because the robot will break), a Ref disabling a robot for transgressions (dragging bumpers, outside starting configuration), a Driver Station issue (poor default power mgt settings, low battery, bad USB/Eth ports, unplugged USB/Eth), or a robot issue (wiring loosening up after being hit all day, code errors, DSC shorts or CAN wiring glitches that prevent driving but leave all other functions running, low battery dips rebooting everything).

Because the robot side of FMS is so simple, network problems are easy for the field crew to spot and deal with.

If you want to be scientific and gather actual data rather than anecdotal evidence, then scouters have to:
  1. Ignore driver station positions in their reports (avoid confirmation bias-position can always be looked up later if it's important to you).
  2. Note the RSL (solid off or solid on - not blinking) when a robot stops moving.
  3. Note the team light (e-Stops are highlighted by the bottom yellow light)
  4. Send drive team scouters to inquire at the team pits for the reason for the robot non-movement (only the drivers know, often not the pit crew and certainly never random team members)
  5. Use pit scouters to ask how much testing time the robot had before the event. Face it, the vast majority of us build a robot in 6 weeks and collision test it only at the competition - that's why teams are shaking bugs out all through Championships.
  6. The absolute best is to inspect the team Driver Station logs, not that teams are likely to let you look at them, but you can check your own. The robot is actually providing the data, so any loss of comms is pretty obvious, because the log goes blank. If it comes back again, then your robot rebooted. If the data is there all through the match, then your comms were good.
  7. Volunteer for field duty - they keep logs on all robot failures.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 13-04-2014 at 09:36.