设置
快速交货
免运费
国际贸易术语
支付类型
市场产品
制造商零件编号 3099
CAMERA BD RASPBERRY PI 8MP
Adafruit Industries LLC
C-BISCUIT Robot System Architecture
2016-12-20 | By All About Circuits
License: See Original Project Raspberry Pi
Courtesy of All About Circuits
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.
Updated Architecture
At this point the primary components of the demo bot are the following:
- Lynxmotion Tri-Track robot chassis
- Raspberry Pi 3
- Raspberry Pi Camera
- SD Card (>=8 GB) (If you’re new to Raspberry Pi, an SD card preloaded with the Raspian OS is a nice option)
- 12 V, 2800 mAh NiMH battery pack
- Battery charger
- Robot Control Board, a custom-designed PCB
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:
- The Tri-Track robot chassis comes with 12 V motors. It’s preferable to operate a motor at its specified voltage, and this is not so easy with LiPo because LiPo-pack voltages come in increments of 3.7 V (one LiPo cell generates 3.7 V). So if you’re looking for 12 V, the closest you can get is a three-cell pack that provides 11.1 V.
- LiPo batteries are more finicky when it comes to charging, storage, and transportation, and they are generally considered more dangerous because they have a tendency to explode under seriously adverse conditions.
- NiMH batteries endure more charging cycles than LiPo. We might be doing a lot of charging and discharging as we pull this demo bot together, and I like the idea of a longer-lasting power source.
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:
- Communicate with the RPi 3
- Control the motors that move the robot chassis
- Convert 12 V from the battery to 5 V for the RPi 3 and for the low-voltage circuitry on the RCB
- Monitor the battery voltage
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:
- The RPi 3 has standard USB connectors, whereas the UART signals used for RCB communication are available only as header pins.
- Properly shielded USB cables are readily available.
- USB employs differential signaling and incorporates a cyclic redundancy check (CRC) for error detection.
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.
Motor Control
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.
Regulating Voltage
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.
Conclusion
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.
Have questions or comments? Continue the conversation on TechForum, DigiKey's online community and technical resource.
Visit TechForum
