Category Archives: Uncategorized

Update 11/6/13

We’ve made a bit of headway in the last couple of weeks. Josh has begun CADing a mechanical design for the frame of the robot. We received a couple of important product donations. We’ve also decided to develop a backup microcontroller system to the NI myRIO system using Stellarisware launchpads from TI.

Our goals for the design of the robot’s frame are that it be modular and allow for easy access and removal of components. Here is Josh’s current design, still in progress:

InitialDesign_Front InitialDesign_Isometric InitialDesign_Right InitialDesign_Top


We’ve received two major product donations in the last couple of weeks. The first is a SICK LiDAR unit from AutonomouStuff:


According to the manual, it should provide range sensing information on a plane with 100 degrees field of view. Although we’ve been able to power it, we’ve been having some trouble communicating with it because it isn’t responding to serial commands. We’re currently debugging the problem with AutonomouStuff.

The second donation was a smacking new GNSS unit from Trimble, the BD982:


Jimmy and I were recently able to use the unit’s Ethernet interface to obtain fairly accurate GPS coordinates from holding up the antennas in the ENS parking lot. We’re currently planning to use the Ethernet interface to programmatically receive coordinates as well.

Last meeting, we decided to begin to build a back-up microcontroller system using StellarisWare launchpads. Kevin Gilbert has taken on the job of duplicating last year’s Cypress PSoC interface on the launchpad boards, building on top of the Rasware library we wrote this summer for the boards, which uses our custom power-regulating boosterpack.


Software Design

In the last month or so, we’ve been ironing out our initial software design. Here are our goals  and requirements for the software system:

  • Platform: ROS Groovy on Ubuntu Linux. ROS provides a large amount of useful packages, drivers, and community support. ROS is only fully supported on Ubuntu Linux.
  • Executive pattern: an overseeing executive program should decide high-level actions and delegates subproblems to separate programs. This way, it is easier to separate decision making code from navigation and sensor processing.
  • Planning: some degree of mapping and planning needs to be used instead of an exclusively reactive approach to navigation. By planning a path, the robot won’t get stuck or make incorrect decisions to satisfy short-term conditions.
  • Support for simulation & recorded data: to make testing easier, all data processing, algorithms, and decision making should be able to run in a simulated environment or run on previously recorded data without having to be modified.
  • Driver abstraction & modularity: data streams from redundant sensors for localization and environment modeling should be easily added and removed with minimal system changes. We may add or remove sensors several times, but this process should be simple and the rest of the system shouldn’t have to be extensively updated everytime it happens.
  • Design clarity: the spec of individual programs in the system should be clear enough that developers can know what to code from reading the spec, and testers should be able to test those programs from reading the spec.

With those goals in mind, we’ve come up with this diagram describing the interaction between ROS nodes (programs), topics (data pipes), and services (remote procedural calls). The diagram is described in more depth on this document, which is still being completed.

Now that the design is more or less finalized, we are ready to begin software development using bagged data from last year and simulation for testing.

Update 10/9/13

Last meeting we discussed progress in each system design. A major highlight was an announcement Rachel made that NI is willing to donate to us at least one myRIO (potentially more) to replace DoloRAS’s PSoC. See the meeting notes here, courtesy of Kevin Gilbert. This coming Sunday (10/13/13) we will continue to talk about system designs. I think our goal should be to have a rough spec of each system (software, microcontroller/embedded, power, and mechanical) within the next couple of weeks.

In other news, Frank, Sagar, and I put together a draft of a document entitled “Not-so-fond Reflections on IGVC 2013” which lists several problems we had with our entry in IGVC this past year.

Excerpt from section 2.b:

Another issue with the sonars was the way they were arranged. By doing math, we figured that spreading 12 sonars that each have 15 degree field of view over a half circle would give us full 180 degree coverage. However, this was not the case due to the way we arranged the sonars around the half circle…

I expect these problems to motivate our entry this coming year. If you have any questions or if there’s a section on the document that isn’t clear, feel free to add a Google doc comment.

Side note: the reflections were written assuming the audience has a bit of knowledge about our entry, which can be got from our 2013 design doc.

Thoughts 7/3/2013

Nothing has happened in the last couple of weeks, unless you count Sagar and my attempts to document packages from our 2013 GitHub repository. In the same vein, Sagar uploaded all the bags we got during the competition to Dropbox.

We’ve also made a couple of Google docs to gauge and gather interest within RAS for IGVC–both of which were posted in the RAS Facebook group a couple of days ago. So far only Chris Davis, Rachel, Sagar, and Joshua James have put down their interests.

I’ve been thinking about a hypothetical redesign of our current software system. This would only be a reorganization of data flow, packages, and nodes–not any changes to implementation. See the diagram below. Here are the main ideas:

1. The vision nodes should be compressed into one node. If needed, stages in the vision pipeline–along with the threshold/Hough line UI tweaker–would be displayed with OpenCV windows.

2. The Extended Kalman Filter (EKF) should be a service that does a prediction instead of publishing predictions to a topic at 10 Hz.

3. Unnecessary nodes should be removed. Having an entire node dedicated to choosing whether or not to take the VN 200’s INS or GPS topic is unnecessary, and we never used the INS data anyway. The vel_cmd_filter node is also unnecessary–it does no filtering.

4. Scans should be matched with EKF state data to be sure that actions are being made with data all from the same moment in time.

5. Not shown on the diagram: GPS x/y waypoints, red/white thresholds, and Hough line parameters should be specified as ROS parameters in launch files rather than needing to be read from text files.

6. Names for topics, nodes, and packages should be consistent and simple.

image (2)

Meeting 6/16/13

In addition to being the first meeting of the coming year, this was also our IGVC 2013 postmortem meeting. We discussed what we did right in the past year, how we did at the competition, what we did wrong, and how to do better. Frank, Sagar, and I collected our thoughts on the matter in a Google doc. (We also filmed all of our runs and uploaded them to the UT RAS youtube channel.) For more details on what we did last year, see last year’s blog.

We can start working on a few things now, such as getting a new wheelchair base (the gearbox on our current one will likely stop working soon and is too expensive to replace), replacing the PSoC with a microcontroller that has USB driver support (which requires rewriting the implementation of our Computer-microcontroller communication protocol), starting to get money for expensive equipment, and getting V-REP integrated with ROS. Sagar and I are also working on documenting the code from this past year in the wiki connected to our GitHub repository.

Sagar and Frank will both be gone in the Spring 2014 semester, so the question remains of who will be on the IGVC team besides myself. Rachel, Yves, and Joshua Bryant attended this meeting and expressed interest in helping out in the coming year. Rachel is interested in taking on embedded stuff, Josh will probably continue to work on mechanical things, and Yves seems interested in helping with software.