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:
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.
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.