ASURO programming using state diagrams

Watch the short video above. It shows a little mobile robot (ASURO¹⁾) exploring its environment. Consider how the exploration algorithm might work …

The diagram below shows the state chart of the software running on the robot. If you examine the diagram you can clearly understand what is happening why. This is the first major benefit of state diagrams. State diagrams are perfect to fully describe reactive systems.

Ok - does this diagram really describes the software or is it just an early design sketch which is not valid anymore because it was never updated after coding has started?

To make sure that this does not happen the code running on the robot was directly generated from the state diagram. This is the second major benefit. State diagrams are perfect to fully describe reactive systems and generate code out of them. If you are interested in the ASURO code just send us a mail.

Debugging an application that is based on generated code from a state diagram is a bit different compared to debugging hand written state machine code. Why? Because you can assume that the generated code is correct. You don’t have to worry about all the nitty gritty details of the realisation of a state machine in C (e.g. handling history, handling hierarchical designs, placement of entry/exit …). If the machine does not what it should do then most probably the model is not correct. To track down the problem - especially in deeply embedded real-time systems - typically means to add a tracing mechanism which allows you see which events do fire etc. Here the code generator can support you.

The code generator can add trace code automatically. You only have to call the generator with the -Trace command line switch. In this case calls to a trace function are inserted in the generated code. The argument of the trace function is the processed event. A part of the ASURO state machine is displayed below. For every handled event the trace function is called (e.g. xxxTraceEvent(2U)). If the trace code is not anymore needed just call the codegenerator again without the -Trace option.

case EXPLORE:
 
	switch(instanceVar->stateVarEXPLORE){
 
		/*
		  Code for transitions starting from inner states
		 */
		case AHEAD:
			/* action code  */
			flag=drive(speed,FWD,flag);
 
			if(usDist<15){
				behaviourTraceEvent(2U);
				/*Transition from AHEAD to AHEAD_WITH_BARR */
				evConsumed=16U;
 
				/*Action code for transition */
				flag=1;speed=80; StatusLED(RED);
				instanceVar->stateVarEXPLORE=AHEAD_WITH_BARR;
			}else if(msg==(BEHAVIOUR_EVENT_T)evTimeoutT0){
				behaviourTraceEvent(0U);
				/*Transition from AHEAD to IDLE3 */
				evConsumed=1U;
 
				/*onEntry code of state IDLE3 */
				startTimer(TIMER0, 1000);MotorSpeed(0,0);
				instanceVar->stateVarEXPLORE=IDLE3;
			}
			else
			{
				/* Intentionally left blank  */
			}
		break;
                ...

If tracing is enabled an additional header file is generated which provides a table to map event ids to event strings. E.g. the argument 2U from above corresponds to the second entry in the table. This allows you to easily display the event as text.

const char* const behaviourTraceEvents[] = {
	"evTimeoutT0",
	"turned==1",
	"usDist<15",
	"usDist>30",
	"evKey"
};

The trace function must be provided by yourself. Within the trace function you can decide now what to do with this trace information.

• store it in a ring buffer and read it out later (post mortem)
• display it somehow
• forward it to a monitoring station
• …

The following code was used on the ASURO robot and simply sends the processed event to a monitoring PC.

void behaviourTraceEvent(BEHAVIOUR_EVENT_T evt){
	SerPrint(behaviourTraceEvents[evt]);
	crlf();
}

On the PC it is now possible to watch the event flow in a terminal window.

Watching events in a terminal window is not bad but sinelaboreRT can do even better. When starting the codegen.jar with the -S command line switch an interactive graphical simulation window pops up. The status of the state machine after startup is displayed. The events that can be handled presently are shown in blue and are also listed in left window. The output window shows the executed statemachine code. You can now send events to the machine by clicking on an event. The display is updated accordingly and shows the new status.

Beside the interactive mode it is possible to send events via an UPD port. This is what we show next. A small application receives the events sent from the ASURO robot over a wireless serial link and translates it into a UDP message (see diagram below). The UDP message is received from the simulator and the display is updated accordingly. Click on the simulation image above and watch how the state diagram is updated while ASURO is exploring its environment.

The sinelaboreRT code generator provides several mechanisms to support you during debugging and testing of your state machine design.

• It can automatically add trace code to the state machine
• It provides an interactive simulation window which can display the status of your embedded target in real-time.
• With the UPD/IP interface a flexible mechanism is available to use the communication interface your hardware offers. A simple “event forwarder” is all what you need.