The beginning

When developing for Arduino, focusing on a cart that was able to follow a predetermined line on the floor, I realized that when making structured code in C++ it was a bad thing, it was simpler to develop the logic, but in the long run I saw myself creating several ifs.

Yes, this meme represents well what I mean. I had to create checks for the sensors, all the time, and there were several so I can be sure that everything will go well. I missed the OOP classes, where we create objects and separate things in an organized way, here the code was linear and its ability to be messy was huge.

Such a code is difficult to maintain and confusing even for those who are programming, imagine for someone else outside the project. It is simpler to do, much simpler, but it is that programmer’s choice:

• Make simple code to never mess with it later
• Or make a code well done to be used later

Even if you try to modulate this by creating several methods, it will only increase the size of the code (which is included in just one .ino file), making the programmer have to hunt down the part of the code in which he has to perform maintenance.

One solution for this is to use object orientation for Arduino in C++, it is a good option, although it increases the complexity for the application, the code is more readable and there will be greater maintenance.

State Partner

Thinking of developing an efficient object-oriented code for a line-following cart, I had the following analogy:

Thinking about a cart working, it will have several states in which it should behave differently.

Which is true, giving an example, while the cart is moving forward, I wish it to perform certain checks and certain actions. I want each state of the cart to make it behave differently depending on what is needed.

And thinking about it, I studied the State Design Partner, or State Machine for some, and in it we have the concept that something will have a number of states and in those states it must perform determined or even unique behaviors, making transitions between states.

In this simple example we have a button, and in this we can only have 2 possible states: On and Off.

In each state the button will perform a different action, in On it will turn on something, in Off it will turn off. What makes him transition from one state to another is the action of pressing the button.

Note that it is a very simple concept and we can apply it to Arduino projects. The State Machine is ideal when something is likely to have situations where it will have to behave differently, could this be solved with a simple if? Yes, but if the complexity of your application starts to rise, and you see that more and more create if after if, it is better to rethink what you are doing…

if(isSensor) {
    // do something
    if(anotherSensor) {
        // Do something else
    } else {
        // Do something else
    }
} else {
    // do something
}

To get around this I created this State Machine model that is able to solve this problem and bring modularity to your code, being able to reuse and easy to maintain.

This is my project, for more information about, follow the link below for the article about the installation.

Install...

In this article we will see how to install the package and know some concepts for using it.

Continue reading