Thread: Editing Main.c
View Single Post
  #2   Spotlight this post!  
Unread 31-01-2004, 10:55
Dave Flowerday Dave Flowerday is offline
Software Engineer
VRC #0111 (Wildstang)
Team Role: Engineer
 
Join Date: Feb 2002
Rookie Year: 1995
Location: North Barrington, IL
Posts: 1,366
Dave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond reputeDave Flowerday has a reputation beyond repute
Re: Editing Main.c

Quote:
Originally Posted by Astronouth7303
I have been thinking about this for a little while. Why not have 2 sets of initializations and loops? 1 for autonomous, 1 for regular. And while we're at it, include a HALT() routine. Here's my version. Where do I put the prototype for HALT()?
It's an interesting idea, but I'd advise against it. I looked at what you did at main.c and there's two major problems that I see. The first is that your code now depends on the fact that autonomous will be active when the robot is powered on. I don't believe this will be the case at the competitions. I'm pretty sure that last year, when you were setting up your robot on the field, the "Disabled" bit was set but the "Autonomous" bit was clear. Then, when the round started, it would change from "Disabled - no auto" to "Enabled - auto mode" in one packet. Even if they did plan to have the autonomous bit set when you plug your robot in on the field, there might be a delay or something - I wouldn't rely on it.

The second problem is that once your autonomous routine ends, there's no going back. This probably isn't such a big deal, but if somehow one packet from the OI comes down during autonomous mode with the autonomous flag cleared, your robot will stop autonomous mode and you won't be able to get back in. I highly doubt this would happen since IFI checksums the packets to ensure that they are valid before passing them to the user cpu, but still.. you never know what might happen.

Finally, your idea of halting the robot is interesting, but I don't see the purpose for it. Why would you want your robot to ever shut down? And more importantly, why would you want code to do that in there when you compete? I know our drive team would be rather upset if we had code like that in our robot and then a bug or something caused that condition to occur... Also, if you really want to have this halt option, it would probably be a wise idea to turn off all your outputs beforehand (PWMs to 127, relay outputs off, etc).