I had the idea of making a radio-controlled car "my way" for a long time. My main goal was to create an FPV vehicle I could control from the internets using components that gave enough freedom for customization and replacements of parts once obsolescence kicked in.
Last year a group of students of mine started an open source electric wheelchair project. I spent some time over the summer completiing their work and learned a couple of practical things in the process. The details of that project can be found here: Open electric drive kit for wheelchairs - alpha v. The control board of the wheelchair had a BLE module that could be used to control the wheelchair from a mobile phone (don't ask me how this feature was justified) and I had the chance to learn how easy it is to implement basic BLE communications.
This gave me the idea of using BLE as the means of communication between hardware elements. Perhaps it is a very bad idea for real-time "life-critical" applications, perhaps from the design point of view it is a poor option because of all the physical complexity and the reliability concerns this brings, HOWEVER it is certainly an attractive option to keep hardware elements electrically separated, reusable and easy to debug (you can play with it with your phone/laptop/etc).
So fast forward to the last few weekends, I took some hardware I had kept in my cupboard for ages and put together a quick prototype of an Arduino-controlled car with BLE communication. I used the chassis of the old robot project our 1st year students used to do and I got this ugly monster running:
I used an Arduino Nano because of the form factor, a TB6612FNG H-bridge MOSFET motor driver to drive the two DC motors and an (obsolete?) mRF8001 module from Adafruit for the BLE communications.
On the software side, I borrowed the Arduino code from the wheelchair project, which provided a simple means of reading joystick commands from the BLE stream and translating them into the PWM signals given to the motor driver. This software is fairly sophisticate and includes a few interesting features such as a jerk/acceleration limiter and a cruise control. The original phone app that was developed for the wheelchair project could be used to control the car straightaway. Again, you can find all the details in the page of the wheelchair project.
This worked very well as a proof of concept but I wanted to make the prototype more sturdy before proceeding to the next steps. On the following weekend I made this improved version:
(a "snow plow" accessory was added on the front to make this push stuff around)
An assessor here demanded that the car was painted in a fabulous colour scheme and I placed all the circuitry on the bottom of the base using the ugliest hot-glue cable management known to men:
Breadboards are the worst friend/enemy of electronic engineers, therefore I made a PCB adapter to replace the spaghetti breadboard circuitry by something more sturdy and "electrically better". This PCB is fairly simple:
There are a couple of tricks anyone planning to make a PCB using a mill or DIY etching should take into account. For instance, holes aren't plated, therefore the two pads (ie top, bottom) for each leg of a through-hole component have to be soldered if there are traces reaching them from both sides. This is OK to do with some components that leave the legs exposed on the top side but it is a serious nightmare with others. The lack of solder mask only makes the problem worse because it is harder to keep the solder from running away from the pad by the track.
Further, bias aren't plated either and they have to be connected manually, typically using a short piece of wire soldered from both sides. The easiest bias to solder are the ones where the copper area on one side is significantly bigger than the copper area of the other side: if you solder the side with the big copper area first, it is unlikely that this side will become loose when soldering the opposite side. Corollary: soldering bias connecting to a plane is "piece of cake".
Details like this can make a massive difference. When I made this PCB I had forgotten about some of this and wasted 30 min trying to solder just a few pins of the original PCB before I decided to fix the design and produce a new one where pins would be connected on the bottom side only. I completed soldering this one in about 20 min.
I also spent some time improving the software on the user input side. I didn't update the phone app but created a series of Python scripts to run on a BLE-enabled laptopm or a Raspberry Pi to control the car using a Joystick. I also found out that the code could be used straightaway to control the car from a USB dancing mat which was fun.
All the source material for the stuff I've just described can be found in the files section of the project with a brief description. You will find 2 Python scripts that control the car from a computer with BLE and a USB joystick, 1 further script that does the same but decouples the BLE communication and the interface to a USB joystick to run in two separate computers communicated by UDP and finally a zip file wground ith the KiCad project with the circuits and the PCB layout for the adapter board.
The next step is to place a Raspberry Pi with BLE+Wi-Fi and a Raspberry Camera on the car and to set up a video stream between the RPi and the laptop where the joystick will be connected. Hopefully, latency (or "lactancy" as some online forums suggest) will be low enough to enable some basic FPV control. I plan to use gstreamer for this and I already know how this can be done because I faced the same "challenge" when I worked on the Raspberry Pi Surveillance and the control of the JJRC H37 quad from a PC.
Stay tuned for the updates.