Brian Goldfain Food, drink, robotics



Half of the summer is gone with little research to show. What I do have is a test track for the robot, a second generation robot under development, and full autonomy tests on the horizon for the current platform. At the end of every week I look at my progress and ask one question: what should I work on next week? What follows is how I try to balance and make sense of the daily logistics requirements, ongoing infrastructure development, and the need for research progress on my current robotics project. How to answer this question is more important than ever to me because I start a new program in the fall.

As a PhD student, my job is to solve important unsolved problems in my field to increase human knowledge by some measurable amount. I think these illustrations put it into perspective.

Concerning my weekly work, I try to  maximize the likelihood that my robot will do something no other robot has done before (drive itself very fast). From my experience, the single largest factor determining success for robotics projects is to start with solid hardware and software infrastructure. This includes properly set up test space, a reliable platform, and core software to abstract out hardware interaction, data routing, and visualization. I will admit that my perspective is skewed toward software. As mentioned in an earlier post, we are building our system using ROS, which a great example of how core technologies enable successful project development. Just take a look at all the awesome projects people are listing on the ROS website.

I estimate that upwards of 80% of the time on my current project is dedicated to infrastructure development and testing. We could have used a more balanced time allocation approach and pushed early on for a fully autonomous demo, but it would have been a shell. Further, that would slow the overall progress of the project beyond that demo. Corners cut in the drive to the specific goal leaves important components in shambles and inoperable under all but ideal conditions requiring constant tuning.

I don't believe this is how successful long-term robotics projects should progress, and I keep that in mind every week when I plan. I believe that taking the time to develop bulletproof infrastructure in the beginning leads to awesome, repeatable demos later. As the saying goes, there is no shortcut to success.

Filed under: Robotics No Comments

Using QT in a ROS Catkin Package

This post is a brief account of how to compile a QT GUI as part of a ROS catkin package.

I spent the past week migrating a ROS project to the latest release, ROS Groovy. A major change with this release is the deprecation of the build system rosbuild in favor of a new build system, catkin. Catkin is a light-weight wrapper for CMake. Overall, the migration went smoothly, but it took significantly longer than anticipated (which I probably should have anticipated). One sticking point was compiling our Operator Control Station (OCS) GUI, designed in QT4. The problems were related to the removal of QT-specific rosbuild macros for the CMakeLists.txt and the use of out of source builds by catkin.

The Setup

I used qt_ros to generate a QT form, an accompanying QMainWindow derived class, and a ROS interface class as the basis for the OCS. The original CMakeLists.txt was based on rosbuild and modifications for the transition to catkin. I relied on a variety of resources for the migration, since none of them seemed to have all the information I needed: catkin's CMakeLists.txt overview, using CMake to build QT, rosbuild to catkin migration guide, and this post about using CMake with QT.

The Skinny

The OCS took significantly more work to catkinize than the rest of the nodes. The migration guide specifies how to transition many rosbuild macros to catkin, but the qt-specific ones are absent, specifically:

rosbuild_prepare_qt4(QtCore QtGui)

Using information from the first three of the above sources, I found a replacement to include the QT components I need:

find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui)

The next problem involved catkin's transition to out of source builds. A QT .ui file must be turned into an associated header file to be included in a project. All of the files built during a catkin build are placed in the build/ directory of the catkin workspace, not CMake's current working directory. For someone trying to include a ui header file from an in source location, the standard include will fail because the ui's header file ends up in buid/.

Once I figured this out, I found the last source, and the addition to the CMakeLists.txt was simple:


Now everything compiles and installs properly. The new CMakeLists are closer to pure CMake.


Below is the CMakeLists.txt I use to compile the OCS. Not included are some catkin and project dependencies passed in from parent directories. I want to offer this as a basic outline to compile and install a QT GUI using catkin and ROS Groovy because I was not able to find it anywhere else.

cmake_minimum_required(VERSION 2.8.3)
find_package(catkin REQUIRED COMPONENTS roscpp image_transport)
find_package(Qt4 REQUIRED COMPONENTS QtCore QtGui)




add_executable(ocs ${QT_SOURCES} ${QT_RESOURCES_CPP} ${QT_FORMS_HPP} ${QT_MOC_HPP})
target_link_libraries(ocs ${QT_LIBRARIES} ${ROS_LIBRARIES} ${catkin_LIBRARIES})

install(TARGETS ocs

First brew of the year

The Brew

I bottled the first brew this season before I left for winter break. When I returned to Atlanta, it was refrigerated and ready to drink. It started as a Mr. Beer Oktoberfest, but I decided to spice it up a little because the base brews tend to lack flavor. To keep with the season, I added 2 tbsp of ground cinnamon and tbsp ground nutmeg to the keg just before adding yeast. In hind sight, I should have used while cinnamon sticks and partly ground nutmeg in a muslin sack and removed them before bottling.

Either way, the mixture fermented for about 4 weeks. I chose to let it ferment that long because the average temperature was around 60 deg F. During the bottling process, I tasted the beer, and immediately regretted adding the spices. There was a strange bitter aftertaste that was definitely not hops, and similar to the dry bitterness of a black tea steeped way too long. Not a good bitter. There was no turning back, so I bottled and hoped that an extended carbonation and refrigeration stage would mellow the off flavors.

First Taste

Cracking open the first bottle, I was pleasantly surprised by the aroma. Both the cinnamon and nutmeg were easily distinguishable but balanced, and let the malty, caramel aromas come through. After just the first sip, I knew this was my best brew so far. The spices blended perfectly with the rest of the beer and provided a nice finishing note that my earlier beers lacked. The more satisfying aftertaste may also come from the fact that this is my first batch of darker beer with a more malty profile.

Overall, the extra time put into the long fermentation and refrigeration steps paid off, or judging the taste at bottling is not an accurate measure of the product.

More Bottles

For Christmas I received a second set of bottles and a hydrometer kit. This should up my production, and hope to have a new brew every month, as long as the weather stays cool enough. Instead of eyeballing the fermentation process, I can watch fermentation progress and bottle at the ideal time. This has been one of my biggest obstacles so far in brewing consistently because an extra week or two for every fermentation adds up quickly. The next batch, a wheat beer, is already in the fermenter, and should move to the carbonation within the next two weeks, depending on the hydrometer readings.