The goals of the final project are to demonstrate cooperative autonomy and to provide an open-ended set of challenge tasks to allow you to exercise the topics you've learned in the course. The tasks described below are intentionally open-ended to allow for creativity in accomplishing each tasks. It is also not expected (or required) that teams complete all the tasks; the reason to have a variety of tasks is to allow teams to customize their approach and their project.
The project is also open to ideas or custom tasks that extend the project. For example, incorporating a different sensor (e.g., a camera or short-range RFID reader) would provide many options for additional tasks that could be of more interest to particular students.
Mine Countermeasures Analogy
The motivating application the final project is emulating is a mine countermeasures problem including wide-area search/survey, followed by reacquisition, identification and deactivation. Our analogous scenario is to use wheeled robots with onboard RFID readers. The mine-line-objects in our scenario are RFID tags in unknown locations.
The following tasks are intended to be an outline of incremental steps towards a multi-robot system capable of detecting, identifying and localizing RFID targets in increasingly complex environments. You are not expected to complete all of the tasks, but instead to use the tasks as possible examples for building a functional robotic system.
Single Robot Search
Given map (occupancy grid) of the operating area with unknown number and location of "mine" targets, one robot should be able to efficiently search the mapped area to detect, identify and localize the RFID targets within the area. This is very similar to the second exercise in Assignment 7: Leader Follower and RFID (19-3), but with the added necessity of having the robot autonomously search the space. There are a number of effective search algorithms that might be employed. Also, don't feel that you need to use the same operational area (map) from previous labs; it may make more sense to use a different smaller/larger area of the task.
The system provides the identification and estimated location for all of the mines in the operational area. This can be done in post-processing (after the mission) or in real-time, which is a bit more challenging.
Extending single robot search to multiple robots.
Given a map of the search area, multiple (more than one) robots work together to detect, identify and localize targets within the defined operational area with an given map of the search area.
For this tasks there are two distinct roles for the robots: a searching robot and and identification robot. The wide-area searching robot(s) are tasked with estimating the location of targets. These estimates are relayed to the identification robot(s), which then reacquire the target to provide the identification.
The tasks above are meant to follow directly from the assignments/labs of the course. Students are encouraged to extend the project in the direction of their own interests. Below are some ideas on possible extensions.
- Adaptive search. When a robot detects a target it should switch from a wide area search behavior to a fine survey to better localize the target, then switch back to the original survey pattern.
- Complete coverage search. It is likely that the original search method was based on a pre-defined survey approach. How could the system generate its own search plan to completely cover the operational area with the provided sensor?
- Frontier exploration. Most of what we have done so far relies on access to a known map to support robot localization. Our method of generating the map was to teleoperate the robot within the space. There are other options of generating the map while localizing. For example the frontier_exploration and explore_lite packages illustrate methods to have the robot build maps in a more automated fashion.
- Multi-Robot Mapping. We have also relied on mapping from a single platform. The multirobot_map_merge package allows for the combination of maps from multiple platforms.
- RVIZ visualization of RFID. It would be interesting to have RVIZ plot the estimated location of the RFID detections.
You team should create an NPS GitLab project to document your project. This GitLab project includes a git repository, for the code (launch files, config files, MATLAB/Simulink, etc.), and a wiki for project documentation. You will develop a project wiki in the style of other open-source contributions to the ROS ecosystem.
One of the advantages of ROS is the large community of users which have contributed to the software and its documentation. As a result of this scale there are user contributed tutorials on many of the use-cases that you might encounter. The following are some ROS projects with good documentation that you can use as a model for your project:
- navigation: The navigation stack includes a number of subsidiary ROS packages (e.g., amcl and move_base) - each with its own documentation
- smach: A state-machine implementation for ROS.
- turtlebot3: A central collection of of the many packages/projects associated with turtlebots.
ROS Project Documentation and Tutorials
The objective of your project documentation is to provide an explanation of what your solution does and how it works so that other users could reproduce your results. Consider the audience to be a ROS user that is trying to use your project as a starting point for their own work. As with the examples above the documentation should provide description (what the project does and how it does it), documentation (interface description of topics, services, etc.) and tutorials (recipes for reproducing your results).
Considering the following set components as possible aspects to include:
- Introduction: Summary of what is included
- Instructions on setting up and running your solution with sufficient detail for a reader to reproduce your results. This should include links to any dependencies, instructions for accessing your software (e.g., links to git repositories) and annotated commands for making each piece of the system work.
- Performance: Documentation of what you were able to achieve using the your approach.
- Troubleshooting information is very beneficial - if there are common pitfalls, it is very helpful if they are explained.
- Next steps: A list of how to improve the project will help others know where they can contribute.
Videos are a great way to document your projects by illustrating the performance of experiments and/or simulation results. If submit videos as part of your project, please don't put them in a git repository. Instead, put them online (youtube, vimeo, etc.) or put them on a shared drive (see https://nps.account.box.com/login) and include the link in your report.
The project is an opportunity to demonstrate that you are able to put to use the tools we've learned in the class to solve a particular robotics challenge. The documentation should describe what you were able to achieve (system performance) and how you approached the problem (system design). Where possible, quantify your results using experimental data.
Below is a rubric that will be used in evaluating the documentation.
- Technical Content (40%)
- Appropriate, viable discussion what is being done and how the solution is designed and implemented.
- Clearly describes what objectives and the evidence (experiments and demonstrations) to illustrate the solution.
- Code repository is organized to facilitate community re-use.
- Technical Writing (40%)
- Appropriate figures (graphs), images and tables to describe the project
- Captions provide a stand-alone description of the contents
- Graphs have labels on all axes (with units), use appropriate linestyles and include a legend (if appropriate)
- All figures and tables are referenced and discussed within the text
- Text within figures (labels, legend, annotations, etc.) is of appropriate size and format to be clearly legible
- Organization and Writing (20%)
- Proper format of document including logical organization of document into appropriate sections (and subsections)
- Report includes brief Introduction and Conclusion sections.
- Ideas a segmented into logically complete paragraphs
- Correct spelling and grammar
- Compliance with Strunk and White’s “Elementary Rules of Usage”
- Comparisons and conclusions are as quantitative as possible: avoids qualitative words such as “good”, “reasonable”, “acceptable”, “significant”, “about”, “approximately”, etc.
Each team should...
- Create a GitLab project on the NPS server and provide a link to the project to the instructor.
- Create a first wiki page describing the project
- What the team expects to achieve
- First design of how the solution will be implemented.
Each team should create a wiki page on the project site to provide an intermediate status update on the project, including...
- Brief list of what was accomplished during the week.
- List of tasks for the next week, leading to the final project deliverables.
- Identification of any high-risk topics or issues.
The topics below are items that may be potentially useful for specific projects, e.g., ROS packages, etc.
- Turtlebot Autonomy
- If you want to have the turtlebot run independent of the laptop, you need to run the ROS master on the turtlebot Raspberry Pi. One way to start would be to return to the initial turtlebot setup in Assignment 4: Networking, Turtlebot Setup, Waypoint Navigation (19-3) and switch network setup so that the ROS master is associated with the Raspberry Pi IP address.
- MultiMaster is a method for coordinating the ROS system when there are more then one ROS master on the network. The multimaster_fkie is a good implementation that we've used previously in the course (see Assignment 6: Callbacks, Multimaster and Multiple (N=2) Robots (17-3) for an example of setting up multimaster with Pioneer robots). Setting this up on turtlebot(s) would be a nice contribution.
- Simulink deployed on Turtlebot. So far we have been developing in a prototype scenario where we run Simulink on an offboard laptop. It may be possible to compile the Simulink program to be deployed on the Turtlebot Raspberry Pi.
- The Mathworks provides an example, Generate a Standalone ROS Node from Simulink.
- A similar video example from Mathworks mentions deploying to a Raspberry Pi https://www.mathworks.com/videos/matlab-and-simulink-robotics-arena-deploying-algorithms-to-ros-1510659362460.html
- We are starting to document some examples internally at NPS here Standalone ROS Nodes from MATLAB/Simulink
- Strings in ROS Messages with Simulink
For example, if you want to send a goal to the move_base node via the move_base_simple/goal topic, you need to publish a geometry_msgs/PoseStamped message. Part of that message is the
frame_idstring. The Mathworks provides a good tutorial for doing this: Work with ROS Messages in Simulink.
- Running move_base on multiple robots can be challenging. You need to work out both the tf frames (unique frames) and namespaces. Here is an example of doing this: https://github.com/ferherranz/multi_robot_stage/blob/master/launch/navigation.launch
- See working example Multirobot move_base
- Setting Logging Level : Describes how to change the verbosity of the output of a ROS node. In particular how to turn on the debugging messages to help fix a problem.
Final Project Repositories
- wiki: Search and Reacquire
- wiki: Exploring Frontiers