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.