For many years now on and off I’ve played in the programming contest associated with the International Conference on Function Programming. Each time it has been fun, exhilarating, and definitely humbling! www.icfpcontest.org
This year, the competition runs from Friday June 21st through Monday June 24th. Once again we’ll be competing as “Side Effects May Include…”. Look for us on the leaderboard and cheer on!
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.
The new release is on github and pypi, so a newer pygazebo is only a “pip install pygazebo” away.