robot controller can best be understood by examining the
code in RobotController.ino (available at the article link).
The user configuration items are first up. These are the
networking parameters which must match that of the
robot, or the communication between the robot and robot
controller won’t be possible. The robot creates its own
network called an access point (AP); these parameters make
sure the robot controller is talking to the robot’s AP IP
address at port 8000. MAX_SPEED defines the maximum
speed of the robot’s motors. When set at 900, this slows
the robot down to make navigation easier. Setting this to
1023 would make the robot’s motors run at full speed.
Next up are the hardware configuration items which
make the software aware of which I/O lines are connected
to which peripherals. Following this, are utility functions
used throughout the software. The setup() function which
follows configures the hardware and attempts to log on to
the robot’s network. If logon fails, the RGB LED blinks red
to let the user know there is a network problem. If the
connection is successful, the LED turns green, the initial
state of the state machine is set, and the setup function
ends. The loop() function contains the FSM which
orchestrates everything. The FSM is just a switch statement
which is controlled by the state variable. The current FSM
state is evaluated every time through the loop. The FSM is
made up of the states shown in Table 2.
The Robot Hardware
The robot is made up of the parts listed in Table 3.
Figure 7 shows a close-up of the robot’s electronics and
Figure 8 shows the schematic.
Two items of note here. First, you’ll notice that an SD
memory card is visible on the robot’s circuit board. This is
SERVO 05.2016 45
Initializes important FSM variables, then
transitions to the STATE_CHECK_CONNEC
TION state the next time through the loop.
Check the status of the network connection
between the robot and controller. If the
connection is up, it transitions to the
STATE_CHECK_PINGS state. If the connection
isn't up, a transition is made to the
In this state, an attempt is made to contact the
robot at its IP address and port. If successful,
the RGB LED is set to green and a transition is
made to the STATE_CHECK_PINGS state. If the
robot cannot be contacted, a transition is made
to STATE_ERROR which causes the LED to
Two things happen in this state. First, a
determination is made as to whether a ping
synchronization message should be sent to
the robot. If the ping timeout has expired, a
ping message is sent and the timeout is
reset. Second, a check is made to confirm the
controller has received the echoed ping
message from the robot in the allotted time
interval. If everything is fine, a transition is
made to STATE_CHECK_INCOMING. If the
controller hasn't received a ping message in
the allotted time, a transition is again made
to STATE_ERROR, but this time the LED will
In this state, the controller listens for input
from the robot. At the present time, the only
input of interest from the robot is the echoed
ping message. If this is received, the received
ping timeout is reset and a transition is made
In this state, the joystick's position is read
and manipulated into the left and right motor
messages previously discussed. New
messages will only be sent to the robot when
the joystick's position changes. At the end of
this process, a transition is made back to the
STATE_CHECK_CONNECTION state and the
FSM process starts over.
This state is entered when there is a problem
with the network connection or when the link
goes out of sync. The RGB LED blinks with a
color indicative of the error and then resets
the state to STATE_INIT, causing the software
to re-start in an attempt to correct the error.
Figure 7. Robot electronics close-up. Note: The SD memory card
is not used in this basic robot application.
Figure 8. Robot schematic.