Quote:
Originally Posted by slavik262
When you talk about iterative being similar to how you've programmed in the past, are you referring to the default code of previous years? WPILib was available for the past two years and previous versions resemble the "Simple Robot" class much more than interative.
|
I was referring to the MPLAB C code not the old WPILib.
As Kevin pointed out the main reason for doing this as opposed to a switch is abstraction and cleanliness of code. With the power behind the new controller I am not to worried about using dynamic memory allocation or STL containers. Also this method opens up an interesting path of possible polymorphic state.
I've attached an update version that has been refactored a bit. The AddStateCallback method is now SetStateCallback method and the template only takes two parameters. I was able to change it so the third parameter is inferred.
Update example:
Code:
#include "StateMachine.h"
enum AutoState
{
AUTO_START,
AUTO_TURN,
AUTO_GOAL1
};
class MyBot : public IterativeRobot
{
private:
StateMachine<AutoState, MyBot> *m_state;
public:
MyBot(void)
{
m_state = new StateMachine<AutoState, MyBot>(this);
m_state->SetStateCallback(AUTO_START, &MyBot::Autonomous_State_Start);
m_state->SetStateCallback(AUTO_TURN, &MyBot::Autonomous_State_Turn);
m_state->SetStateCallback(AUTO_GOAL1, &MyBot::Autonomous_State_Goal1);
}
~MyBot(void)
{
delete m_state;
}
void AutonomousInit(void)
{
m_state->SetCurrentState(AUTO_START);
}
void AutonomousPeriodic(void)
{
m_state->CallCurrentState();
}
void Autonomous_State_Start(void)
{
//... DO STUFF ...
m_state->SetCurrentState(AUTO_TURN);
}
void Autonomous_State_Turn(void)
{
//... DO STUFF ...
m_state->SetCurrentState(AUTO_GOAL1);
}
void Autonomous_State_Goal1(void)
{
//... DO STUFF ...
m_state->SetCurrentState(AUTO_TURN);
}
};