Weeks 6-7: Creating the Movement Interface

I spent the past two weeks coding up the movement interface, a model plugin that will allow a user to specify a series of points and move the model between those points in Gazebo.

Figuring out how to do this was a little tricker than I anticipated, since it involves using PoseAnimation, a library that isn’t well-documented, apart from a tutorial that just points to some short example code.

Pose Animation

To animate a model in Gazebo, you need to create an animation object and populate it with a set of keyFrames. Each frame specifies translation and rotation of the model relative to the last frame. To begin, the animation gets a an initial frame with a translation of zero (meaning the model’s initial position). For the model movement plugin, the rest of the frames are generated by calculating the coordinate translation from the model’s initial position to goal position, then creating a frame for each second of the animation, dividing the translation amount  by the number of frames and assigning that translation value to each frame, thus creating a constant velocity. The animation length is somewhat arbitrary, but for now is based on the euclidean distance from start to end point, one second per unit. [Note: no rotation in the animation for now!]

To animate movement between a sequence of points, this frame creation process is repeated for each consecutive pair of points, A->B, B->C, etc. Unfortunately, since there can only be one animation per model (as far as I can tell), stringing together these subsets of frames is a little ugly, and involves passing around current translation values. I’ll see if I can clean-up the code a little in the coming weeks.

Reading Parameters

This movement plugin has two intended usages, each with a different method of getting the required parameters.

One use case is as a standalone plugin, for gazebo users to do it as they will. For this use case, Jose and I decided that the easiest way to pass in parameters is via the sdf file. Under the <plugin> tag, users need to set <path>, a string of positions, and <n_points>, the number of points in the path. Using the sdf pointer passed to the  load() function, these parameters can be read within the plugin.

The other use case is, of course, as a part of the path planner plugin — once the planner algorithm generates a valid path, the path planner plugin needs to be able to call the movement interface to actually move the model along the path. For the planner plugin to communicate with the movement interface, we use the gazebo transport system, which uses Google Protocol Buffers to transmit messages between processes by subscribing and publishing to known channels. To read parameters this way, the movement plugin creates a transport node and subscribes to the “~/pose_animation” channel. Upon receiving a message, a callback function is triggered, which parses the messages into the series of poses that specify the path.

Status Report

The movement interface is pretty much functional (minus a bug with a test path publisher I that made). There’s definitely some clean-up that I could do, but in the interest of having a complete path planner plugin, I’m moving on for now. Since the collision map generator is basically done, the only major parts left are the planner algorithm, and the overall plugin which will actually stitch all these pieces together.

Weeks 4-5: Breaking it Down

Over the past two weeks, I finally got into actually coding for the project. To be honest, despite our thorough design efforts, my inexperience with both big projects and working remotely left me having trouble getting started. After spinning my wheels for about a week, my mentor and I eventually figured out how make the problem more approachable: by dividing it into smaller pieces and posting them as individual issues on bitbucket.

This may seem like a no-brainer — after all, programming is all about dividing complex problems into smaller conceptual chunks. However, having these separate issues on bitbucket gave me a way to aggregate information/research on each of my problems, and ask Jose questions quickly. Having this forum made it easier not to simply hit a roadblock, get stuck, and procrastinate.

Now, here’s what I’ve actually been working on:

The Collision Map Generator

As noted in the design doc, one of the key components of using a path-planner is creating a collision map, a process which takes world information and transforms it into a map of where the world’s obstacles are. There are many ways to do this, but to start, Jose and I decided to work off a Gazebo tutorial explaining how to create a collision map using a ray-tracing technique. Essentially, this method shoots a ray in the z-direction at some valid (x, y) coordinate, and detects whether that ray intersects with any obstacles. If it does, that point is marked as occupied. If it doesn’t then the point is free. By doing this at every (x,y) coordinate, this technique can build a 2D map of the free and occupied space. The method isn’t perfect (consider a cube floating high above a model’s head, or terrain), but it’s a good starting space.

Just getting the tutorial code to work was a little more difficult than I anticipated, mostly due to cmake issues and problems that I suspect are peculiar to my system. After tinkering with the cmake file, I managed to get everything working (including setting up the custom message type, and eventually getting the correct output), but mysteriously, after making some innocuous changes to output format, I started to get connection errors, in which my request publisher would just hang. I’m still looking into this.

The Movement Interface

Jose pointed out another helpful tutorial on the basics of animation. Basically, this code demonstrates how to animate an object using pose. I’ve been experimenting with animation and getting a feel for things. Hopefully, I’ll soon have some working code for a basic movement plugin that can move a model from point to point.

Weeks 2-3: Design

These weeks were spent writing a design document for our project and continuing to get familiar with Gazebo.

Filling out the Gazebo design doc template was actually a great structured way to get introduced to the project and make sure that I understand all the moving parts. A lot of my learning process over the past few weeks went as follows

  1. Try to write a section of the design document
  2. Realize that I am confused or need clarification
  3. Read documentation, with limited success
  4. Ask for help

This process seemed to work out pretty well for me, and after some back-and-forth edits with José, we were able to submit a fairly complete design doc draft to Gazebo Design, where we’ll hopefully get some helpful critiques before moving forward.

Some Design Considerations

José and I quickly realized that this project had the potential to be as simple or complex as we could manage. There a plenty of features that would be nice to implement, but might be difficult to shoot for right off the bat. So to reiterate quickly, our baseline goal for this project is to create

A model plugin which can move the model to a target position given the current world information.

From there, there are still a lot of questions. For example, are we going to handle planning in high dimensional space? Given the many existing path planning libraries and algorithms available, how to choose? How will the models be moved?

We’ve decided to design the plugin to work with a number of different path planner interfaces and movement interfaces, with the goal of allowing users to customize path planning and model movement options. The architecture looks something like this. The plugin itself will handle the process of translating world information into a collision map, passing this information to the planner, collecting the results and handing them off to a movement interface, which will be responsible for communicating movement messages to the server. See the design doc for more details.

So to start off, we’re going to concentrate on getting down the most basic functionality: calculating a collision map, an interface to a simple path planner, and a movement interface which will simply push a model from point to point with reasonable granularity. As things come together, we’ll work on supporting an external path planner, and other, fancier things.

Coming soon: actual code! 😀

Weeks 0-1: Getting Started

Build Issues

Confession: I was nearly unable to make the single contribution to the Gazebo repository required for the OPW application. Why? Through no fault of the Gazebo team, installing software is just hard.

Most of the time leading up to my internship and my first week was spent trying to get Gazebo built on my Yosemite machine. I had a lot of trouble with this because I don’t have much experience installing software, and had no idea how to debug when things went wrong.

After being stuck for quite a while, help came via the discussion on the issue I opened. Working with contributors Steven Peters and James Townsend, we discovered that there were a couple of issues in play. First, the protobuf dependency needed to be built with Python support, which the Gazebo Homebrew formula did not do. This was easily resolved by re-installing protobuf manually using the “–with-python” flag.

The next issue was a little more insidious. Upon cmake-ing, I received a build error claiming that I had the wrong version of freeimage, despite definitely having a clean install of the latest version. James, another Yosemite user, was able to recreate my problem and resolve it by modifying the FindFreeImage.cmake file. However, once I tried those modifications, I found that the freeimage error persisted. James and I were mystified, since we appeared to have virtually identical systems. I even tried cloning his repo directly, to no avail.

It eventually became clear that the problem still lay somewhere with FindFreeImage.cmake, since swapping it out with another implementation solved my build problems immediately. I am finally able to cmake, make and install properly, although during compilation, my system generates several thousand BOOST warning, and curiously enough, pops up print dialogs intermittently. So there’s still some work to do.

I’m extremely glad I now have a working build, but I can’t help but think that difficult installation processes like what I just experienced may be significant barriers to entry for FOSS projects. It’s very frustrating to be excited to contribute to a project, only to be blocked by what seems like peripheral problems. Lucky for me, the Gazebo community was supportive and responsive to the issues I encountered. I just hope my struggles can help smooth the build process for new users in the future.

Design 

With a (finally) working build of Gazebo in hand, I spent the remainder of my first week continuing to get familiar with C++, a new language for me, and my project specifications.

Jose and I had a video conference to discuss the project, and we agreed that it was important to have a clear idea about what we were going to do before diving into implementation. Since Gazebo requires a design document for major contributions, we decided that writing one would be a good way to start. Once I have a draft completed, Jose and I will be able to tweak it together until the proposed architecture seems right, and I have a much better idea of what I’m doing. I think taking our time to lay out the details clearly will really pay off in the long run.

DONE: Training, Gazebo installation

TODO: Design document, getting to know plugins

Hello World

Hi! I’m starting this blog to document my experiences as an OPW intern.

What’s OPW? The Outreach Program for Women is a part of The GNOME Foundation‘s Free & Open Source Software Outreach program. Its mission is engage women (cis and trans), trans men, and genderqueer people in open source software. OPW offers internships with various open source projects in order to introduce new people to the FOSS community.

So for 10 weeks, December 9th – March 9th, I’ll be working with the Open Source Robotics Foundation, under the guidance of my awesome mentor Jose Luis Rivero. My project is to implement a path planning algorithm for Gazebo, a multi-robot simulation program.

I am beyond excited to have been accepted into the program, and to be working with OSRF. I’ve always wanted to get involved with FOSS, but have never been sure how to start. My internship hasn’t even begun, and already I’ve received a warm welcome from the opw team, the osrf team, and my mentor. I hope to do them justice by learning a lot, and making some worthwhile contributions. 🙂