View Single Post
  #14   Spotlight this post!  
Unread 16-10-2009, 10:43
EricVanWyk EricVanWyk is offline
Registered User
no team
 
Join Date: Jan 2007
Rookie Year: 2000
Location: Boston
Posts: 1,597
EricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond reputeEricVanWyk has a reputation beyond repute
Send a message via AIM to EricVanWyk
Re: Team 2102 Problem With Control Interface

I was thinking unhappy sensor too, but the symptoms made me second guess that thought. My understanding is that they have no control over anything, period - each of the motors have their favorite setting (ramming or snoozing), and they just go for it when enabled. I'd think that with a sensor malfunction, unrelated components would still be ok.

This makes me think that while a unhappy sensor may be the cause, it can not be the underlying cause. It could be that the student's code isn't being allowed to run. For example, lets assume that the camera feeds that loop, and it became unplugged. In this case, the loop would be forever waiting for the camera to initialize and pass its reference in. Assume also that the drive motors were given a speed once elsewhere - for example, autonomous ended with the motors going forward. Assume thirdly that the watchdog is either disabled or mis-used, and we fing ourselves in a situation that closely matches theirs.

I know I made three unlikely assumptions in that analysis, but maybe it will trigger a neuron somewhere on chiefdelphi that will lead to a more likely scenario.

Could you post the code?
Reply With Quote