View Single Post
  #15   Spotlight this post!  
Unread 31-03-2010, 10:35
mikets's Avatar
mikets mikets is offline
Software Engineer
FRC #0492 (Titan Robotics)
Team Role: Mentor
 
Join Date: Jan 2010
Rookie Year: 2008
Location: Bellevue, WA
Posts: 667
mikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of lightmikets is a glorious beacon of light
Re: Suggestion for next year's WPILib

Killing a thread is not too much a concern because it could be a controlled event (i.e. you can write code to monitor a termination event and clean up). It is the unexpected termination such as a fault that could be a problem although one can also use structured exception handling to do the clean up. However, it can clean up properly only if the code is expecting the fault (i.e. putting the code in the try block). In either case, if there are bugs in the code that do not expect a certain scenario, you can still hang the thread or fault without catching it.

Our code is also based on Iterative robot but we don't start a new thread. Instead, we have a structure that does cooperative multi-tasking. We also develop an event notification system and a generic state machine that makes the autonomous code almost script like. We could go further and write a parser to read a script from file too, but don't have time to do it this season.

The autonomous code looks something like this:
Code:
switch (state)
{
    case 0:
        // Do something such as drive forward 3 ft.
        // At the end of the drive, it will generate an event.
        nextstate = 1;
        WaitForEvents(event, nextstate);
        break;
    case 1:
        ...
        break;
}
The WaitForEvents is not blocking, so the code returns for executing other stuff until an event unblocks it.
__________________

Last edited by mikets : 31-03-2010 at 10:41.
Reply With Quote