YAAR - Yet Another Arduino Robot

I would like to introduce YAAR – Yet Another Arduino Robot. YAAR (ar ar – Lt. Tasha Yar, Star trek…) is intended as a modular hardware and software development platform for robotics projects. Here are the main features:

• Wi-Fi connected supervisory command and control
• Wi-Fi video monitoring
• Raspberry Pi for higher level processing
• Arduino Mega2560 for low level control
• Closed loop speed control
• Supports DC motors and brushless motors
• Servo driven steering
• Software differential motive power and steering
• Pi compatible power supply with pushbutton ON/OFF
• Modular hardware to support larger platforms

Introduction

Over the years I have built lots of run-around-the-floor robots with varying degrees of autonomy. But all of my previous robotic projects have been plagued by communications hassles. I have used RF and Bluetooth links with 900 MHz / 2.4 GHz / 5.8 GHz data link and video transmitters and receivers. They all work, but it was always a hassle getting all of the components set up and working properly. Consolidating all communications over Wi-Fi would be a serious improvement. Additionally, I had some larger robotic projects in mind that would benefit from the higher intelligence that a Raspberry Pi would bring. That is how YAAR was born.

Project Notes

The mechanical aspect of the project is designed using Fusion 360. This is a free (non-commercial) Autodesk 3D CAD system. The basic requirements for the CAD are to be able to export .DXF files for laser cutting and .STL files for 3D printing. Some laser cutters are incapable of importing .DXF files correctly. Inkscape is pretty good at sorting out these file incompatibilities.

I use DipTrace for schematic capture and PWB layout. DipTrace is free for non-commercial use to create one- or two-layer boards with a maximum of 500 pads. DipTrace can export Eagle files if desired. Schematics and PWB layouts are supplied as DipTrace files. Gerber files are also supplied. Although I have supplied files in GBR, DXF and STL format, I would encourage you to generate these files directly from Fusion or DipTrace – I have had disturbing results with .DXF files in particular.

I buy nearly all of my components through AliExpress. The smallest resistors and capacitors are 0805 size so hand soldering is straightforward. I also purchase generic integrated circuits from China such as the MCP6001 op amps, TCST1103 photo interrupter, DRV8833 dual motor control and SS34 Schottky diodes. Admittedly, you have to wait several weeks for delivery (my average is 3 to 4 weeks). Digi-Key is my go-to source for specialized parts such as Molex C-Grid connectors. I use Oshpark and JLCPCB as PCB sources. I use the 0.1” Molex C-Grid system for wire interconnections and terminations.

This is a project overview. I do not go in to all of the details such as “download the Arduino IDE…” That would require a book. However, I think I have provided enough for someone with basic hardware and software skills to successfully get YAAR up and running.

Latest updates of everything here and more is available at:

https://www.dropbox.com/s/vnpseg2xxdbehr4/YAAR.zip?dl=0

Sources and supplies are listed in the attached "Sources" file.

YAAR’s hardware is composed of 4 main components; power supply, hardware inputs/outputs and associated microcontroller, motor control and a brain. 

The Raspberry Pi’s primary purpose is to serve as a communications center and provide high level thinking capabilities. Communication between the Pi and the PC running a terminal emulation program (PuTTY) is based on the SSH protocol over Wi-Fi. Video from the camera is transmitted also over Wi-Fi by the UV4L streaming server. UV4L was chosen based on best video lag, about a half second. I used a Raspberry Pi 3B+ for this project because I had it on hand and all things Raspberry are currently out-of-stock or only available at scalper prices.

 An Arduino Mega2560 Pro is used as the low-level hardware controller. Two other microcontrollers were evaluated; the 32U4 based Pro Micro and the STM32F103 based Blue Pill. Although the Pro Micro had sufficient internal resources, it did not have enough I/O pins to support the project. The Blue Pill does have enough I/O and was considerably faster, but was very susceptible to the noise generated by the motors. Additionally, the Blue Pill is not a “mainstream” Arduino. Getting consistent, up-to-date libraries installed and finding the documentation was a challenge for me.

The Arduino is attached to a custom board that provides onboard power and distributes power and signals to all attached inputs and outputs. A custom dual motor controller board is attached to the power distribution board. Together this Hardware Control Unit (HCU) supports the following features:

• PWM outputs for two brush type motors
• Optionally, two RC outputs for brushless motors
• Two shaft encoder sensor inputs
• Emergency stop bumper
• SR-04 sonar obstacle detection
• Power supply monitoring and control
• Servo controlled steering
• Blinking laser diode (just like Picard the Borg)
• Piezo alarm
• Serial communications to Raspberry Pi
• Onboard 5 Volt switching power supply
• Plenty of unused I/O for future needs
• Status LEDs

The Hardware Control Unit responds to commands sent over either the serial port connected to the Pi or the Arduino IDE serial port. The HCU will monitor and control the steering and motors to accomplish the following:

• Go forward at a prescribed speed following a straight path
• Go backwards at a prescribed speed
• Stop
• Follow a curved path of prescribed radius
• Angle path to the right or left by prescribed amount

The Pro Micro had sufficient internal resources (interrupts, timers, serial ports) but lacked the needed number of I/O pins. The speed of the Blue Pill was enticing, but I found that the microcontroller was very susceptible to noise and although I was successful in getting it running, I found the Mega2560 easier to interface, much more trouble-free and the software support environment more developed and better documented. The Arduino is managing a task scheduler at 100 x/second and running an event driven state machine at a loop speed in excess of 100k/sec with ~20% processor overhead. All events are interrupt driven where possible. Even though it is not as speedy as the Blue Pill, it’s speedy enough. Abandoning the Blue Pill was a painful decision because the STM32F103 microcontroller clocked at 72 MHz was capable of running the task scheduler at 1000x/sec with the same microprocessor overhead as the Mega2560 which was a bit surprising because the STM32F’s clock rate is only 4.5x faster than the Arduino and it is a RISC architecture.

The Arduino control scheme is centered around two main elements; a task scheduler and a state machine. The task scheduler is driven by a periodic interrupt generated by timer 5 every 10 milliseconds. The interrupt service routine sets a flag corresponding to the time interval since last called. Flags are set corresponding to 10 ms, 20 ms, 50 ms, 100 ms, … 1 second. The main program loop consists of the task scheduler checking each of these flags and, if set, executes the task assigned to that time slot. The end result is that certain tasks such as closed loop speed control can be executed at higher rates whereas other tasks such as battery monitoring can be executed at much slower rates.

The second major software element is the state machine. YAAR is always in one of several states for example, stopped, going forward or going backwards. The state machine constantly monitors all inputs related to the current state and if anything has

changed, appropriate action is taken. Many events are interrupt driven which reduces the microcontroller overhead and increases the execution rate. The task scheduler executes the state machine task every 10 milliseconds. 

One of the key features of YAAR are the optical speed encoders that provide speed information for the closed loop speed control. Without a feedback loop control scheme, speed is heavily influenced by changing load, friction, surface and geometry. YAAR is able to creep along at a stable 5 cm/second (.1 mph!). The encoders also support track control which enables a controlled steering angle to be accomplished e.g. “Right 20 degrees”.

Steering is accomplished with both the servo controlled front wheel and differential speed control of the two rear wheels. Mechanically, the front wheel is simply mounted to a fork on the servo. In order for YAAR to rotate in place the front wheel servo must rotate 90 degrees left and right of center.

YAAR’s software and hardware are independent of robot size with the exception of the motor control. A connector is provided on the HCU to connect to an external motor control. Signals available are PWM, RC servo, power and individual controls for enable and direction. The RC servo signals support readily available brushless motor controllers.

The motor control used here is designed for the “Arduino TT” motors which are small, readily available and cheap. The Texas Instruments DRV8833 dual motor control supplies up to 1 Amp to each motor at a maximum input voltage of 11.5 Volts. A jumper selects either 5 Volt supply or battery for motor power – use the battery option. The DRV8833 has only two control pins for each motor. If one is used for PWM speed control, the other becomes the direction control but when reversing direction, the PWM signal must be inverted. Fortunately, the timer in the Arduino supports outputting an inverted PWM

signal. The state of the two input signals controls how the DRV8833 handles flyback current (the current that flows after the inductor is switched off). If both input signals are low, the current recirculates through the power supply until dissipated then the motor coasts. If both signals are high, the motor is shorted to ground which puts an electrical brake on the motor. Braking is less efficient but results in smoother operation at low speeds. I chose brake mode for forward operation resulting in smooth slow speed forward motion but jerkier motion when moving at slow speed in the reverse state. The two scope captures illustrate the waveforms on both sides of the motor. The first is forward in the slow decay mode and the second is reverse in the fast decay mode. The telltale difference is that in the second scope capture, the motor armature can be seen “kicking back” to a voltage exceeding the power supply. The PWM rate can range from 30Hz to 31kHz. I chose 4kHz.

The motor control task is a simple error feedback loop consisting of proportional and integral correction terms (timer OCR2A, B registers serve as the I term). I have experimented with a D term, but found no improvement. Perhaps with a faster encoder update rate this would change. This task is executed 20 times/second. The motor control software is written in a separate tab labeled “DRV8833” in the Arduino IDE to facilitate replacement for other motor controllers. When printing a diagnostic report to the IDE serial monitor a “hiccup” in motor speed can occasionally be observed as tasks are suspended during longer reports.

The slot encoder is a simple circuit. Although you can purchase slot encoders for the Arduino robot for $1 on AliExpress, there are a couple of drawbacks to the ones I have tested. Biggest problem is that they bounce. They are large and they consume a lot of current. This circuit eliminates bouncing with positive feedback around the op amp. 

The slot encoders are key to the design of YAAR. They enable accurate speed control and tracking. The circuit shown is compact, low power and bounce free. The circuit operates from 3V to 6V.

Along with the encoder is an improved encoder disc with 50 holes instead of the usual 10. It is unfortunate that there is no practical method of attaching the encoder disk to the end of the motor shaft instead of to the wheel shaft. Getting as much speed information as quickly as possible is key in order to achieve smooth low speed operation. Fifty holes was the maximum my laser cutter would cleanly cut. The disc is cut from 1/16” ply. Attach the disk with a 2-56 or a 2mm screw to the opposite end of the wheel shaft. The PWB should be fabricated on .032” stock with 2 oz. copper.

The sensor unit consists of the camera, SR-04 ultrasonic distance sensor, bumper switches and laser diode. A 3D printed mount is designed for all sensors so that they may be assembled and wired before mounting into the robot.

The SR-04, camera and bumper switches are mounted in the elevated head unit. This is attached to the ECU with 3mm screws so that it can be swung up to access the connections below. Be careful when mounting the camera. Put a soft cloth under the assembly or else the lens will be marred.

Note: the laser diode module contains a 91 Ohm resistor which will draw too much current (31 mA) from the microcontroller output. This must be replaced with a 150 Ohm resistor which will limit the current to 19 mA.

The power supply is a switch mode buck converter that regulates the 7.4 Volt 2S LiPo battery down to 5 Volts. Power to the system is started with the press of a pushbutton. Shutdown is accomplished with the same pushbutton – just like your PC. This is important because just as pulling the plug on your PC is not recommended, neither is it recommended for the Raspberry Pi. Why not just switch off the power? Because the Pi has a lot of housekeeping to do in order to shut down. If this process is interrupted at the wrong time, SD card files can be corrupted. The power supply plugs directly into the 40-pin header of the Pi and is controlled by the Arduino. Note that when the pushbutton is pressed, power to the Power Distribution Board is being supplied through the pushbutton, then through the diode to the enable pin of the power supply on the power distribution board. After the Arduino boots up (which takes about a second), the Arduino will control the enable pin through a second isolation diode.

• Attaches directly to Pi 20 pin header
• 20 Volt max battery input
• 3 Amp output
• Trimpot adjustable from 4.95 to 5.48 Volt output
• 92% efficiency
• 2 cell LiPo supply

The power supply is based on Diodes Inc. the 3 Amp AP62300T switch mode regulator. Originally, I had designed the power supply to use the 5 Amp Texas Instruments TPS565201 regulator. However, after my initial prototype units were working, I tried to order more only to discover that the lead time had stretched to over a year. I chuckled to myself that my little project had contributed to the “chip shortage” that was crippling the auto industry. Fortunately, the AP62300T is almost a drop-in replacement. All of my measurements of the Raspberry Pi’s current draw (with camera) averages less than 1 Amp with brief excursions during startup of 1.75 Amps so the AP62300T will suffice nicely. There are small differences in reference voltages and enable pin control requirements. Additionally, there are two versions; the “T” and “not T” version with different reference voltages. It doesn’t matter – the schematic shows the correct resistors for each version. As with most components purchased from AliExpress, data sheets are wishful thinking. None of the Chinese sourced caps have exploded and the 7x7x3 mm inductor seems to be universally rated over 5 Amps. With the resistor values shown the output ranges from 4.95 V to 5.48 V (using the “T” version). Be careful when adjusting the trimpot, if you don’t have a non-conducting screwdriver, don’t adjust while plugged into the Pi – inserting a metallic Phillips screwdriver into the slot changes the voltage. After R1 is installed, the power supply will not turn on unless the EN pin is pulled high so install R1 after you have tested and adjusted the unit. I have adjusted my unit to 5.1 V with a 5 Ohm load. The power supply will maintain regulation unless the battery voltage falls below 6.5 Volts at which point the 2 cell LiPo battery will be over 90% depleted. The AP62300T is rated for a maximum input voltage of 20 Volts.

It turned out that the control connector is best oriented at 90 degrees. This covers up the voltage adjust trimpot making adjustment tedious. Turn the power off when adjusting the trimpot. The connections to the Hardware Control Unit are as follows: - see illustrations

The power supply also has provisions for an I2C connector. The connector attaching the power supply to the Pi obscures the SDA and SCL signals so they are recreated at the I2C connector together with a couple of control signals: - see illustrations

You may have noticed that the battery is always connected to the system which could result in substantial leakage current. The leakage current is measured at 10 uA which amounts to years from a LiPo 18650 battery. The PWB should be fabricated on .032” stock with 2 oz. copper. Lastly, because the Arduino takes about a second to boot, you will have to hold the pushbutton down until the sustained beep begins or the laser diode begins flashing, this means that the Arduino has booted.

Special care must be taken when interconnected circuits are powered up and powered down separately. Most ICs have input protection diodes as shown in the partial datasheet schematic. In our case the Arduino powers up first which means that the Pi is still powered off. If the Arduino attempts to output a digital high to any pin on the Pi, the result will be a short circuit through the input protection diode. This will greatly exceed the maximum output current rating of the Arduino and the input current rating of the Pi. But the problems do not end there. Some ICs are susceptible to “latch-up” meaning that if a current if flowing through the body diode during power up, the entire IC will act like an SCR and short circuit the power to ground resulting in a sharp “pop!”, a small puff of smoke and that acrid smell we geeks know so well. These same considerations must be kept in mind when shutting the power off; all Arduino outputs are put in tristate and only then can the Pi be safely powered off. You can send the “(K)ill” command over the SSH / PC terminal link or press the pushbutton to follow this procedure.

The Raspberry Pi serves as YAAR’s “Brains” and communication hub. Currently commands are sent form a PC terminal (PuTTY) via SSH over Wi-Fi to the Pi which are relayed over a serial link to the Hardware Control Unit. Progress is monitored on the PC through the camera connected to the Pi using a low latency UV4L software link into a browser window.

At this point I must confess that I am not a Python / Linux programmer. The first bit of Python code is a simple sketch that monitors an input from the Arduino and executes a shutdown command if the signal goes low. This was an easy hack taken from pushbutton shutdown code found in many places on the web. 

The second bit of code is easy in principle but took a while to get working correctly. Basically, the code sends any input from the SSH port to the UART and sends any input received from the UART to the SSH port. Sounds easy enuf, huh?

#!/usr/bin/env python3
# non blocking input from SSH
# without "timeout" any noise will hang program
# This is a Pyton3 sketch, the .py file type is removed so it can be invoked easier


import sys
import select
import serial
from time import sleep


ser = serial.Serial("/dev/ttyS0", 9600, timeout=1) # timeout=1 second


while True:
    while sys.stdin in select.select([sys.stdin], [], [], 0)[0]:
        fromSSH = sys.stdin.readline() #get input string from PC via SSH
    
        if fromSSH:                    # if not empty
            fromSSH += '\n'            # add lf, needed for parseInt()
            toUART = fromSSH.encode('utf-8') # convert utf-8 to bytes
            ser.write(toUART)          # write out ascii bytes
            sleep(0.1)                 # time for Arduino to reply
 
    else:
        if ser.inWaiting() > 0:        # anything from Arduino?
            fromUART = ser.readline()  # '\n' terminated line, bytes
            toSSH = fromUART.decode()  # convert bytes to utf-8 string
            print(toSSH)               # send to PC via SSH

Here is an overview of the actions and items that must be installed on the Pi:

1. Enable Wi-Fi
2. Enable and test SSH communications to your PC’s terminal program (PuTTY host name raspberrypi, Port 22, Connection type SSH, Login as: pi, Pi@raspberrypi’s password: default is raspberry unless you changed it)
3. Install and test Python shutdown.py code – use a pushbutton to ground to test
4. Make shutdown.py execute on startup
5. Install and test UV4L
6. Install and test robot.py – at this point you should be able to connect to YAAR and communicate to the HCU over Wi-Fi / SSH / PuTTY

Fabricate the wiring harness. I used an 18 pin DRH for SIG1, a 24 pin DRH for SIG2, a 6 pin SRH for the control connector to the power supply and a 6-pin polarized SRH for the connector to the sensor head unit.

Mechanically, YAAR isn’t much to shout about – just the minimum required to test the electronics and develop the software. I have found that laser cut 1/8” (3mm) lite ply (3 ply poplar) is a fast and easy method for fabricating the body. I use thin cyanoacrylate glue to assemble the plywood, rubber banding it together beforehand. Be careful not to allow excess glue around the motor mount or in the ECU mounting area – these places are a tight fit.

The motor presents a design challenge – the motor to wheel clearance can be as small as 1mm in some motors and wheels (there is quite a bit of variance). Unfortunately, the motor mounting screws are directly underneath the squeeze point so even if the motor is mounted on the outside of the body, the screw head will rub on the wheel. The solution was to design a 3D printed motor mount that attaches to the inside of the body with screws positioned where sufficient clearance exists. The encoder mount attaches to the motor mount through the normal motor mounting holes to ensure correct optical alignment of the encoder and the encoder disc. When assembling the motor / motor mount / encoder mount, note that the small protrusion on the motor body is on the same side as the wheel (motor is not symmetrical). Wherever possible I use 3mm screws and tap the 3D printed PLA. This results in a very satisfying assembly process. Old desktop computers can be the motherlode of 3mm screws.

There are several 3D printed parts:

• Electronic Control Unit (ECU) – a holder for the Pi, HCU and battery
• Bumper Arm Extension – extends microswitch arm
• Bumper – connects two bumper arm extensions in front of wheel
• Servo Mount – holds steering servo
• Fork – holds 1.75” wheel
• Motor Mount – holds motor and encoder mount
• Sensor mount – allows wiring of sensor unit before installation

The ECU is designed to fit a Raspberry Pi 3B+. Some redesign will be needed for a Pi 4. The fork is designed for the TS-53 servo which has 25 splines. Redesign may be required for a different servo. The TS-53 servo I selected is obsolete. I believe the alternative one suggested in the sources document is better, but untested. In order for YAAR to rotate in place, the servo must be able to rotate 180 degrees.

Bend the microswitch arms forward enough so that the bumper clears the front wheel when depressed. Use maker’s best friend - hot melt glue to attach the bumper to the arm extensions.

My first step is to get out the hot melt glue gun and apply a glob of glue over the micro-USB connector on the Arduino. There is nothing more depressing than seeing that connector dangling from the end of your USB cable after having been ripped off the board.

Bench test the HCU first. Attach the Arduino to the Power Distribution Board and connect the micro-USB. Invoke the Arduino IDE and load the code. Do not attach anything else to the HCU. Power will be supplied by the USB. Invoke the IDE serial monitor and confirm that the menu is presented.

Next attach the motor control module and the two motor assemblies to the HCU. The motors can be tested by sending forward and reverse commands. Remember that power is being supplied by the PC USB port so limit your speed. Mine runs out of juice at about 25 cm/sec. Check that the encoders are operating correctly by putting a bit of post-it note on each wheel and verifying that the motors are, in fact, tracking by noting that the relative position of the marker is unchanged. Problems can be caused by misalignment of the encoder and encoder disk or an obscured (or partially obscured) slot.

Attach the sensor module and connector SIG2. The laser should start blinking. The ultrasonic range finder can be tested using report 3.

Attach the power supply to the SIG1 connector and the SIG1 connector to the HCU. Apply 7.4V power to the power supply. Confirm proper operation of the bumper switches and the pushbutton. Whenever the STOP state is entered, the HCU sends a code in binary representing the reason (CODABOPP):

Click on the data input window in the monitor and enter a command such as “f<ENTER>” for forward then “v10<ENTER>” for speed. There are 7 built-in diagnostic reports such as “x1”, the one shown below (see illustrations). Note that the basic commanded speed is 10 cm/sec but each motor is modifying the commanded speed slightly as the steering task is attempting to keep the track straight , Adist = Bdist. There are 7 reports:

1. Motor information
2. Steering
3. General
4. Ping
5. Spin
6. Power control
7. Mechanical & menu

Entering any command without an expected argument will set that argument equal to zero, so invoking report 0 will turn off any active report. You will have to examine the code to see the meaning of many of the columns as the abbreviated titles can be obtuse.

Be aware that your PC is probably limited to 500 mA at the USB connector. Approaching this limit will result in aberrant behavior.

After a couple of seconds, you will see the command menu presented on the monitor. Commands can be sent to the Arduino either from the IDE serial monitor or the Raspberry Pi serial port (via SSH and PuTTY).

After you are satisfied that the HCU is operating correctly, attach the power supply to the Pi and the HCU to the control connector. Attach the battery (or external power supply). Remember that when the Arduino IDE is connected you must use care not to cause an Arduino reset because this will immediately turn off the power to the Pi, such as when you load new code or invoke the monitor. The software detects the presence of a battery and enables power to the Pi only if present and sufficiently charged. Debugging with both the Raspberry Pi and the Arduino IDE and monitor active can be tricky. This is my boot up procedure:

1. Invoke Arduino IDE on the PC, open appropriate code file
2. Plug USB cable into Arduino, this will start the Arduino bootup but not the Pi
3. Enable the IDE serial monitor, this will reboot the Arduino
4. Load new code into the Arduino if desired
5. Attach battery to power supply board
6. Disable then re-enable the IDE serial monitor, it, this will reboot both Arduino and Pi. The presence of a battery will be noted and the Pi will be powered up.

After a couple of seconds, you will see the command menu presented on the monitor. It takes the Pi about 30 seconds to boot, after that you can confirm operation of the video link. Commands can be sent to the Arduino either from the IDE serial monitor or the Raspberry Pi serial port (via SSH and PuTTY).

Shutdown is accomplished by pressing the pushbutton or sending the (K)ill command. Wait to disconnect the battery until the alarm has stopped beeping or the laser to stop blinking. If you want to load new code into the Arduino, turn off the system, disconnect the battery, load the code and restart the system. Communication failures between the Arduino and Pi are usually caused by a low battery. Despite of all of my admonishments about turning off the Pi during operation, mine has survived dozens of inadvertent power shutdowns with no detectable ill effects.

I did run in to a tricky problem while debugging the HCU characterized by the motors running fine at slow speed but hiccupping or resetting when going faster. This was (finally!) tracked down to a weak ground connection between pins 1 & 2 on the 20 pin MTRCTRL connector and ground pins 1 & 2 on the SIG1 connector. Adding a 22 gauge wire between the pins solved the problem.

YAAR responds to 9 fundamental

commands:

1. Stop – enter stop state, motors will apply electrical motor brake
2. Forward – enter forward state (at velocity = 0)
3. Reverse – enter reverse state (at velocity = 0)
4. Velocity – set prescribed speed
5. Distance – set prescribed distance (default = 10km)
6. Curve – set path to circle right (+) or left (-) of prescribed radius in cm
7. Right – set prescribed new track in degrees
8. Left – if executed from stop state, YAAR will rotate in place
9. Halt – sets velocity=0 but remains in forward or reverse state

Commands can be entered from either the Arduino serial console or sent by the Raspberry Pi. A typical command would consist of entering the desired state then specifying the desired velocity. Commands are not case sensitive. Each command must be sent with <ENTER>, e.g.:

f<ENTER>     Enter the forward state
v20<ENTER>   Set speed to 20 cm/sec, begin moving forward

The following command sequence will cause YAAR to travel backwards 100 cm at a speed of 30 cm/sec:

b<ENTER>     Enter the backup state
d100<ENTER>  Set distance to 100 cm
v30<ENTER>   Set speed to 30 cm/sec, begin moving backward

The same command sequence can be entered as:

B d100 v30<ENTER> Use spaces to separate commands, execute upon ENTER

After YAAR has entered the forward state, the path may be modified with the R, L and C commands.

f<ENTER>      Enter the forward state
v20<ENTER>   Begin forward motion at speed = 20 cm/sec
r45<ENTER>   Change track to the right 45 degrees
c-100<ENTER> Circle to the left with a radius of 1 meter
r<ENTER>     Change track to right 0 degrees (straight ahead)
s<ENTER>     Enter the stop state
r360<ENTER>  Enter the spin state, rotate in place right 360 degrees

Steering task is not invoked in the backup state resulting in the same speed command to both motors when in reverse.  

Right now, the brain isn’t thinking about much as all it does is relay communications, but the possibilities are endless… First of all, as I said, I am not terribly comfortable coding in Python. But maybe my first step will be to replace the SR-04 ultrasonic distance sensor with a Time-Of-Flight sensor like the VL53L5 connected via I2C to the Pi. This would result in an architectural improvement as the Pi would be able to utilize the spatial information as well as simple obstacle avoidance. It would also give the Pi something to think about, which was the whole point of the project.

After that, the following projects beckon; follow a color blob, navigate around the house, build a larger platform, telepresence, audio commands, follow a person… I would be eager to collaborate on extending the capabilities of this project if anyone is interested.