We just concluded the first ever Boston Mech Warfare Expo this weekend, held at Jaybridge Robotics in Cambridge. We had a lot of exciting mech fighting action, learned a lot, and even had a fair amount of exciting repairs! There are many hours of video I need to sort through, but in the meantime, here are some photos:
In our efforts to reduce weight and complexity for Savage Solder, over the Christmas holiday and first couple of months of 2015 we designed a new computer system based on the Odroid U3 instead of the Mini-ITX form factor PC we had used previously.
To make that happen, we put together a new power control board which was designed as a “shield” for the Odroid. It has the following functions:
- Li-polymer charge management: Previously, Savage Solder used a laptop battery extender, which was functional, but suitable capacities came only in large form factors. We gained a lot of flexibility by using a custom form factor li-poly battery pack, but this means that charge control and safety need to be addressed.
- DC/DC step up regulator: The Odroid (and other things), need 5V, so we have a step up regulator to bring the li-poly voltage up to what the Odroid can use.
- USB hub: The Odroid has 3 USB ports, (4 if you count the OTG port). We need more than that, and there aren’t many small form factor hubs which would fit into a tiny enclosure. This needed to be USB 2.0 high speed, to support webcams.
- Serial level shifter: To reduce the demand for USB ports, we pull out the exposed 1.8V serial port from the Odroid and level shift it up to 5V on a connector that also has 5V power. For Savage Solder, this is used for the GPS.
- Speaker power: The control board has a FET to switch the audio power directly from the li-poly pack.
- Soft shutdown management: The Odroid’s filesystem could be compromised if it gets powered off unexpectedly. We have a low power microcontroller which reads a discrete switch, informs the Odroid, and powers the system off after the Odroid has had a chance to shutdown cleanly.
- I2C Level shifter:The Odroid’s expansion port I2C is level shifted to the li-poly voltage level to communicate with the li-poly charger control IC and the shutdown management microcontroller.
These were the primary components that the rest of the board was designed around:
|BQ24192||TI||Li-poly charge management|
|LTC3124||Linear||5V step-up regulator|
|ATTiny841||Atmel||Soft shutdown control|
|TCA9517||TI||I2C level shifter|
|SN74LVC1T45||TI||Serial level shifter|
One of our goals with this design was to be pretty sure that the board itself would not be the cause of power problems, signal integrity problems, or really any sort of problems. Thus each USB port’s power is separately switched with a separate large decoupling capacitor and the USB signals have ESD protection. The board itself is 4 layer to give a proper ground plane under each of the USB traces and keep the impedance matched well. All the external connectors with power are separately decoupled and have PTC resettable fuses inline.
As mentioned, the board was designed as a “shield” for the Odroid. That meant that the mounting holes matched up with Odroid’s, and that the Odroid’s expansion port connects through with a stacking connector. Additionally, the USB connection was made by desoldering the Odroid’s vertical USB connector and using another stacking pin header to connect the two boards.
The board was manufactured on OSHpark’s 4 layer process, which worked out just fine for this project.
Assembly was challenging, especially for the QFN parts. The one that we built up so far I assembled by hand, using an iron and a hot air rework station with a lot of retries. If we make a subsequent revision, it will need to be with a toaster oven reflow system, or contracted out. Hand assembly time was probably around 16 hours.
While not strictly on the board itself, desoldering the vertical USB connector on the Odroid was very challenging as well. We ruined one Odroid in the process, and the other needed hand rework to replace some components which were lost in the desoldering process.
There are of course a number of errata in the version one board, but nothing that couldn’t be reworked in place.
Installation and test
So far, we haven’t identified any performance or reliability problems when testing on Savage Solder. The board ran through our spring testing and RoboGames Robogamellan run without being the cause of any known failures.
Savage Solder competed in the Robomagellan event in the newly restored and most impressive Robogames 2015 this past weekend. We had two successful runs out of 3, one with no bonus cones and one which touched the challenging 0.01 bonus cone. Both runs put us on the top of the leaderboard.
Here are links to videos I found or uploaded from other other competitors from last weekend:
As part of preparing Savage Solder for events this spring, I’ve been overhauling the computer and sensing platform to have higher reliability and lower weight. One of the changes was a new LCD and input interface.
I wrote up the previous LCD here before, which was the width of the car, pretty heavy, and not resistant to the elements. For this version, I wanted to use a smaller screen, and remove the possibility of moisture getting into the case, while still maintaining roughly the same USB interface.
PCB and Assembly
The display I ended up using was the 2.2″ TFT LCD from Adafruit. It is color, has sufficient pixels to display everything we wanted, and has a SPI interface. The other half of the solution is the input device, for which I decided to use an off the shelf MPR121 capacitive touch sensor controller, with a breakout board, also from Adafruit.
As before, these were glued together with a custom board holding an ATMega32U4 and a few other miscellaneous components. It is mezzanine mounted to the LCD and touch board, and has and external JST connector for USB. Also custom printed was the touch sensor itself. It is nothing more than a PCB with solder-masked copper where each of the touch sensitive areas should be, pulled out to a connector on the back.
The entire assembly was designed to be mounted to the lid of an off the shelf enclosure with a clear polycarbonate lid (which is where the rest of the electronics is going). The LCD and touch board each have four mounting holes, which are attached with a bolt, nut and lockwasher assembly. Sealing is accomplished with neoprene o-rings on the outer surface of the lid.
The MPR121 has a lot of options, many of which influence the performance of the device. The enclosure I am using is an off the shelf one from BUD (PN-1324-C amazon link). It has a polycarbonate lid approximately 1/8″ thick, which is kind of at the extreme of what you can get capacitive touch sensors to work through. I was inspired by Adafruit’s MPR121 library, but rewrote it to not require Arduino. I had to tweak a number of the MPR121 constants as well to work under the thick polycarbonate:
|MPR121 Register||Adafruit||Savage Solder|
|CONFIG1||0x10||0x20 (32uA charge current)|
|Thresholds||12, 6||4, 2|
For rendering text on the display, I also based my code on the Adafruit ILI9340 library. Since this LCD controller has to render text one pixel at a time, it was much slower than the HD44780 text-based controller we were using previously. To get remotely acceptable performance, I had to make the AVR keep a framebuffer around, and only re-draw characters which had actually changed.
To act as a forcing function in our development of Super Mega Microbot, we put together a Mech Warfare style qualification video, showing it driving around for more than 5 minutes shooting at some targets. Here it is!
legtool is the library and graphical application I’ve developed for inverse kinematics and gait generation to use with Super Mega Microbot. I’ve pushed a public version of it to github, in the hopes that it may be useful for other developers of legged robots.
I’ve also put together a short demonstration video, showing how to download, install, and use legtool with a gazebo simulated quadruped.
In lieu of actual documentation (or possibly to start generating the text of some), I’ve written some text describing what legtool does and how to to use it below.
legtool overview and installation
legtool is a python library and PySide based graphical application useful for pose generation, inverse kinematics, and gait generation for legged robots. It consists of a set of python libraries, and a graphical debugging application which uses those libraries to allow a developer to explore legged locomotion. It has primarily been tested on Ubuntu linux, but may be portable to other operating systems.
legtool is not yet packaged for installation, so all you need to do is clone the github repository and install the dependencies as documented in the README.
git clone https://github.com/jpieper/legtool.git
Legtool by default creates a configuration file in ~/.config, however, you can specify an alternate configuration on the command line using the -c option. If you have multiple robots, or a simulation and an actual robot, you will want to keep multiple configurations around.
The first tab which is active, the “servo” tab, contains controls to select the servos to control and configure them, along with controls to maintain a list of named poses, where each pose consists of a set of servo positions.
Here you can move servos individually to verify their operation, and compose poses. The only use for poses currently is in the later inverse kinematics tabs, so there is no need to define more than idle, minimum, and maximum.
Inverse kinematics tab
The second tab, the IK tab, lets you configure which servos are in which leg, what sign they have, and also the geometry of the legs. The lower right corner visualizes the achievable region of operation in 2D. You can select alternate projections, and change the centerpoint of the test using the IK Offset group. Clicking on the rendering will command that leg to that position.
The third, and currently final tab, contains controls to allow configuring the placement of all shoulder joints, marking the center of gravity, and configuring the gait engine. It provides several debugging facilities to allow visualizing the results of the gait engine.
The geometry configuration is in the upper left. The shoulder position can be set individually for each leg. The center of gravity and idle position are common to all legs. The gait configuration area in the lower left selects which gait to use, and then exposes a number of configuration options for that gait.
The remainder of the tab is devoted to interactive tools for debugging the gaits:
- Gait graph: The gait graph in the upper middle shows for the duration of a single cycle, when each of the legs is in the air.
- Geometry view: Visible in the upper right, this shows a 2D rendering of where the shoulders, legs, body, center of gravity, and support polygon are located.
- Graphical command view: Visible in the lower right, the graphical command view shows which commands are feasible given the current geometry and gait configuration. Any two command axes can be selected, after which the feasible region is shown in green, regions where the speed is limited are in yellow, and totally infeasible regions are in red.
- Playback: The playback scrubber allows you to slide back and forward through a gait cycle, visualizing the results in the geometry view or on the simulated or real robot.
- Textual command area: All of the 9 degrees of command freedom are settable here, in addition to the two available in the graphical command view.
Yesterday I pushed the release of the newest version of pygazebo to github, 3.0.0-2014.1. This version has two big changes, the first is that I’ve updated all the message bindings for gazebo 3.0.0, which gets two new messages, CameraCmd and SphericalCoordinates. The second, and larger change, is a switch from eventlet to trollius for asynchronous coroutine operation.
trollius is an implementation of the python3 asyncio/tulip library for python2. It is largely API compatible, with the biggest exception being that as a library, trollius can’t support the new python3 “yield from” syntax. pygazebo internally uses an API compatible subset.
The biggest reasons to switch were:
- Explicit control flow: In the asyncio model, the only ways of yielding control are by returning from a function, or “yield”ing from a coroutine. This means that you can reason locally about whether synchronization is appropriate, even when calling other methods.
- Integration with other event loops: While eventlet was nominally capable of being integrated with other event loops, in practice it wasn’t very easy and no one did it. The best integration strategy was usually to poll at a high frequency in another event loop and pump the eventlet loop. asyncio already has a draft event loop to interoperate with GLib (gbulb), and writing a basic one to interoperate with QT was not challenging.
- Unit test coverage: Eventlet (and other greenlet based systems) had a long-standing issue where most python unit test systems could not accurately track test coverage. trollius and asyncio seem to work just fine here.
AVC 2014 has come and gone! Savage Solder placed 2nd in the doping class this year, with two of three successful runs. The first run ended after about 5 feet when the replacement ESC seemed to overheat after being left on for too long before the starting line. The second run was flawless, hitting the hoop and the ramp. The third run was nearly perfect, only missing the hoop.
Congrats to all the other teams, there were a lot of successful and inventive entries this year!
I’ve found two good videos of the third run so far, the first from the official livestream at time 12:00
And the second from hearthdragon:
This video shows some gaits for our Mech Warfare entrant, tentatively named “Super Mega Microbot”. First there is a slow statically stable gait, then a faster two leg at a time gait.
Technically, it has been walking for a couple of weeks, but this is the first time with the actual aluminum machined chassis plates, so that it makes for a nice video. All the previous testing has been done with some polycarbonate plates that I cut out by hand. We haven’t mounted the onboard computer or turret yet, but that is coming soon. In their place is an extra lipo battery to make the center of gravity more reasonable. This gait was driven by a PC over the serial cable seen in the frame.