algorithm Arduino hardware software

Basic SmartCar Bot – Setup

There comes a point at which the hardware and controls need to be started ‘in anger’ and tuned for performance. There is a lot to set up, but the process for MD_SmartCar is made easier by following logical steps, building up from simple to more complex activities.

This article outlines these steps from beginning to end, at which point a full application can be built using the configured core code.

The core library, configuration, setup and application sketches referenced in this series of articles are available in my code repository as the MD_SmartCar library.

Bench Testing

All preliminary SmartCar testing is done at the ‘bench’, with the car attached to the USB cable for diagnostics and setup.

I found it useful to create an vehicle support stand to allow the wheels to rotate freely. This started as two loose wooden blocks, but they kept moving and falling over.

A better solution was to make a rigid stand (below). The assembly keeps the blocks consistently spaced and stable. The small platform is to support the rear castor and keep the vehicle level.

Configuration Parameters

Setting up and tuning the SmartCar controls is a straightforward exercise. There are quite a number of vehicle parameters that need to be determined, falling into 2 main categories:

  1. Physical constants related to the various components of the SmartCar. These constants are passed into the library by the application in the begin() method.
  2. Software parameters for the control system. These include a number of items that are worked out by trial-and-error during the Startup and Tuning process described below. These parameters are stored in processor’s EEPROM and directly accessed by the MD_SmartCar library during initialization.

Physical Constants

The physical constants are the easiest to determine as they are directly measured.

  • The wheel diameter in mm. This is measured to the outside edge of the wheel tyre. This is the 2r used in the Unicycle Model calculations.
  • The base length is the distance between wheel centerlines in mm. This is B factor used in the Unicycle Model calculations.
  • The number of encoder pulses expected per wheel revolution. One pulse is received for each edge transition of the encoder, so this is double the number of gaps, or white spaces, of the encoder wheel.
  • The maximum number of encoder pulses per second at top speed. This is measured, with the motors running at PWM setting 255, during the steps verifying the correctness of motor wiring and setup below.

Testing Interface

The user interface for all the test programs is implemented using the MD_cmdProcessor library. This is a simple implementation of a Command Line Interface (CLI) explained in a previous article that takes its input from a Serial stream. This makes it equally useful for use with the Serial Monitor and USB connection to the programming computer, or a Bluetooth interface to a remote app.

Startup and Tuning

Motor Wiring and Wheel Rotation

A common trait of all the supported DC motor controllers is that there is no ‘correct’ way to wire them up. The direction of motor spin relative to vehicle body depends on the orientation of the motor, how the gearbox works, and the way the motor is wired, so this needs to be worked out by testing.

The first step is to use the MotorTest example sketch and the Serial Monitor to ensure that the motors are turning in the correct direction and the encoders are working correctly.

This is done by temporarily making the connections between motor and controller and using the test software to drive the motor ‘forward’. If it spins in the wrong direction, reverse the motor wiring.

The encoder feedback can also be tested now – you are looking for the test software to print counts for both encoders when the motors are running. The encoder feedback is printed every second, so the maximum number of pulses per second is just the lowest of the observed counts at the maximum speed setting (PWM 255). Note that a small difference in counts is normal due to different properties of the two motors.

Now is also a good time to determine the lowest viable PWM setting that keeps a motor turning once it has already started. Starting from a high PWM value, slowly reduce the speed until the motor no longer turns. Note this value for when we set the low PID control limit value.

Calibration Parameters

The next step is to use the Calibrate example sketch and Serial Monitor to determine software configuration parameters and store them in EEPROM.

While setting parameters, it is a good idea to save parameters to EEPROM on a regular basis. The saved parameters can be reloaded from EEPROM at any time – useful when a change has upset a previously viable set of parameters. You will also save the final parameter set before progressing to the next step.

Kicker PWM

The kicker PWM is the PWM speed setting needed to start a motor.

Internal mechanical and electrical friction means that there is a minimum threshold below which the power supplied by the PWM signal is insufficient to get a motor started.

When drive() initiates PID speed control of the motors, it could be for speeds less than the kicker value. So, for low speeds and a standing start, the kicker PWM is set as the initial speed for a short time to ‘unstick’ the motor before the actual (lower) speed is set.

The kicker PWM should be set slightly higher than the PWM value found by experimentation.

Precision Moves PWM

The move() method enables precise movements using a predefined PWM setting. This setting is a compromise that needs to be tuned by experimentation, and should be

  • higher than the kicker setting to so the motor starts with no problems.
  • low enough to minimize or eliminate the amount of coasting at the end of the move() method.

PWM Control Limits

The control limits are the lowest and highest outputs allowed by the PID controller.

  • The lower limit is the lowest PWM setting that keeps a motor running when is has already started. This should be lower than the kicker or precision move PWM settings.
  • The upper limit will generally be set at 255 (the maximum) unless there is some other reason to make it lower.

PID Tuning

PID tuning is the most time consuming and complex part of this setup, but the defaults Kp, Ki and Kd parameters should provide a good starting point for TT type motors at least. You should expect to have a high Kp, no Ki and a relatively small Kd (this is really a PD controller).

The step uses the Calibrate sketch and SerialStudio application (found here) connected via USB. While the Serial Monitor could be used to view the raw numbers output from the library whilst tuning the PID loop, SerialStudio can act like the Serial Monitor but also provides superior data visualization and amore pleasant tuning experience.

Full detailed instructions for this are found in the library documentation (docs subfolder). The MD_SmartCar library directly supports SerialStudio by outputting data suitable for real-time charts of PID tuning outputs in real time.

PID values can be set independently for Left and Right motors if required. In most cases one PID setup for both motors should be adequate.

Once you are happy with the performance and stability of the PID control parameters, save them to EEPROM.

Floor Run Fine-Tune

This final testing is all about testing the vehicle ‘in real life’ as it moves about on the floor. The dynamics of this situation are likely to be different from the previous bench testing, so some additional parameter tuning may be necessary.

The step uses the Setup_Control example sketch and the related App Inventor 2 (AI2) application code found in the example’s sketch folder. The AI2 application provides a GUI front end for commands through a Bluetooth interface. The same commands could be issued from the Serial Monitor (or other Terminal program) connected through a Bluetooth serial port or with a serial umbilical connected to the vehicle.

The AI2 application has a main menu leading to displays for testing controlling drive(), move() and spin(), a terminal window to monitor vehicle messages, and a setup screen for changing the configuration parameters discussed above.

Spin Derating Factor

This is the last of the setup parameters and needs to be worked out by observation.

When the vehicle executes a spin() and stops, it will continue to move for a short time due to its inertia. This parameter is a ‘fudge’ factor to stop the motion before the actual end (ie, de-rate the spin) so that the vehicle will coast to approximately the right spot.

This factor defines the fraction of the full rotation motion (for example, 0.7 will stop the motion 70% through the required steps) and is a compromise of the results for long rotations (more momentum) and short ones (less momentum).

Checking Kicker, Move and PID parameters

Carry out a final check of these parameters in action with the vehicle moving its own weight around. The parameters can be modified from the setup screen of the AI2 app if they need further tuning.

In the next and final part we finally implement a SmartCar robotic random-rover application.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s