Hmm, TRAFFIC SIGNALS ?
We know what’s coming,and usually in what order… but not ‘when’.
They could change if the trigger events are modified from cycle to cycle.
e.g. no pedestrians, no turners etc.
No fire trucks.
…just another state.
Thé example I started with in my tutorial was a timed light. You have an on/off button but when it’s on it will switch off after 40 seconds for example.
Easy to relate to, only 2 states (light on or off) and 2 events ( (button press and timeout)
Do a fancy push button. Press, long press, double press, and of course debouncing...
Do NOT do a traffic light. That’s the number 1 SM homework...
maybe I did not explain well and explicit enough what I want:
The concept "state-machine" is based on the switch-case-statement. Switch-case (with break) has a lot of code = all the "cases" but executes only one case.
What is an allday-example of
You input different "cases" (numbers)
and depending on the number
only some exclusive steps - exclusive to this case get "executed"
I would like to start more explanation with such an example.
And this might be the reason why some programming-techniques seem hard to understand.
If you don't have a clear picture of the underlying functionality it is indeed hard to understand.
best regards Stefan
If you mean don't do it because it is to be assigned as homework, I see. No need to read further.
If you mean don't do it because it's been done to death, and arguably a fair bit further, I disagree.
First, while we all may have seen it N times, the noobs will not have.
While not uniquely, a traffic control system affords an ideal play pen. The nice thing about it is that is is 1) not artificial, 2) within the experience of most people and 3) small enough to be tractable but large enough to be non-trivial.
It can start with something so simple, the student (!) will think it is dumb. All this machinery to switch between green and red at a programmed rate! One traffic light in some town in Vermont that only has one.
It can get more complicated progressively to the point where the light bulb (green) goes off in the mind of the learning - this would be so hard in the old linear manner of thinking, and so relatively simple with this nice machine, just add some parts to it and we done.
And what we are adding is control by car arrival, pedestrians who, even in Vermont, appreciate that brief time when we allow them to cross our roads… night versus day schedules, a speed sensor and automatic police dispatch call &c. &c.
Also this is fun, trust me, to get working and build, so it is a natural for "jouer avec des Arduinos" as someone might put it. A few switches and LEDs, and that kid in class who's more into other things goes and builds a little tiny intersection with a nice set of lights &c.
The challenge is to find something as nice out of the box. I haven't yet, I be thinking about it.
a7
I like home heating and cooling. It starts very simple: if it's too cold, turn the heating on, else turn it off.
Then it can grow into something more complex, especially if you include the safety checks and error display that the controller does. Then there's different rules for "is anyone home?". Maybe add checks on the weather forecast too.
I think the fact that you can have a trivial working piece of code that doesn't merit a state machine and then evolve it into something that really benefits from the technique can really help people see the why and the how.
My full example is a "gradual lighting". You have 4 lights and a click on a button turns on the next light. it's on a timeout, so x seconds after the last action it auto-turns off and because time-iis-money, a double click from any lighting state goes to full ON or full OFF.
My tutorial walks the user to first handle the clicks, then adds the time out then adds the double click. To make it simple and focus on event management, I used a button library.
It's not only easy to relate too, but also very easy for any newbie to build from any starter kit (4 leds, 4 resistors, 1 momentary button, one Arduino). I'd recommend to take this into consideration when choosing the example.
^ This is key.
I like the heating and cooling thing. It does mean using an abstraction in the lab, a bit more of one than traffic lights require. I don't see this as a bad thing, in fact that may make HVAC a better "playpen" in some respects - never too early to start making models of reality with alternative representations for hardware and environmental conditions that would be hard to have right there.
a7
A problem I have found when writing tutorials is knowing what the audience already understands, which is all but impossible. To get round the problem with a millis() tutorial I set out what the audience was expected to know at the start so that the tutorial did not become bogged down with side issues
It is all too easy to get bogged down in side issues such as debouncing inputs and the installation and use of libraries, which I think should be avoided
Traffic light control would seem to be an excellent example to use when illustrating the use of a state machine. The states are easy to describe and understand, people will have experience of seeing traffic lights so can relate to the example, the number of states and interactions can be increased as the complexity is increased.
Another helpful factor is that and the case exit conditions will include both user driven (button press) and timed (period expiry) events as well as the possibility of including an overriding state such that all lights are at red due to the approach of an emergency vehicle
and it's also within reach of most starter kits in terms of hardware (a few leds, a few resistors, a few buttons and some wires). That's to me an important consideration for a conceptual tutorial.
The Heating/Cooling example is somewhat more demanding in terms of equipment.
I think that if I was going to use the HVAC example in a practical lab, I'd have to make a simulator with another Arduino. Something to send temperature and time (accelerated) at least as well as the ability to run a script to allow repeated testing to facilitate debugging.
@wildbill That sounds like the second or maybe even third level, dunno how fast things go these days, would that be the 2nd/3rd week or the 2nd/3rd quarter? 
But it sounds like a ton of fun, you could have one group making the simulator of the system and another making a controls system to tame it.
a7
Ooh, I love it!
a7
One aspect not mentioned yet (beyond the traffic light suggestion)…
… is the concept that ‘state machines’ don’t have to run the states in a strictly sequential,order. 1-2-3-4–1-2-… etc.
This the truly useful part of a well designed state machine.
Exceptional events (e.g.pedestrian crossing button or emergency vehicle transponder) can disrupt the default sequence, or even jump to an additional series of states until the ‘exception’ event has completed.
This is the double click option in my tutorial that jumps straight to the "last" state where all leds are On or to the all OFF state
1 Like
I design and build industrial control and safety systems for a living and use state machines all the time.
While it won't matter a lot here for this example, I find usually you want to maintain three state variables, lastState, currentState, nextState.
Why, lots of reasons, but writing the new state to nextState and then only moving that to to currentState last thing in the loop means you can't get a "double solve" in the cycle of the evaluation, sometimes this is very important.
Having lasteState also means you can compare the currentState and lastState and know that you just transitioned, sometimes there is an action you want to take only on the transition between two states.
Also, once you have done the above it becomes trivial to keep a bucket brigade of the last ten states (say, up to you and memory) which can be super handy for debugging.
In my experience there is often only one practical means to get an unambiguous and exhaustive description of the behavior of some software or something it controls, and that is by use of state machine/s.
There are also hierarchal state machines and one of the seemingly unteachable skills is the optimal system and sub-system decomposition (eg do you have a separate machine for modes, like auto, off, local, remote, or do you build them into the main machine, etc etc).
Currently I have a safety system for ten burner kiln that ends up as a hierarchy of 16 machines, but this vastly reduces the number of test cases required by means of architectural encapsulation (assuming no side effects).
Stick with it, you learn by doing and if this is one thing you can do well you can make a whole career out of it.
PS : I prefer the use of a state table rather than a state chart, then you are forced to consider every possible transition, even if just gets an X for don't care, at least you know you considered all of the possibilities.
1 Like
Yup. I'm a big fan of Miro Samek's work.
Debugging state machine becomes more difficult when you use a state table and your transition becomes something like:
state = stateTable[state].nextState[inputs];
I suspect your technique of explicitly keeping track of previous/next state(s) would help a lot.