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! 😀