Minimum time value iteration solution of the double integrator

I've spent the last week of spare time working of a value iteration problem for the underactuated robotics subject I've been working on. In particular this has involved finding the optimal policy of how to get the undamped double integrator to the origin in minimum time (github gist of code). A MATLAB / Octave solution is available on the OCW site, so I don't feel too bad publishing this here.

This has been something a bit different for me, considering how little vectorised code I've written in the past, but has already had a big impact on some things I'm doing for a number of projects. The performance benefit is substantial, but it makes code hard to read, write, debug and test.

Python simulation of the simple pendulum

Following on from the previous post, I've created some simulations of the simple pendulum without damping or control input. This work was designed more to be a test of my understanding of how to use the scipy integrator module, and to make sure the matplotlib plotting code worked correctly.

I'm pretty pleased with the results, and you can see a plot of the homoclinic orbits of pendulum starting in different initial states, and some videos of what that means, if you don't naturally think in phase space.

Python simulation of the Van der Pol Oscillator

One of the things I'm doing at the moment is watching an excellent series of MIT OCW lectures by Assoc. Prof. Russ Tedrake on underactuated robotics. I've learned a lot watching the videos, which pick up at a point where some parts of my doctoral studies finished.

Just to pick something small that is at least tangentially related to the related to the course, I've attached a python snippet of code for generating the Van der Pol Oscillator. This system is significant in that it exhibits limit cycles, which are an important tool for reasoning about walking robots

import numpy as np
import matplotlib.pyplot as plt
from scipy.integrate import odeint

mu = 0.2

def van_der_pol_oscillator_deriv(x, t):
    nx0 = x[1]
    nx1 = -mu * (x[0] ** 2.0 - 1.0) * x[1] - x[0]
    res = np.array([nx0, nx1])
    return res

ts = np.linspace(0.0, 50.0, 500)

xs = odeint(van_der_pol_oscillator_deriv, [0.2, 0.2], ts)
plt.plot(xs[:,0], xs[:,1])
xs = odeint(van_der_pol_oscillator_deriv, [-3.0, -3.0], ts)
plt.plot(xs[:,0], xs[:,1])
xs = odeint(van_der_pol_oscillator_deriv, [4.0, 4.0], ts)
plt.plot(xs[:,0], xs[:,1])
plt.gca().set_aspect('equal')
plt.savefig('vanderpol_oscillator.png')
plt.show() 

Which when simulated looks something like this:

Hard Real-Time Motion Planning for Autonomous Vehicles online now

It's been a while since I've checked, but Swinburne University have published a low quality copy of my PhD thesis - "Hard Real-Time motion Planning for Autonomous Vehicles" online at their research bank. If you don't want to download the whole thing, you can look at the summary here

During my candidature I had the honour of working with the team developing the Wayamba Unmanned Underwater Vehicle, a three meter long flat-fish form factor research vehicle.

Image Taken from http://www.defence.gov.au/news/navynews/editions/4821/topstories/story08.htm

PyCon - Day 5 (Sprints Day 1)

Today was the first time I've ever sprinted, and I can honestly say it wasn't at all what I expected. I was expecting frantic energy, and I mistakenly assumed that the project maintainers would turn up with a huge number of tickets that would get allocated to anyone who came. I also hoped (expected?) that there would be someone experienced in the project who would help me get started.

Instead it was a cross between a design meeting and a pretty regular work day, and while everyone was friendly and very helpful, they were also busy trying to get their own work done.

It's no-ones fault - I just wasn't anywhere near prepared enough to actually be useful helping on the project that I wanted to work on. In part, I guess that some of that is about trying to break into a community - there needs to be a degree of trust before you get commit rights to a major repository. So I'm happy to watch most of this one out, with the understanding that things will go better at future conferences.

Instead, I've had a good day working on a related topic to my project of interest, which I'm hoping may end up with nice enough results to put in for a PyCon AU talk.

We'll see how it goes.

PyCon - Day 5 (Conference Day 3)

I have to admit that the feeling of washed out has continued, and with the change of daylight saving, I almost missed breakfast and the keynote entirely.

Guido's address to PyCon started the morning officially, and he reiterated the key point that this was a time for consolidation and community building, and that we as python developers should already know the answers to any questions trolls may post on various forums. He also indicated that modifications to the core language in the future would need to be demonstrated more rigorously, either in alternative distributions, or through the use of import hooks.

The poster session / job fair was excellent, but in my opinion, the academic and mathematics posters far outshone anything else. I took lots of photos, and I'm happy to discuss them with anyone who is interested.

I literally dragged myself to three talks today, which isn't to say anything about the speakers, merely the grueling schedule of the conference:
- Writing GIMP plugins in Python
- Build A Python-Based Search Engine
- Parsing sentences with the OTHER natural language tool: LinkGrammar

All of which were interesting, but none of which seemed earth-shattering.

The conference finished with lightning talks, which really deserves a post of it's own, but suffice to say, the github links and urls mentioned will be enough to keep me busy for a few weeks when I get home.

The culmination of the conference was a raffle (what Australian's would call a give-away), with Frisbees tossed out into the audience to decide winners. I will state, I did catch a Frisbee - but gave it up to someone else with a tighter grip.

I'll admit in advance that this is reasonably subjective, but it is interesting to try to consider what the most important developers in the python community are interested in, over the past three days. So based (almost completely on the description of the talks in the conference program), the relative proportion of talks by field is something like:

The Python Language, Standard Library and Packaging - 25%
Web topics / Cloud / Networking - 24 %
Math / Science / Data Manipulation - 12 %
Testing / Debugging - 10 %
Electronics / Robotics - 7%
Other - 12 %

This result surprised me a little, because I expected to see a much higher proportion of the web/cloud/networking topics than what really seemed to be present.

At dinner time I found Richard Jones from the Melbourne Python Users Group who was about to go to dinner, and invited myself to go along. Richard ended up deciding that sleep prior to sprinting was more important than food (or more alcohol).

I ended up on a table at a Mexican restaurant with Ian Ozsvald, Mike Mueller (of Python Academy), Ricardo Kirkner and Jack Diederich, amongst others. This was an awesome experience, where I got to pick the brains of so many speakers from the conference.

A number of margaritas later, I've finally arrived back at the hotel, wondering exactly how I'm going to manage to be up in a condition for sprinting in the morning. Regardless, this has probably been the best, and most valuable, night of the whole PyCon.

PyCon - Day 4 (Conference Day 2)

The second conference day definitely had a different feel from the first day. I'm not sure whether it is being away from home, the time difference, or some very big days, but I'm feeling pretty tired.

The PyCon committee had asked the mornings keynote speaker David Beazley to speak on something "diabolical" - something that he has a reputation for after great talks at the past few python events on "programming the superboard" and "the challenges of the python GIL". I think he picked the perfect topic, talking about PyPy (the Python-in-Python) project, which has the potential to have an enormous impact on performance for all code and infrastructure written in Python.

Having attended the PyPy talk earlier in the week and having tried to go through some of the same very challenging process of getting PyPy to build within the last week, the talk struck a chord with me. PyPy is so exciting, yet seems to require an enormous amount of effort to get started to even add small features.

Straight after the keynote I raced over to the exhibitors hall, because I'd manage to finish the Google challenges last night, which meant I earned my pins, and a T-shirt with the slogan on the back "Python: Programming the way Guido Intended"

The talk schedule worked out a little differently today, in particular, I had the flexibility to go to talks that were just plain cool rather than related to work:

- The Journey to Give Every Scientist a Supercomputer
- Python for Makers
- Pragmatic Unicode, or How do I stop the pain?
- Python and HDF5 - Fast Storage for Large Data
- Militarizing Your Backyard with Python: Computer Vision and the Squirrel
Hordes
- Using fabric to standardize the development process

One of the big standouts for the day was the talk on Ned Batchelder's talk on Pragmatic Unicode, which provided a consistent approach to dealing with Unicode through your programs. It also seemed to be a far more pragmatic than the Joel Spolsky's essay on "The Absolute Minimum Every Programmer Should Know About Unicode".

I was impressed by the "Militarizing Your Backyard with Python: Computer Vision and the Squirrel Hordes" talk, both for using Python for everything from the highest to the lowest level, and also because the speaker managed to get very impressive machine learning results for squirrel classification from a minimal, and what I assumed would have been a very small and coarse set of features.

The other big thing that happened was that as a response to the fabric talk, one of the delegates came off the floor and gave a really succinct answer about what the roles of provisioning tools like chef and puppet, versus fabric. The answer seems to boil down to the fact that there is some cross-over, but fabric is best suited for remote management, and puppet/chef are best suited for keeping your machines in a consistent state.