Catching a Bus: Prototyping a wireless robot control box with MikroElektronika Click Boards
The mobile robot and its remote control.
I have been playing around with a Parallax BoE-Bot mobile robot chassis for some years now. It’s featured in a number of my DS blog posts too, see Sensing and Control with FORTHdsPIC for example. More recently I upgraded its Arduino-format dsPIC33FJ processor board to a Clicker 2 dsPIC33E board from MikroElektronika (Porting FORTHdsPIC to a MikroElektronika Clicker 2 Board). My regular reader will know that the word FORTHdsPIC has appeared many times in these DesignSpark missives because I’ve used the excuse of writing a FORTH language interpreter/compiler for embedded applications to indulge my interest in assembler or ‘bare-metal’ programming.
The aim of this project was to equip my mobile robot with wireless control. A secondary objective was to make a functional hand-held controller from a commercial modular prototyping system without using any solder.
No Smartphone involved
It’s tempting to say: ‘Why go to all this trouble, why not control the robot from my Smartphone?’ Have you ever seen a professional drone or robot submersible driven from a tiny touchscreen? What you really need are good old-fashioned mechanical joysticks, the sort that video games consoles used to have. My two-wheeled buggy requires so-called ‘tank’ steering, which means that the direction of travel is determined by the relative speeds of the two wheels. Tank steering does not necessarily mean skid steering – see Give your Robot the Mobility Control of a real Mars Rover: Part 4.
Given that I’d already ported FORTHdsPIC across to the Clicker 2, it seemed logical to use one for the control unit and another for the robot itself. The MikroElektronika system turned out to be a good choice for a number of reasons:
- The dual expansion headers on both the Clicker 2 and the Click peripheral modules make for good, solid connections without the need for bolts and stand-offs. The Arduino Shield format is similar, but the Raspberry Pi has always had the weakness of a single expansion socket.
- All Click modules feature two 8-pin parallel headers providing access to, amongst other things, UART, SPI and I2C serial bus signals. The Clicker 2 processor board has two of these mikroBUS sockets. I used one for a USB-UART bridge Click, the other for a wireless Click.
- To provide forward/reverse and speed control for each motor, I needed a single-axis joystick with an analogue output and a spring bias to the halfway position. Fortunately, the Click range includes a two-axis ‘Thumbstick’ module with an on-board 12-bit ADC and a SPI bus interface. The unwanted x-axis data is just ignored. The two Thumbsticks had to be mounted side-by-side, but the only mikroBUS sockets on the MCU board were already taken. So…..
- In addition to the mikroBUS sockets, the Clicker 2 also possesses a pair of 26-way headers, one on each side. These make it possible to attach a large expansion Shield, the same size as the MCU board, which contains two more side-by-side mikroBUS sockets. The Thumbstick Clicks plug in to these.
- The range of RF wireless Click boards is extensive. Perhaps too extensive, as it can make choosing the ‘right’ one a lengthy process. This application does not call for a high-speed, wide-bandwidth, mesh-network or long-range solution. This eliminates Wi-Fi, Bluetooth, LoRa etc. with all the software complications they entail. Instead, I opted for a simple 2.4GHz low-power, packet-protocol link using the NORDIC nRF24L01P chip frequently used on Arduino-based wireless projects. This device can be found on the nRF T Click module.
- A final requirement was for battery operation: control units and indeed, mobile robots, can hardly be considered ‘wireless’ while plugged into a wall-socket. The Clicker 2 has this covered too, as it has a connector for a Li-Po rechargeable battery together with a Power Management chip (PMIC) which handles charging from a USB socket. The 3.7 volt 2000 mAh battery wedges in nicely between the MCU board and the expansion Shield.
MikroElektronika Clicker 2 for dsPIC33E MIKROE-2567 (144-8343)
mikroBUS Shield for mikromedia MIKROE-1154 (791-6485)
Thumbstick Click mikroBUS (2) MIKROE-1627 (882-9014)
nRF T Click mikroBUS MIKROE-1305 (136-0698)
USB-UART 3 Click mikroBUS MIKROE-3063 (184-0913)
RS PRO Li-Po 3.7V 2000mAh battery SR674361P (125-1266)
The big advantage of using these sort of rapid-prototyping systems is that detailed hardware circuit design is minimised. All you need to do is construct a diagram like that in Fig.1 which shows how all the serial bus systems relate to the relevant I/O pins on the MCU. This information is needed for the development of application firmware.This particular dsPIC33 device contains four independent SPI channels, four UARTs and two I2C channels. The remote-control uses SPI bus 2 for the wireless Click, SPI bus 3 for the two Thumbsticks and UART 1 for the PC terminal. SPI 2 has a fixed assignment of MCU I/O pins, but SPI 3 and UART 1 pins can be selected by the user firmware.
Just plug it all together (well almost)
There is just a bit of soldering to be done: the 26-pin stacking headers need to be soldered onto the Clicker 2 and Shield boards. After that, it takes just a few seconds to assemble the complete unit. The advantage of using a modular prototyping system with dual-in-line headers to join it all together now becomes apparent. You have a solid, compact unit which can be held in the hand and tested without needing to put it in a case. Just keep your fingers off the wireless Click and its PCB antenna!
There are three approaches to firmware development which can be applied:
- Code it in dsPIC33 assembler language. This involves using the free-to-download Microchip MPLAB X IDE to generate a .HEX file which can be Flashed into the Clicker 2 program memory via its on-chip bootloader. It represents the ‘hard way’ as you may need to develop all the peripheral device drivers yourself.
- Code it in C, Pascal or BASIC and generate the .HEX file using the appropriate compiler from MikroElektronika. These compilers are not free-to-download, but it’s probably the quickest and easiest method because all the device drivers are supplied in a library.
- For lovers of the Forth programming language, called masochists by some, there is my free-to-download FORTHdsPIC, the latest version of which is tailored for the Clicker 2. The advantage is that once FORTHdsPIC has been Flashed into the Clicker 2 program memory, all subsequent application coding is carried out via a terminal emulator running on a Windows PC. Lines of Forth source code can be typed in and executed immediately or downloaded as .TXT files, compiled and run on the Clicker 2.
The basic function of the controller is to monitor the positions of the two Thumbsticks and transmit the data to the robot via a 2.4GHz RF wireless channel (Fig.2). Thumbstick Click features a 2-channel 12-bit ADC chip, the Microchip MCP3204: only channel 0, the ‘Y-axis’, is used here though. The stick is biased by a spring to the mid position of a potentiometer. The output value of the ADC will be about 2047 at this point and the corresponding motor will be stationary. Pushing the stick forward increases the value to a maximum of 4095 – full speed forwards. Similarly, pulling it back to the other extreme yields 0 – full speed backwards. These 12-bit numbers are scaled back to 6-bits by the program because the lower resolution is perfectly adequate for controlling the motors, and only one byte needs to be sent for each over the wireless channel.
For testing and subsequent checking that the remote is indeed working, I’ve included a routine that turns on one of the Clicker 2 User LEDs whenever the corresponding Thumbstick is moved from its neutral position. Of course, this doesn’t mean that the wireless link is working. This same visual check is also incorporated into the receiver code on the robot, but in this case, LED(s) flashing in response to Thumbstick movement does mean successful RF operation.
I’ll describe the Click wireless link, based on the Nordic Semiconductor nRF24L01+ chip, in a future article on the robot electronics.
The source code for the latest version (0.9) of FORTHdsPIC and the Forth program for the remote control are attached as downloads below. Having discussed the basic operation of the SPI bus in a previous post, this article is intended to show how it works in practice. The low-level assembler-coded SPI drivers MSPIO2, MSPIO3, CSLO and CSHI can be found in the FORTHdsPIC source file. Forth word JOYSTK, defined in the remote source file, uses the driver code to extract a 12-bit value from the Thumbstick’s ADC chip. Read the source code in conjunction with the MCP3204 datasheet.
FORTHdsPIC development system
The first two suggestions for developing the firmware listed above, do not require the USB-UART bridge Click for sending code to the MCU: the separate micro-USB socket is the port for the on-chip bootloader. FORTHdsPIC itself is Flashed-in via the bootloader, but subsequent Forth coding needs a virtual COM port on a PC running a terminal emulator such as the open-source Tera Term.The bench setup for this wireless remote-control project. Both the joystick unit and the robot are connected by USB cables to a laptop running independent terminal windows for software development purposes.
Close-up of the PC screen. It makes life a lot easier being able to run and debug both the transmitter and receiver target systems on the same screen at the same time! The Forth source code is edited in a simple text editor such as Windows Notepad and stored as a .TXT file. The Send File function in Tera Term is used to download the source code into the Clicker 2 where it’s compiled into run-time code.
Debug in RAM, Run in Flash
A characteristic of any ‘embedded’ system is that it powers up into its application program without the need for human interaction or loading RAM from a hard-disk. In other words, the code needs to be in non-volatile memory that runs straight from power-up reset. FORTHdsPIC normally saves the compiled run-time code in RAM, but if the word SETFLSH is executed from the terminal first, the source file sent as normal and FLASH executed immediately afterwards, then the code is saved in the MCU Flash memory instead. Both USB cables can be disconnected and the USB UART Click removed if desired. Switch both remote and robot to battery power and away you go!
The next part of this ‘Catching a Bus’ series will feature the IIC or I2C serial bus: not as fast as the SPI but only 2-wire, no matter how many Slaves are connected. After that comes more detail on the robot controller which also has Clicker 2 and nRF Click boards at its heart. I’ll provide more detail on the (extremely simple) wireless protocol and show how the MCU talks to the ultrasonic rangefinder via an I2C bus.
If you're stuck for something to do, follow my posts on Twitter. I link to interesting articles on new electronics and related technologies, retweeting posts I spot about robots, space exploration and other issues.
CommentsAdd a comment
Hmmmm. About your comment of touch screen joying. Did you know that the Dragon is flown by touchscreen? The astronauts don't have joy sticks. It's how your write the programme that counts. Not the technology. I've seen people fly drones with those pesky little screens. The programme used the phone's accelerometers
@torontofred I agree it's not about the technology - hardware or software. It's the human factors or ergonomics that matter. The Crew Dragon has a touchscreen HMI for manual control with 'soft joysticks'. The 'flying' consists of firing thrusters to keep on-screen crosshairs over the ISS docking target superimposed on the same screen. The task is pretty simple, but the spacecraft dynamics make it very difficult to do and it requires a lot of training on a simulator. Fortunately, it's all done so slowly, for safety reasons! Take a look at the video in the following link of Doug Hurley manually driving the spacecraft: https://www.theverge.com/2020/5/30/21275753/nasa-spacex-astronauts-fly-crew-dragon-touchscreen-controls What makes this elegant interface usable? The 'weightless' environment. Imagine having to use muscle power to hold your fingers close to the screen for more than a few seconds. Imagine too if many rapid actions are required with your focus away from the touch pads. Yes it can be done - but it increases the scope for missing the right button in a stressful situation. Even modern airliners have manual controls that require continuous input - not just occasional taps on a screen, which is why the Airbus A380 has a 'mechanical' joystick attached to a comfortable armrest. Boeing have chosen to retain the old-fashioned steering yokes on their aircraft. Both these systems allow the pilot to remain 100% focused on the instruments or the view through the window. I still have an original AR Drone controlled by an iPhone through it's tilt accelerometers. It was very difficult to fly as you tried to watch the camera view while waving the phone around!