Arduino Bluetooth Remote Control - Part 4 - Controlling Via BT

The previous Instructable (Part 3) showed how to control the speed and direction of a motor. There are also two LEDs which indicate forward/reverse.

This part will split the inputs and outputs and use Bluetooth to connect the two halves. One Arduino board will have the inputs and be called the Controller and the other will have the LEDs and motor and be called the Gadget. The terms transmitter and receiver are not really appropriate because both master and slave modules can transmit and receive data so I will use the terms Controller and Gadget. The master BT module will be in the Controller because it can communicate with more than one slave BT module and it may be desirable to have more then one Arduino board at the Gadget end if that thing gets complex.

The hardware is easy, it is just the previous motor circuit split in two and the BT modules added.

What is needed next is a way for the Controller to tell the Gadget what settings are needed. A set of commands can be designed to control the state of the LEDs and the speed and direction of the motor.

The method must allow for corrupt data or incomplete information arriving.

Step 1: Controller Circuit

The Controller has the BT module in pins 2 and 3, The switch in pin4 and two LEDs driven from pins 11 and 12.

The LEDs have been retained to show that the switch is doing its job.

Step 2: Gadget Circuit

An Arduino Uno is shown in the Circuit as it's easier for testing but it could be another type, for example a Nano would be better for a mobile Gadget. The pin connections will be the same.

The BT module is in 2 and 3 as before.

The H-bridge is driven from 8,9 and 10.

The LEDs are on 11 and 12.

The motor should have a small capacitor to smooth things out and the H-bridge connection should have 1K resistors to help protect the Arduino.

Step 3: Communications

Now the commands can be designed.

There needs to be a set format for the data so that it is possible to identify a command and know that it is a correct one, not just some random data. This is a whole industry in itself but a simple "protocol" can be invented which will do the job.

Each command will be exactly 6 characters long and will have a parameter which is up to 6 characters.

Each command will begin with the '@' symbol and end with the '#' symbol. The command itself can not contain '@' or '#' symbols of course.

So now a valid command can look like:

@SPEED 150#

The command begins with '@', the next 6 characters are 'SPEED ', then up to 6 characters '150' ending with '#'.

For this project there are four command types, with their possible parameters:

SPEED , 0 to 255, sets the motor speed

LEDRED, ON or OFF, turns red LED on or off

LEDGRN, ON or OFF, turns green LED on or off

DIRECT, FORWRD or REVRSE, controls the motor direction

The data sent from the Controller could look like:

@SPEED 0#@LEDREDON#@LEDGRNOFF#@DIRECTFORWRD#@SPEED 120#

and so on.

Step 4: Controller Program

The beginning of the program sets up some pin assignments and starts up the Serial Monitor and BT module.

The rest of the program loops around reading the switch and pot values and sending them to the BT module.

String variables are used to build up a command line which is "printed" to the BT module. A delay is applied each time a command is sent.

An important consideration in communications is timing. If the Controller sends data faster than the Gadget can receive it, information will be lost and the remote control won't work very well.

The program loops around and sends all the input values every time, so 4 commands are sent per loop. The total time for these can be adjusted using delays. The time required for the other parts of the program is minimal because simple instructions like these are executed in microseconds.

There should be a complete set of control values sent about three times per second and that would be plenty fast enough for our simple control project. The UART speed of the BT modules could be increased if the transfer was too slow. That might happen with more complex projects. Both modules would need to be set to the same UART value, say 38400 for example. Note this is nothing to do with the 9600 comms rate to the Serial Monitor.

Step 5: Gadget Program

The Gadget program is a little more involved.

The definitions include strings to hold the command and the two parts of it, "command type" and "command parameter".

Delays should be avoided in this program. If the program runs too slowly then some commands may be lost.

The program loop will execute these steps:

Get a command from the BT module

Identify the command type

Execute the command

Repeat

The program is structured so that the main loop identifies the command then calls a function to process it. This makes it easy to add a new command into the main loop and have a separate block of code to execute the command. A servo may be added for example. Chasing down bugs is also made much simpler with a good program structure.

A function called GetDataFunction is created to read a command from the BT module.

(The function call is equivalent to gosub GetDataFunction in BASIC).

The command is then broken into cmdtype and cmdpara.

The command must be in the list of "if" statements to be executed. Any invalid commands are ignored. An invalid command could be due to corrupt data or bad comms timing for example.

The functions which execute the commands are simply like those in the motor control program.

Hope you enjoy this project.