Doubts about software development for robots

Hi LMRtians

After doing some programming for my first robot I was wondering (maybe because of my computer science background) if someone uses some kind of notation or software development methods at the hour of programming the robot.
When you are programming simple things like the Start Here Robot ( it is easy to program a sequence of actions:

  Condition 1: gosub Action 1
  Condition 2: gosub Action 2

Action 1:
 gosub Action 1.1
 gosub Action 1.2


But when you are handling more sensor inputs and you want your robot to acomplish more complex tasks, for example constantly monitoring some inputs, even when you are doing some tasks (avoiding an obstacle or something similar).

For example the First robot part II becomes more complex (

I think that programming it straight away and testing how it works, then changing the code and so on doesn't look a good idea. But I would like to know more opinions...

When I was at the University (once upon a time...) I used a notation language for representing states, actions and transitions: GRAFCET and I was wondering if I should use it. I think that the origin of GRAFCET is French, I haven't found much information in English (, only in Spanish ( or Frech (

Another thing that I would like to ask is how you use to deal with all those parameters related with the decision taking, for example with a distance sensor the values for: Inminent_Collision, Warning_zone / All_clear.
Are constants at the begining of the project the only choice?

Thank you



I don’t know about the other

I don’t know about the other links, but your English GRAFCET link is talking about PLCs programmed using ‘Ladder logic’ using the RSLogix5000 environment. I actually use some of this software at work, and I’ve gotta say there’s quite a difference between all-at-once ladder logic and more common sequential logic.

In case you unfamiliar with it, ladder logic evaluates all the conditional tests in the program at once, and then activates all the conditional actions at once. Due to this behaviour it’s very important to keep track of the state of your program/machine, so as to avoid mutliple conflicting actions taking place (or just getting confused).
The familiar languages used for programming microcontrollers are typically sequential logic programs - they execute commands sequentially based on where they’re up to in the program, moving from top to bottom until they encounter some kind of flow control (goto, gosub, return, etc). This means that if you break your programs up into convenient subroutines it’s fairly easy to see what state your micro is in, based on where it is in the program when it executes blocks of code.

I sometimes use custom ‘flag’ registers in my programs to keep track of the program/robot’s current state, but only if the micro itself needs to be aware of the state, due to a subroutine being called from multiple potential states. Setting a bit in the flag register indicates that a certain state or sub-state is currently active, and the program can then test these flags to see what kind of state the micro is supposed to be in.

Due to the relative ease of programming sequentially, I wouldn’t bother using an extra tool like GRAFCET, just keep your code clean and annotate it properly =)

The idea of the flag for

The idea of the flag for storing the state sounds very interesting, that could help a lot to reuse the same routine in different “states”. I was worried of having to code different subroutines for each state of the robot, even when they were doing almost the same thing.

One of the good things about

One of the good things about binary state flags is that you can throw them right into conditional statements like:

if(moving) {…}
elseif(waiting) {…}
else {…}

Another option is to use a numerical state variable, such as:

int state;

switch(state) {
case 0: …
case 1: …
case 2: …
case 3: …
default: …