Refresher and Intro
C-BISCUIT stands for Collaborative Bot with Integrated System Core, Unmanned Interactivity, and Telemetry. It is intended to be more of a platform for robotics projects, not a specific robot. This platform is based on the Raspberry Pi 3, which has WiFi and BlueTooth capabilities, which saves us a lot of troubleshooting for connectivity. RPi also has an active community for support, so anybody looking to add their twists to their versions of C-BISCUIT won’t be alone.
However, we need to test and demonstrate the platform, and for that we need an actual robot. The previous article in the C-BISCUIT series discussed various components of the overall project, as well as the overall system design.
At this point, it is time to finalize the system architecture and integrate the components into a well-oiled machine!
As is often the case in life, the final version does not look exactly like what was originally planned. In fact, we originally started with a Wandboard instead of an RPi 3 but struggled with the software for the camera feed, if you’d like to attempt to using Wandboard, you can read about our misadventures on All About Circuits.
At this point the primary components of the demo bot are the following:
Here is a system diagram:
Now let’s take a look at each one of the system components.
A Frame for the Bot
There’s not much to say about the Tri-Track. We like the tank-style treads, we like the way it looks, we like that it has only two motors, and it seems spacious enough for the C-BISCUIT hardware… but mostly, we like the tank treads.
A Brain for the Bot
Eventually, we want to implement machine-vision algorithms that will allow the Raspberry Pi 3 to influence the robot’s behavior based on input from the camera. Fortunately, the RPi 3 has a convenient connector for the Pi camera.
In the demo bot, the RPi 3 is responsible primarily for three things: receiving image data from the Pi camera, transferring this data over Wi-Fi to a laptop that will display the imagery, and communicating with the Robot Control Board.
The Raspberry Pi 3’s WiFi module makes our job much easier. Courtesy of Stack Exchange.
Powering the Bot
The original plan for the power source was an 11.1 V, 5000 mAh lithium polymer (LiPo) battery. There is nothing specifically wrong with this choice and maybe we will return to LiPo if we are not satisfied with the 2800 mAh available from the NiMH battery mentioned above. Depending on the chassis you choose, a LiPo battery may be a better fit for your bot. However, the following considerations argue in favor of NiMH over LiPo for our bot:
It would be convenient to integrate battery-charging capability into the robot’s electronics; that way we could recharge the battery through a USB connection that is also used for communication between the robot and a PC. But that bonus feature hasn’t made it in yet. Instead, we have an off-the-shelf charger that will do the job nicely.
Controlling the Bot
Our idea here is to incorporate all necessary control and power circuitry into one custom-designed PCB. This will make for a cleaner overall solution—i.e., less wiring, fewer circuit boards to secure to the chassis, tighter integration, and greater customization. The Robot Control Board (RCB) has the following requirements:
Raspberry Pi 3 Comms
Communication with the RPi 3 will be available via USB and logic-level UART.
In the long term, USB is the preferred option, for a few reasons:
I usually wouldn’t place much emphasis on 2) and 3), but we’ll have motor-drive currents switching on and off, and in my opinion that translates to a rather noisy environment for electronics. With shielding, differential signaling, and CRC, USB is more likely to provide a robust communication interface compared to the UART’s single-ended, 3.3 V discrete-wire connections.
However, USB cannot compete with UART when it comes to firmware/software simplicity. I can handle some microcontroller USB development, but I know precisely nothing about implementing USB communication with an RPi, so I want to make sure that we have UART as a backup.
The robot chassis comes with two 12 V brushed DC motors. The RCB will control these using motor-drive ICs that allow us to easily implement forward/backward rotation, PWM speed control, and current limiting.
Image courtesy of RobotShop.
At one point we were hoping to find a suitable robot chassis that comes with stepper motors instead of brushed DC motors, but that search proved futile. Stepper motors allow for high-precision movements, but controlling them is more complicated, and this added complexity might partly explain the shortage of stepper-based chassis options. We didn’t want to give up on the possibility of a stepper-motor-based robot, though, so we decided to incorporate stepper-drive functionality into the RCB.
At this point, it seems more likely that we will use the stepper-drive circuitry for additional robot features rather than for moving the robot itself.
The battery gives us 12 V, but we need 5 V for the Raspberry Pi. It would also be handy to have 5 V for the RCB’s logic-level circuitry because we’re using an EFM8 microcontroller that has an on-chip 5 V–to–3.3 V linear regulator.
A linear regulator is not the best choice in this application; we want the efficiency of a switching regulator, and to simplify the design process on our end we will employ a µModule DC/DC converter from Linear Technology.
Linear Tech’s conception of why you might opt for a µModule, taken from the µModule product guide. I find this image highly amusing, and to be honest it’s a pretty good visual representation of how I feel about custom-designed switching regulators.
Proper Care of NiMH Batteries
The microcontroller’s analog-to-digital converter will be used to monitor the voltage coming from the battery. I think most designers would intuitively recognize the need to ensure that a battery-powered system is aware of the voltage being produced by its power source. But the importance of battery monitoring goes beyond this when we’re dealing with rechargeable batteries because excessive discharge can actually damage the battery.
The voltage across the battery decreases as it supplies current to the system; the following diagram, taken from Energizer’s NiMH Handbook and Application Manual, depicts the typical discharge profile for a NiMH cell.
Image courtesy of Energizer
If the microcontroller knows the battery voltage, it can use this curve to estimate the discharge percentage, and then it can take action to prevent excessive discharge. The Energizer document states the following: “To prevent the potential for irreversible harm to the battery . . . removal of the load from the battery prior to total discharge is highly recommended.”
Some Google searching indicates that a NiMH battery pack should not be discharged beyond 0.9 V per cell, though 1.0 V or 1.1 V might be safer. If we use 1.1 V per cell as the cutoff, we will need to shut down the robot when our ten-cell battery voltage reaches 11 V.
If you look back at the discharge profile, you can see that there is no need to push the cutoff to the absolute minimum because the voltage drops off so rapidly after about 1.1 V. Bottom line, I’d rather shut down the bot a little prematurely than risk damage to the battery.
We now have a bird’s-eye view of the updated system design for the C-BISCUIT demonstration robot. Stay tuned for future articles, which will explore the various parts of the bot in greater detail.