The first part of this series was an introduction to the core hardware for the SmartCar platform. This article covers the power supply, controller and sensors.
One design decision I made early in this project was to use screw terminal connectors wherever possible to make it easy to move wires around.
Many similar projects use duPont connectors but I have found them too easy to dislodge. Screw terminals provide a positive clamping force that resists vibration/rough handling and maintain good electrical contact.
When powered by my bench power supply, with motors running at 100% PWM and all other systems active, the total current draw for the SmartCar was less than 500mA.
During autonomous running, the SmartCar is powered by a 3S 11.V 700mAh LiPo battery pack. The battery has good enough capacity, is relatively small and fits neatly in between the decks of the SmartCar, held in place with a velcro loop.
The LiPo battery voltage is regulated by a couple of step-down buck converters adjusted to give the required output for the motors and electronics. A switch mounted on the robot disconnects the battery to turn the robot off.
A bonus of using this arrangement is that the buck converters isolate the motor controllers PWM electrical noise from affecting the digital circuits.
The motor regulator is located inline with the wiring for the motors, in the bottom section, and attached with a small piece of velcro to the deck to stop it moving.
The digital supply regulator is mounted to a small piece of prototyping PCB on the top deck of the SmartCar, where all the digital circuits are. The regulated output is distributed to six pairs of screw connectors, convenient for connecting the controller and assorted sensors.
For the brains of the robot I decided to use an Arduino Nano. These are freely available, inexpensive and have a built-in USB connector. Screw connector PCBs for this footprint are also commonly available cheaply.
Sensor Hardware (Application Specific)
The most basic sensor for any SmartCar is a bumper switch. These come in many designs, as illustrated below.
The cheapest of these are simple ‘whisker’ type arrangements – inspired by the RedBot bumper above – implemented in the photo below.
The whiskers are made from bent piano wire. Electrical contact is made between the wire and the nuts on the prototype PCB board when the wire hits a solid object and bends back.
The base of the wire is connected to a digital I/O pin pulled high. Closing the circuit shorts the input to ground and the bumper switch is detected as ‘active’.
In practice the whiskers are adequate, but they occasionally get hooked on objects when the vehicle reverses. A better design is probably needed for a future version.
The SmartCar needs some form of distance measuring sensor to avoid hitting other objects.
A common and inexpensive solution for this is the HC-SR04 Sonar sensor. This device has a simple interface and is well supported by the Arduino community, with several libraries available.
This project uses three sonar sensors – one at the front and one on each side – attached using simple support brackets. As the most useful distance is measured in the forward direction, an alternative arrangement would be to use one sensor mounted on a servo and sweep it side to side, like a radar turret, when the side distances are needed.
These sensors emit a modulated ultrasonic ‘ping’ and measure the time for the echo return. This time is converted to a distance by using the speed of sound through the air (which is also dependent on the air temperature, but that is mostly ignored in applications).
The normal interface for this sensor uses 2 pins (Sens and Trig) but the NewPing Library (available here) can use one processor I/O pin for both signals, saving me 3 digital I/O for other uses. The library also performs all the required calculations and returns the distance measured.
The ping sensors performed quite well in detecting solid obstacles (walls, bodies, hard furniture) but were inconsistent in detecting anything covered in softer materials (cushioned furniture, curtains). Some form of LIDAR (like a VL53LOX time of flight distance sensor) may be worth the extra expense in a future implementation.
A light sensor is optional, but is useful to implement behaviours that move the SmartCar towards or away from a light source.
A simple implementation uses two Light Dependent Resistors (LDRs), raised above the height of the vehicle, to discriminate light levels on either side of the sensor (shown below).
The LDR connection is a simple voltage divider to the controller’s analog inputs. I designed the sensor to be tall and pluged into a socket on the top deck of the SmartCar (see below). The sensor was positioned to measure light either side of the vehicle, but could equally be rotated for front/back and back measurements instead.
While not strictly a sensor, wireless remote communications with the SmartCar are a useful feature that allows for remote control and telemetry monitoring data.
A functional and inexpensive solution is a Bluetooth serial link. I had a HC05 module at hand and so used it for this purpose.
The BT module is also plugged into a socket (see photo above) on top of the rover. As the HC05 needs 3V signals, the socket provides the simple voltage divider (circuit above) to convert the Arduino 5V transmit into the BT 3V signal; the receive signal works without conversion straight from the BT module.
Using sockets for the light and BT modules also enables me to reuse them on other robots if needed.
SmartCar Hardware Assembled
The photos below show the SmartCar with all described hardware installed.
The next part of this series will discuss the control philosophy used to manage the SmartCar.