I am new to Arduino and writing in C, I am working on my final project for school. I am building a bidirectional visitor counter with automatic lighting. I am using two IR sensors in the door way, i would like to write the code as a state machine case statement, do i have to download the state machine library?
do i have to download the state machine library?
No, write your own, you will learn a lot more. For help see my
http://www.thebox.myzen.co.uk/Tutorial/State_Machine.html
Or Robin2's several things at once
http://forum.arduino.cc/index.php?topic=223286.0
"state machine" is just a fancy name for a system in which the behaviour of the program is managed by one or more variables that keep track of events. For example,
if (personInRoom == true) {
if (lightsOn == false) {
turnLightsOn();
}
}
I have never seen the need for a library to do that sort of thing.
...R
A library can map sensor signals and delays into events, but the overhead for such a library may be huge. And the configuration of such a struct/object, as well as the condition/action management, still must be done in user code.
If ever, I'd write my own class for every state machine, that holds all inputs and delays in local variables, with significant names for methods for actions and condition tests.
One more link for you to read:
.
State machine sounds so complicated. It's a Machine after all! Well actually it isn't. Robin has it right - it's just that you keep the "state" of things in variables, which then are evaluated to decide if action needs to be taken or not.
By bidirectional visitor counter, you mean two beans which when blocked signal that a person is passing the sensor, right? When the outer beam blinks just before the inner beam blinks means a person entered. Vice-versa means that a person exited. So states could be 'outer beam interrupted' and 'inner beam interrupted'.
Your sketch interprets those 'state variables', and counts entries and exits.
However ... in addition to the nice one person enters/exits at a time event, you will also need to consider more complicated scenarios, such as two people enter at almost the same time, a person starts in but turns around halfway, or if two people enter and leave at the same time. The pattern of the states will be different in those situations. Your sketch will need to determine which pattern happens, and count entries/exits accordingly.
Well, "inner beam interrupted" and "outer beam interrupted" actually are events, not states. The states could be "idle", "passed in" and "passed out". The machine starts in state "idle", waiting for either event. When "inner beam interrupted" occurs, the state changes into "passed in". In state "passed in" the machine again waits for either event, and when "outer beam interrupted" occurs, the action passedOut() is executed, maybe more than decrementing the counter, then changes back into "idle" state.
A good design requires that in every state all (possible) events are handled. I'll leave it to the reader to complete the state diagram/code of this machine as appropriate.
Some states are left after a certain time, if nothing else happens. In such cases a "timeout" event has to be checked, i.e. when (millis()-delayStart>=timeout).
Well, "inner beam interrupted" and "outer beam interrupted" actually are events, not states.
Very true.
Events are normally used to switch the machine to different states. Such as take avoiding action by moving to the left, or stop or such like.
Alright. I would have written it with the 'state' of each beam being states. Possibly changed it later - I was getting sleepy last night.
But I still think it would be easier to handle oddball situations, like someone walking halfway in, then turning around just as someone else walked out, if the states were lower level. PassedIn could be a higher level state, but in my envisioning of the problem, once they "passed in" it would just up the room tally, and wouldn't need to be kept around as a state.