I have found it difficult completing this blog post this week, let alone doing any programming, as I have just discovered the series "Breaking Bad" on Netflix. Now, what I like about this show is how intelligently the show has been thought out, typical of what any engineering design project should be really. The plot, the cast, the characters have not just been cobbled together, but have been interwoven into an intricate and delicate interlinking pattern of intrigue and suspense that has led to the show's success. "Who would have imagined you breaking bad?"
The design of our 17 DOF robot, like system design in general, should not be anything different. It should consist of well thought out building blocks, which will include mechanical design, digital hardware design and software programming, amongst many other scientific disciplines including physics and electrical engineering. Also, if we do not want our robot to harm anybody we may need to include the discipline of philosophy and maybe incorporate Asimov's laws of robotics too! For now, in this blog post, we will concentrate on the design of a printed circuit board to mainly control the robot's servos.
So, the aim of this blog post is to initiate the formal design process of a Multi-Channel Servo Controller Printed Circuit Board (PCB), which is compatible with the 2 x 20 way General Purpose Input/Output (GPIO) header found on the J1 connector of the BeMicro CV Evaluation Kit and on both connectors of the DE0-Nano FPGA Development Kit. Although the primary purpose of this board is to control servos, but because the 2 x 20 way header has more I/O pins than we actually need for this project, we will connect what would have been any unused I/O pins to sensors. We will also use the unused GPIOs to provide real-time debugging possibilities through the use of a UART-to-USB converter.
For the design of this board we are interested in controlling the robot's lower limbs, described in previous parts of the series, that is we wish to control at least 10 servo motors. In the future if we add an active toe joint to each limb we will be required to control 12 servos to fully manipulate the lower limbs. We also wish to experimentally place a 9 or 10 Degrees-of-Freedom (DOF) collection of MEMS sensors at the inertial frame of the robot, described previously.
We could create the perfect recipe for disaster by immediately booting KiCad, the EDA tool we have recently been using on Mac OS X and begin to layout out a circuit and make up the design as we go along. Alternatively, we could, like in Breaking Bad, devise a well conceived and well thought out design, that is suitable for a "small team" approach to system design, without incorporating the more complicated challenges of a full blown multi-discipline one.
An approach that is suitable for this project would be to break the design of the multi-channel servo controller board into stages. We begin by defining the project or creating a Project Design Definition. Then we could flesh out the design on the back-of-an-envelope. Afterwards, we could analyse this preliminary back-of-an-envelope design to select suitable components, in a process known as Component Selection and Analysis. If after this stage we are still happy we could propose a system design in the form of Requirement Specifications.
Once we approve our specification we could then begin the schematic entry process followed by the PCB layout. In the previous part of the series which discussed the 17 DOF Project Management Plan we didn't mention the System Design component of the management plan, shown in the Figure above. The link between the project, the system design and the design definition along with the requirement specifications will be added to the next iteration of the project management plan.
Finally, after each stage has been revisited through a series of checklists to ensure that we have not missed anything we could send the PCB off for Fabrication. On receiving the fabricated PCB we will assemble it here, in-house. This design schema, which can be seen diagrammatically in the Figure above is demonstrated step-by-step in this and the next set of blog posts on the design of the Multi-channel servo control board.
In our mind it is quite clear what we want the Multi-Channel Servo Motor Controller Board to do. However, it does not hurt to write it down in words, so lets do just that. (1) We require a multi-channel servo control board to operate the servos on our 17 DOF Robotics Project. (2) Ideally, the PCB that is developed should be mounted at the inertial reference frame of the robot.
(3) Primarily, the controller board should be used to control the lower limbs or 12 servo motors, when an active toe joint on each limb is considered. (4) Also, a secondary aim of the board is to control all of the 17 servo motors of the robotics kit, when the active toe joints are not considered.
(5) The board should implement an interface that is compatible with the 36 GPIOs of the 2 x 20 way header of the BeMiro CV Evaluation Kit or the two 2 x 20 way headers of the DE0-Nano Development kit. (6) Any unused I/O pins should be used to connect to MEMs sensors including an accelerometer, gyrometer and magnetomer otherwise known as a compass.
(7) As with all our designs we require an USB-to-UART converter to provide design feedback to application software. The converter should consists of a FTDI chip that uses the ftd2xx library.(8) Finally, the size of the PCB is yet TBD, but it will typically be a two layer board with a purple or mustard coloured silk screen.
This design definition could be fleshed out in a rough and ready "back-of-an-envelope", as demonstrated in the next section, of this post.
Our back-of-an-envelope design, based on the design definition discussed previously, can be seen, in the Figure, below. The primary aim of this board is to control servos. Hence, item (1) in the Figure shows two banks of 6 x 3 way headers to control the robot's lower and upper limbs. Since the primary servos we are considering are Tower Pro's MG996R the pin out of each three way header will be 1 - plus, 2 - minus and 3 - control.
Each control pin is connected to a GPIO pin through a voltage level translator. This is depicted by item (3), in the Figure, below. A voltage level translator is required because the FPGA banks (of the BeMicro CV and DE0-Nano) connected to the GPIO's can only support 2.5V or 3.3V . However, the operating voltage of the MG996R can be set to between 4.8V and 7.2V, hence the voltage level translators allow the GPIOs to drive the servos at the higher operating voltages, which operate the servos more quickly.
Similarly, item (2) is represented by two banks of 4 x 3 way headers, whose function is also to control servos. Therefore, in total the multi-channel servo control board could be used to drive a total of 20 servo motors in parallel, which is its characterising feature. Since the board is connected to a FPGA development kit, it allows each servo motor to be driven concurrently.
The servo connections require a total of 20 GPIO pins. However, the BeMicro CV and the DE0-Nano's 2 x 20 way header provides 36 GPIO pins. The remaining GPIO's are used to provide experimental functionality, such as connecting to a 10 degrees-of-freedom MEMS sensor, item (4) and a USB to UART converter, item (5).
The DE0-Nano and the BeMicro CV can be powered by their USB ports. However, the USB Specification 1.1 only guarantees that the port can supply 500mA of current, which barely drive our MEMs sensors, USB-to-UART converter and LEDs let alone drive up to 20 servo motors. Therefore for practical reasons, we should add an external power supply connector to accommodate the servos operating voltage range and current consumption.
The final item, (7) in our preliminary design is the 2 x 20 way header, which apart from providing the 36 GPIOs, discussed previously, also provides access to a 3.3V power rail and a 5.0V one. However, it should be noted that if either device is powered by its USB port the voltage rails are unlikely to provide enough current to drive the maximum of 20 servos.
A confident start and we are definitely heading in the right direction, even if by doing things this way it means that the design of our board is taking longer than we would like it to. The next thing to do is to analyse our "back-of-the-envelope" design, which is exactly what we do in the next series of the blog on Robotics using FPGAs.