Let's Make Robots!

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 (http://letsmakerobots.com/start) it is easy to program a sequence of actions:

While
  Condition 1: gosub Action 1
  Condition 2: gosub Action 2
End

Action 1:
 gosub Action 1.1
 Wait
 gosub Action 1.2

etc.. 


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 (http://letsmakerobots.com/files/clean_navigation.BAS)

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 (http://www.plcdev.com/introduction_grafcets), only in Spanish (http://es.wikipedia.org/wiki/GRAFCET) or Frech (http://www.tecatlant.fr/grafcet/).


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

 

 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

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 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 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: ...
}

"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. ButI would like to know more opinions..."

Because a lot of the chips are so easy to reprogram (compile->upload->5 seconds later, blam, new brains) it works to just tweak and go. I, and I'm sure many others, just build a little stand to hold the bot so it doesn't run away when tweaking things. After a few rounds of programming it comes off the stand and is tried on the floor, until something else needing changed becomes apparent. Then it's back on the stand for another brain load. IIRC, Frits calls this "teaching the robot".

Many times I'll put a temporary program in at the beginning that just uses the serial terminal (arduino and propeller, so far) to spit out debug statements. It's much easier to find servo positions, sensor feedbacks, etc... for the "real" program then. If I do that first, my first real program is 100 times more likely to behave like I thought it should the first time. Can't say about anyone else, but I have a notebook (handmade, often a bot-specific book even) and a whiteboard (actually a mirror) handy when I'm doing this stuff. I end up with bunches of notes jotted down with things like "left shoulder max: 2, min: 170, center: 95". I guess Frits would call that "teaching the programmer"

 

"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?"

Again given how easy it is to replace the code, constants are a pretty simple solution. However, if there's something that may change (depending on ambient lighting, temperature, etc...) the constant can simply hold a starting point, and then have a routine that quickly calibrates the sensor before asking for a real response. Another way would be like OddBot's IR Compound Eye, where it takes a reading, turns on IR LEDs, takes another reading, then finds the difference to account for ambient IR levels.

Yet another way, also involving some kind of calibration technique, would be storing your default parameters in EEPROM. Then the "constants" can be different each time (or for each bot, if making an army), but the overall code is identical.

 

Or did I misunderstand what you were asking? ;)

You are right that the process of reprogramming is quite fast, but What do you do when you want the feedback of the robot when it is moving around? Do you use any kind of wireless connection?

 

I usually knock my head against it until it works ;)

But when I have some really tough logic to figure out I usually try prototyping the algorithm using Python because for me it is very easy to use it in this way, it's a lot closer to pseudo code than C for example.

Now I understand why your picture is wearing a helmet!!