In June 2013 I was lucky to speak at the fantastic SciPy2013 conference
(scientific computing with python). I spoke about a work flow and tools we have
developed at strawlab. The title of my talk
was Managing Complex Experiments, Automation, and
Analysis using Robot Operating System.
The video of that
talk is included below;
This post describes a tool I developed for
distributing ROS packages to scientific collaborators. That software is
For those of you not aware, ROS is a great framework
traditionally targeted for robotics but usable in other fields too. In particular
it has a relatively good performance and simple, strongly typed, inter-process-communication
framework and serialization format. This is simultaneously useful for creating
distributed realtime-ish systems with comprehensive logging of the system
state. Best of all, the python interface to ROS is very clean.
Unfortunately, being a framework, ROS is rather all-or-nothing (going as
far as to describe itself as a meta-operating system). The basic ROS
install is several gigabytes, and building it yourself can be rather
difficult. Furthermore, as I mentioned in my presentation, it is attractive
to use the built in ROS tool rosbag for recording timestamped data
to disk. Unfortunately, reading these files again needs ROS,
thus necessarily coupling experimental data to the software used
to collect it.
To remedy this I wrote ros-freeze,
a python tool to convert any ROS package into a pure-python package including
all of the dependencies. Collaborators can then install the python
package and immediately have access to all the same ROS packages and libraries
without having to build the whole ROS stack.
this is currently working on ROS Electric (an old release, at work
we have chosen to stick with Ubuntu 12.04LTS)
changes for other ROS distributions might be necessary, so please get in touch
this is successfully tested on ROS packages containing tens of thousands of lines of
code and dozens of ROS dependencies.
although recent ROS releases have improved the package management situation (by embracing
deb packaging, yay!) this tool provides an unprecedentedly easy way to distribute your
pure python ROS applications
A Pure Python ROS Distribution?
One side effect of this was the packaging of the pure python ROS core as an easily installable
python egg. This means that you can write, debug and test python ROS nodes without having to
install the whole ROS distribution.
One can even go as far as running rosmaster and the command line tools
(rosnode, rosparam, etc)!
In collaboration with GSOC student Alex Muñoz
and designer Allan Day, GNOME Tweak Tool has
seen many improvements this cycle, both 'under the hood', and most noticeably,
in the form of a modern GNOME3 UI
The difference is stark; compare the old and the new versions below;
In addition to the use of new widgets (Gtk.HeaderBar, Gtk.Application,
Gtk.Stack, Gtk.SearchBar) the organisation of tweaks into categories
has been updated. This should make many
settings easier to find, especially in conjunction with new translations for many
tweak names and descriptions.
Historically, the tweak tool UI was mostly auto-generated, resulting in a rather
uniform and boring look, and more importantly the inability to easily group tweaks
together to show causality (such as turning off desktop icons makes the options
to show specific types of icons on the desktop redundant). This architectural
limitation has now been fixed, and in addition, specialized UI elements have
been created for certain tweaks; startup applications, shell extensions,
desktop icons, the shell top bar, etc.
Other highlights of 3.10 include;
Allow updating GNOME Shell extensions from inside tweak tool
Startup application management
Offer to logout user when tweaks require the session restarted
GNOME style sidebar and search
Ability to disable middle-click paste (great for designers!)
Show text in tooltip when label is ellipsized, and make window maximizable and
Better tweak names and descriptions (manage our own translations
instead of getting all from gsettings)
Unfortunately, not all features I wanted to implement were completed. Things I will
be working on in 3.12 include;
Hidpi tweak (this will land in 3.10.1)
Better search interaction (focus stealing and search-results layout fixes)
Improved layout when the window is maximized
Resurrect the wacom panel (this was generously contributed at the start of the
cycle, but I had no time to port it to the new design, nor any way to test it)
Privileged helper for operations requiring root permissions (power management
options, installing system wide themes)
The main limitation of the current implementation is that is only supports
the PointXYZ point type. PCL is a heavily optimized and templated API,
and the best method for creating specializations correspoinding to the correct point type
in a dynamic language like Python is not clear.
Nevertheless, the binding is already capable of smoothing, filtering and
the fitting of geometries in arbitary 3D point cloud data.
The binding is written using Cython, and is one of the more complex C++
bindings I could find.
The current release has been tested with
although it should work with more recent releases.
At the lab in which I work (Andrew Straw, strawlab) we
study the visual flight behaviour of Drosophila using virtual reality. The
implementation of this will be explained in future posts and papers however for
this post I am going to describe how I used Gtk1 and
ROS to build an interface to control and monitor
running experiments (called the 'Operator Console').
A future post will address and release all the ROS+GObject2 glue that lets these
interfaces scale dynamically as nodes (dis)appear. This just shows the relevant
Gtk parts and has some comments on what I would like from Gtk to make these
sort of interfaces easier.
The screenshow shows the first tab of the 'Operator Console'3.
I use the secondary icon support of Gtk.Entry to show the contents contain
sensible data. Maybe validation support in Gtk would be useful here
The 'Description' entry is a Gtk.TextView, not a Gtk.Entry. It was necessary
to apply custom CSS to make it look reasonably similar. Sadly, it does not
support the full/same set of CSS properties as Gtk.Entry, so it was impossible
to show the same border radius and focus colors
bug. Perhaps a multi-line
Gtk.Entry would be better.
The bottom half of the window shows the utilisation of all computers. I tried
a few versions of this, and simple sensibly formatted monospaced text looked
much better than anything else I tried. Any suggestions?
This screenshot shows an example screen where we mix the control and monitoring
or many instances of the same ROS node.
The Gtk.Switch simultainously displays the status of the projector, and also
allows control of the node. The is a common use-case in the software, and
due to the asynchronous nature of the ROS messages, I need to distinguish these
from user-generated signals. I have wrappers such as the following
for many widgets4. Advice on how to distinguish this use-case would be
The "Standby (Computer1)" is for display only and mirrors the status of a ROS
topic. I would like some way visually to inicate that this widget is not actually
an editable Gtk.Entry. Currently the Gtk.Entry is set
editable = False, it looks to out of place with sensitive = False.
Perhaps I should add some custom CSS to color it slightly different.
Suggestions are appreciated.
I'm really happy with the status of the PyGObject bindings. We have a few quite
large applications built using them (and ROS) and I have no complaints about
performance5 or otherwise. The conventional wisdom was that PyGTK (and GTK) were
not suitable for threaded workloads but the threading model of ROS guarentees that
the 'operator-console' shown above manages upwards of 50 background threads asynchronously
updating the GUI state.
Actually PyGObject, argh why didn't we keep the name as pygtk? ↩
I'll blog about this later. For the curious,
rosgobject lives here. ↩
In real operation this GUI shows the state of many more
machines/nodes/computers. This screenshot is running on my laptop because
showing too much more might give away the game ;-). ↩
freeze_notify and thaw_notify would almost work, if the events
could be dropped and not queued. Also, not all widgets use notify::active,
GtkComboBox(Text) for example. A general way to do this would be preferred. ↩
Excluding plotting / graphing performace. But that is fodder for a later post. ↩
2011 has been an interesting year. Between the stupid earthquakes and the pressure of finishing my PhD, I have been silent because I have had nothing interesting to talk about (cf. twitter...).
But there is a light at the end, I'm on track to complete my thesis, 'Biologically Inspired Visual Control of Flying Robots', in December/January.
I'm excited to say that I have accepted a job at the Institute of Molecular pathology, in a research group studying the mechanisms of visual flight control in insects. Technology wise, it is a perfect fit; the experimental apparatus involves a multi-camera real-time flight tracking system and estimator for multiple targets in an augmented reality flight arena. It is open-source (ish), and python/numpy. Research wise, it allows me to investigate some of the assumptions and unknowns in the biomimetic control systems I implemented during my PhD. And it is in Vienna, 1st Feb, 2012!
This is a career change for me. In the last few years it became increasingly clear that I was morally uncomfortable with the use of UAVs as weapons (drones). Previously I had consoled myself with there existing an ethical and philosophical difference between 'the application of research' and 'the action of research'. When It came to looking for work, and considering who to work for, this difference was often eroded.
It has also been particularly frustrating being in New Zealand for the last 12 months and watching our flaccid national response to the three recent challenges here (world cup, earthquake, rena oil spill).
gnome-tweak-tool is coming along nicely. I have some things in bugzilla to address, but I am happy with the state and direction.
GNOME 3 has helped my productivity greatly, maximized windows, keyboard navigation and less distractions have been welcome changes.
I was recently asked to help a colleague access his image processing C-library from python; quite a common task. As those of you who are familiar with Python might realise, there are a whole bag of ways that this can be accomplished;
In this case the colleague only needed to access a single function from the library returning image data, and then hand this result onto OpenCV. One happy side effect of the new (> v2.1) python-opencv bindings is that they do no validation on CvImage.SetData, which means you can pass an arbitrary string/pointer. Because of this I advised him I thought using something like SWIG was overkill, and he could just write a wrapper to his library using ctypes, or a thin python extension directly.
Image data contains embedded NULLs, and I could not find a concise example of dealing with non null-terminated, non-string char * arrays via ctypes so I wrote one.
I just released PyGTK 2.24, which will almost certainly be the last major PyGTK release. The future of Python on the GNOME platform is PyGObject + GObject Introspection. From my experience over the last few months porting a number of my projects, the future is bright.
In a cruel twist of irony, the state of PyGTK on Windows and Mac has never been better. The credit for the windows work (and some great documentation improvements this cycle) must go to Dieter Verfaillie
I hope that the new stack will reach the same level of capability on other platforms as GTK+ 2.24, but in the large scheme of things the renewed development excitement surrounding GTK+ 3.0 and GNOME 3 is excellent consolation.
As a user I would like to thank those developers before me for creating PyGTK. It was the first 'pythonic' UI toolkit for linux, and a pleasure to use. As the recent maintainer of PyGTK I would especially like to thank those recent developers who helped me, in particular Dieter Verfaillie who really pushed PyGTK over the line regarding Windows support, into the great state it is now.
I'll leave you with some graphical statistics (generated using pepper) for the 12 year history of PyGTK. If planet strips the wordpress gallery then please click here.
update: To clarify a point raised in the comments, PyGTK will be maintained in the exact same was as the GTK+-2.0 series will be maintained. Bug fix releases will be made if necessary, but no new features will be added. If you want the new GTK+-3.0 features then you should use PyGObject + GObject Introspection.
The PyGTK code will not disappear from any servers, it will continue to be shipped in all distributions for the forseeable future, it will continue to work very well on windows, and many applications will continue to use it.
The PyGTK team is pleased to announce the return of the highly popular all-in-one installer for Windows.
The PyGTK All-in-one installer provides an alternative installation method for PyGTK users on Windows. It bundles PyGTK, PyGObject, PyCairo, PyGtkSourceView2, PyGooCanvas, PyRsvg, the gtk+-bundle and Glade in one handy installer.
Currently 32 bit Python 2.6 and 2.7 versions are supported on Windows XP and above.
Dieter Verfaillie deserves enormous thanks for this work. Firstly, he performed the tedious job of ensuring that all the component MSI installers were exactly correct, and secondly, the really difficult task of deconstructing these individual installers and reassembling their contents into a single cohesive executable.
This is a true all-in-one installer, it does not simply call out to launch the individual MSI files.
We are looking to collaborate with others who want to create gtk+ (and friends) all-in-one installers for Windows. We anticipate the tools to generate these installers will move to GNOME in future - perhaps in a common repository. Suggestions and feedback welcome.