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.
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).
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...
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?
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.
