I’ve recently commenced work on a project focusing on building my own, self-driving RC tank. Such a project comes with a myriad of decisions, one of the most critical being selecting the right electronic hardware. From microcontrollers to sensors, motors, and communication modules, the choices made in this stage of the project will significantly influence the capabilities and performance of the vehicle developed in the future stages. In this blog post, we’ll discuss the Self Driving Tank Hardware Selection process.
Micro-Controller
The microcontroller selected for this project will need to interface with all the sensors installed on the vehicle as well as the external communication elements required for the system to operate. Using the information from the sensors, the microcontroller must perform complex calculations to ascertain the vehicle’s current position and generate control outputs necessary for achieving the present objective, be it a fixed heading, waypoint navigation, or a return-to-home scenario.
Most of the sensors required to determine the current position of the vehicle make use of the I2C or SPI communication protocols and luckily these are generally standard features on a microcontroller – meaning most of the microcontrollers we can choose from will have these buses available. Unfortunately, what is not a common feature is having numerous serial ports. Numerous serial ports are required for several reasons namely integrating with GPS units, RC receivers and telemetry. This is something which must be considered when selecting the microcontroller – what is most disappointing is the requirement for multiple serial ports means that the Arduino boards such as the uno and nano are immediately disqualified.
Last but not least, clock speed is another important consideration. As discussed above, the micro-controller must be able to perform complex calculations, a processor with a low clock speed will not be able to perform these calculations (and all the other tasks required for such a project) in a timely manner. If the position and control calculations cannot be performed promptly, large errors in the position estimation function will build which will inevitably lead to poor control performance. Whilst poor control performance in this RC Tank project may not result in significant damage to the vehicle or environment, it is important to note this project, especially the basic software and hardware is intended to be the starting point for a future quad-copter/drone control project. So all opportunities for poor performance must be eliminated as a matter of course.
Arduino Nano / Uno (Atmega328)
The Arduino Nanp can immediately be omitted from consideration. The nano only has one (hardware) UART available and this is reserved for communication with the host PC. This means a form of software serial would be needed to interface with the GPS and the selected RC Reciever. Software Serial (especially on the Atmega328) is far too slow to maintain the data rates required to integrate with the RC controller and GPS.
As a result, the UNO can be eliminated.
Arduino Mega (ATmega2560)
The Arduino Mega is everything the nano/uno is not. It has four UARTs (one of which is reserved for PC<->Microcontroller communication, which leaves three spare for integration with RC receivers, GPS units and telemetry radios. The mega also provides 54 digital pins and 16 analogue pins, these can all be used to interface with external components and sensors. Unfortunately, the clock speed of the mega is only 16mHz – this provides limited processing power, which whilst in the early stages of the project will probably be fine, provides limited opportunities for expansion in the future. It is for these reasons, in combination with the size, that the Arduino Mega can be rejected.
STM32 F405
The STM32 F405 is a microcontroller which is ubiquitous in the flight controller/ROV community. It features many interfaces (6xUARTs, 3xSPI and 3xI2C) which can be utilised for interfacing with external sensors and equipment. It also is capable of having a clock speed of 168MHz, which means it is capable of performing intensive control calculations. Unfortunately, it is not readily available as a breakout board – this, unfortunately, means this MCU must (initially) be rejected. Hopefully, when the project develops further and my PCB design and soldering skills develop, it will be possible to integrate the STM32F405 MCU into this project.
STM32 F401
The STM32 F401, has 3xUARTS, 4xSPIs, and 3xI2C interfaces which should be plenty of data buses for interfacing with the various sensors in this project. Whilst not as fully featured as the F405 MCU described above, it is readily available as a break-out board, making it ideal for prototyping the tank control software. Due to the plentiful IO and readily available breakout board, this microcontroller has been selected for use to develop the initial software build.
Sensor Selection
Inertial Measurement Unit
The inertial measurement unit can measure the rotational velocity and the normal accelerations that are present in the vehicle. Using this information it is possible to determine the vehicle’s current attitude. Furthermore, by integrating the normal acceleration twice it is then possible to dead reckon where the vehicle has travelled when compared to its starting location. The extent to which these functions will be used in this project is not currently clear, but I believe this functionality will be useful, even if it is only for telemetry.
The MPU-6000 is regularly used in a variety of commercial flight controllers proving that its performance is satisfactory for attitude and navigation control for drones etc. Its sister part, the mpu6050 is regularly used by hobbyists and industry alike. It is the same as the MPU-6000 except it makes use of the I2C bus instead of SPI. I think in the future the MPU-6050 will be replaced by some other sensor – which makes use of fancy sensor fusion technology, such that it can be offloaded from the main MCU.
Pressure Sensor
Much like the inertial measurement unit, the usefulness of the pressure sensor is not immediately clear in this project. However, it may have been used in determining the position of the vehicle vertically, especially when compared to the start point.
The BMP280 was the only pressure and temperature sensor considered for this project. The sensor provides reasonable accurate pressure and temperature data which can then be used to ascertain the vehicle’s altitude.
Most importantly the device is one which I am reasonably familiar with and I fully understand its quirks.
Global Positions System (GPS)
Most of us use a GPS of some kind every day – so hopefully its applications in this project are relatively obvious. The GPS unit will be used to determine the position of the vehicle relative to the rest of the world. The unit will also provide information such as velocity and altitude. There are many different GPS units on the market, all of which will provide this data as it is part of the standard.
The BN-880 was selected for this project. Again, no major consideration was given to the selection of this GPS unit – I merely had one lying around. The GPS module does use UART to provide the GPS data which is a bit of a pain – as the UART protocol is generally quite slow. Whilst this is fine for a reasonably slow application like a tank this is probably fine. Whilst for a faster vehicle such as a drone then it may the UART interface may be limiting. Saying that though, Ardupilot and Betaflight make use of UART GPS’ so regardless of the vehicle, it is probably fine.
Compass
A compass whilst not essential for navigation – certainly will make the process easier. By using a compass we can ascertain the vehicle’s heading, which will allow us to easily navigate from way point to way point.
The BN-880 GPS has an internal compass, specifically the HMC5883L compass – this was the main (only) reason for selecting this compass. The assumption is that it will be fine – but if testing reveals any deficiencies. Again this is sometimes used by Ardupilot and Betaflight so the assumption is that it will be fine.
Communication Systems
RC Reciever
The RC receiver, regardless of which is selected will primarily be used to transmit control instructions from the user (Me!) to the vehicle. Such commands will include the throttle command, steering as well as the mode selection.
Custom receiver
A custom receiver will be, as the name implies, custom. This means I can support as many channels as I like and I can encode as many channels as I like. One of the main drawbacks of doing this is that I will be required to develop a custom transmitter. This is potentially a lot of additional work – something, which I want to avoid for the initial stages of this project.
SBus based receivers
Sbus is supported by many different receivers produced by many different manufacturers – this means there are plenty of options available when it comes to selecting a receiver and most importantly, most Sbus receivers are compatible with my multiprotocol TX16S transmitter – meaning no custom development work is needed! This does have some drawbacks though. Discrete signals such as on/off switches are encoded as a numeric PWM value rather than a boolean (1 or 0) and as a result, extra processing is required by the controller to ascertain the state of the discrete.
Sbus does have two major drawbacks though – it runs at a non-standard baud rate (100,000b/s) and is an inverted UART. The former is relatively easy to deal with – it just requires some software tweaks to be able to handle. The latter, however, is a bit more difficult to deal with. Most UART implementations on a microcontroller will not natively deal with an inverted UART signal and as a result, external circuitry to invert the inverted signal is required.
IBus based receivers
IBUS-based receivers are very similar to their SBUS counterparts. However, IBUS overcomes many of the drawbacks of SBUS. It uses a standard baud rate (115,200b/s) and it is “inverted SBUS” – this means no external circuitry is required to make this work with a microcontroller.
The only drawback associated with IBUS is the fact that it is only supported by one manufacturer – FlySky. Fortunately, FlySky is associated with being on the budget end of the hobby and as a result, the receivers are relatively cheap and readily available. It is for these reasons and those described in the paragraph above, that this project is going to use a FlySky Ibus receiver.
Telemetry
Using a telemetry stream, we can send whatever parameters we like to a remote laptop/PC. This will help significantly with the debugging process.
NRF24
When I first started this project, I thought an NRF24 would be the perfect choice for telemetry in the project, but following a small amount of research, I quickly realised this would not be the case. An NRF24 will transmit a maximum of 32 bytes in a single packet. This means every single message that is sent using this method will require some kind of pre/post-processing to ensure that it can be fitted into one or split into multiple transmissions – frankly, I cannot be bothered to do this.
Transparent UART
A transparent UART is exactly that, transparent. What you transmit on one side will be received in the same format on the other. No conversion is required! This makes the implementation super easy! A generic Transparent UART Radio was selected for this project. In the future, especially if longer-range missions become of interest, I will probably upgrade the radio to an RFD900 (or similar) radio.
Motor Drivers Considered
When you need to power any kind of motor you will need a switch of some kind. You could use a relay and set it up in an h-bridge configuration. This would work – partially – achieving any kind of granularity with the speed control will be difficult – as the speed at which the relay can switch is limited. In this scenario – where we want to control the speed of the motor, a MOSFET-based motor driver is probably best. It allows us to control the motor direction similarly to the relay, but it also allows us to properly control the speed of the motor by allowing us to provide a high-frequency PWM signal to the motor.
I thought selecting the motor driver would be simple. I wanted to use something off-the-shelf and readily available in the RC hobby – this, for me at least, turned out to be a mistake.
Generic PWM “RC” Motor Driver
When I first started this project, I thought the easiest approach would be to use an off-the-shelf Bi-Directional PWM motor driver intended for use with traditional RC receivers. I thought: “I’ll just use the Arduino servo library” – a sensible idea, right? Wrong – The two motor drivers couldn’t have been more different. The PWM value at which they armed differed by 100-200µS. Since the midpoint of the PWM range doesn’t match – it’s logical that the upper and lower bounds also differ by 100-200µS. This is fine, it can be easily accounted for in software. What can’t be easily accounted for is the inconsistent behaviour when a motor reverse is commanded. No matter how long I returned the throttle command to neutral, the motor drivers would seemingly go into reverse when they felt like it. This inconsistent behaviour is kinda fine when using manual control – but it is far from ideal when implementing novel control algorithms.
Ultimately, I think I cheaped out on these “PWM “RC” motor drivers and as a result, I got what I deserved.
L298N
The L298N, whilst a popular motor driver for hobbyists, is somewhat limited in its capabilities and performance. The L298N motor driver was excluded for the following reasons:
- Voltage Drop – this driver has a significant voltage drop across its circuitry, this means that less power reaches the motors and as a result, the performance of the motors is degraded
- Limited Current Handling, I believe the L298N driver can only support 2.8A, which might be fine for a small robot project. For this tank project, I think there is potential for the driver to be saturated, again limiting the performance of the motors.
- No current sensing – the L298N doesn’t provide native current sensing. It’s advantageous to record the current for each motor or set of motors – the absence of native current sensing means additional circuitry is required to achieve this.
BTS7960 43A Motor Driver
Ultimately, the BTS7960 was chosen for this project this was done for a multitude of reasons, honestly mainly for the reasons the L298N was disregarded above.
- Minimal Voltage Drop – This motor driver has a minimal voltage drop across its MOSFETs and as a result, the power lost to the motors is minimal
- High current handling – The BTS7960 is capable of handling high currents – While 43A is probably overkill for the motors required for this project, it’s good to have plenty of headroom when driving motors.
- Simple Bi-Directional Operation. I had no end of issues when it came to driving a motor in two directions using a traditional RC ESC. However, the BTS7960 manages the bi-directional functionality in a very simple manner. You just change which pin the PWM is applied to! Very simple and very robust!
Miscellaneous
Memory
By memory, I mean storage. There are two types of storage considered for this project. The first is EEPROM, which will be used to store configuration data over – the specific configuration data required – I am currently not sure but it has been included for the sake of completeness. The second stage medium is an SD card, which will likely be used for the storing of logs, mission and other data which need to be easily accessible. It would be possible to use a flash chip of some kind to store this data, but this would require an extensive software development process – something I wish to avoid.
Power
The power source selected for this project is 2x Lithium Polymer Batteries, each configured as 4s with a 2200mAh capacity. There are better-suited batteries for this particular project, but these are what I had lying around and they are capable of providing more than enough power for this project. The various voltages required by the many devices are also generated using LM2596 Buck Converters.
