The team’s focus throughout these past seven weeks was the abdomen. As has been mentioned in previous posts, the size and mass of the abdomen drives the parameters of the rest of the project, so going after this component first will hopefully make the remainder of the project easier. To summarize the following (long) post, C Term was spent primarily understanding selected technologies, and outlining their use-case frameworks in regard to this project.
Monolithic PCB Design
One of the most difficult design decisions made through this term was that we decided against going with a monolithic PCB for the abdomen. Our team is lucky to have generated interest by multiple sponsors, but with this comes a lot of ambiguity. For example, up until the last few weeks of the term, it was unclear what kind of batteries would go in the robot. Being the largest single component inside of the abdomen, its dimensions drove the design of the abdomen for a long period of time. PCB design begun under the assumption that a given type of battery would be used, but it became clear that that battery wouldn’t be suitable in the long run. As a team, we realized that the cycle time on designing and manufacturing a large PCB to fit the array of sensors and other components inside the robot was too time consuming and expensive to justify re-spinning boards with every design iteration. The design philosophy moving forward with electronics is to remain as flexible as possible to accommodate for changes in abdomen design. This will translate to using prebuilt modules scattered all over the inside of the robot rather than one large PCB holding all of the components.
Implementing Bi-Directional RS485 Communication
Early on in the project, we chose to implement a distributed computing network inside of the robot. Complex systems like automobiles do this as a way to (among other things) free up the main CPU to do complicated tasks. Additionally, it minimizes the amount of wiring that has to be passed through the complicated structure of the robot. Instead of having a dozen separate wires going from the grippers to the abdomen, we will only need to use four: Power, Ground, Data A and Data B.
To implement the data link layer of this network, we selected RS485. All of the components we selected for processing on the robot (Beaglebone Black (BBB) for the main computer and Atmega328p for the various modules) had native RS232 support, so getting them talking on a common bus was only a transceiver away.
The network inside of CHAMP is going to looks something like this:
With the BBB taking the role of the master over the other modules.
Writing library wrappers
CHAMP is going to use a variety of sensors in order to make ascending the tree as simple as possible for the operator, and as safe as possible for the robot. Many of these sensors use different communication protocols and output different kinds of data by default. C Term marked the development of a series of library wrappers to make using the sensors easier. To illustrate why this will be useful, the following two code snippets accomplish the same task, acquire the barometric pressure from the BMP180 sensor package:
*Syntax Highlighting Plugin*
These libraries isolate the functionality for the sensor that is useful for the CHAMP project and use a common configuration and language to make it easier for the programmers using them. So far, library wrappers have been written for the BMP180 and the LSM9DS1.
Picking a GUI Framework
QT is a cross platform, multi-language UI framework. We have selected this framework largely because of the large community of developers behind it (vocal on places like stackoverflow) and because it has an implementation in Python.