To improve upon version 2 of the code base, focusing on changes to:
Ease of expansion - building infrastructure that makes adding functional modules to the code base easy
Reclaiming functionality of some nodes from version 1, that were unused in version 2
Improving upon existing nodes
Cleaning up the code base by throwing away unused files
Continue reading for details on each aspect of this project.
Rather than lumping all nodes into either "onboard" or "offboard" launch files, we have created a series of launch files that can be added to either main launch file. Furthermore, these launch modules can be disabled in the command line. Here is how this was achieved:
Here is the launch module for alexa voice integration:
It is added to the offboard launch like so:
SO if you wish to launch offboard without voice, use this command:
Going forward, all new features should be added to their own launch module, where the module contains all nodes that are required for the feature to work properly. The only excepition is if a new feature is added to the core of the package, and is required for the package to function properly.
A handful of changes have been made to the state manager interface. They include
get_state now communicates via the state query service, rather than directly accessing the current_state field.
get_state and change_state now have error handling to deal for the event that the state serivces are unavailable.
New functions have been added to the state_tools file which should make interfacing with the state manager easier.
To make it easier for new users to begin working with the existing campus rover platform, we have created a set of install scripts that will make the setup time significantly faster, and remove all the guesswork. Refer to the cr_ros_3 package readme for installation instructions.
Prior to cr_ros_3, the campus roverr platform only worked on robots running ROS Kinetic. Now, the platform will run on robot running ROS Melodic.
Formerly known as "message_switch", the talking queue was an overlooked node that did not recieve much attention until now, as it was overlooked for directly interfacing with the talk service. As the code base grows and more features may wish to use the on-board text to speech feature, a queue for all talking requests is a nessecary feature.
Using the talk queue from another node is easy. First, import the following:
Set up a publisher to the /things_to_say topic
Whenever your node wishes to produce speech, utilize a line of code similar to this:
The location narrator is a novelty feature that has been reclaimed by:
indtroducing a new set of waypoints in files/waypoints.json that correspond to the basement demo area
modifying the existing script to narrate whenever the nearest waypoint or the state changes.
Innaccuracies in costmaps can lead to difficulty in navigation. As such, we have implemented costmap clearing under the following circumstances:
Navigation returns the 'aborted' code
The robot exits the flying state and enters the lost state
Here's why:
When navigation fails it is often because the costmap is muddled in some way that prevents a new route from being plotted. If the costmap is cleared and the goal is re-sent, then navigation may become successful.
A human lifting the robot create a significant amount of lidar noise that is innacurate because the robot is not on the ground. Therefore, when the robot is place back on the ground it deserves a clean slate.
Here's how:
First, the Empty service topic must be impported
Then establish a serivce proxy
Finally, any time a node requires the costmap cleared, ultilize this line:
The Rasbperry Pi camera that is mounted to Mutant is mounted such that by default, it is upside down. Fortunately, Ubiqutiy's rapicam_node that we ultize supports dynamic reconfiguration. This can be done manually using the following shell command:
This will bring up a GUI which will allow various aspects of the camera configuration to be manipulated. It also allows for a given configuration to be saved in a yaml file. Unfortunately, changes made through dynamic reconfiguration are temporary, and using a GUI to reconfigure every time is tedium that we strive to eliminate. The solution lies in camera_reconfigure.sh. We saved our desired configuration to camera.yaml from rqt_reconfigure. camera_reconfigure.sh uses that yaml file in this crucial line:
Thus, automatic reconfiguration is acheived.
Transforms are tricky. Version 2 never quite had accurate fiducial localizations due to bad static fiducial transforms. Through trial and error, static fiducial transforms have been edited and the pose esitmates have become more accurate as a result. We found it useful to refer to this static transform documentation to help remember the order of the arguments supplied to the static transform publisher:
If Rviz is not supplied the right settings file, it can produce a lot of frustrating errors. This was the case with our old settings file. We have generated a new settings file. How? Here are the steps:
launch default turtlebot navigation
save the settings from Rviz as a new file
set Rviz in mutant_navigation.launch to use the new settings file
make the necessary changes to the left bar to make Rviz visualize navigation properly (ex. using scan_filter as the scan topic rather than scan)
save your changes to your settings file
We have added ngrok_launcher.sh which will bringup an ngrok tunnel to the alexa webhook to allow the alexa voice nodes to function.
Minor updates have been made to cr_web to accomodate a few changes to the code base. They are:
localhost port changed from 5000 (default) to 3000, to accomodate cr web app and ngrok webhook running on the same machine
Updated the map file to match current demo area layout.
Files related to the following were removed:
gen2 facial recognition
gen2 package delivery
gen3 facial recognition
gen3 hand detection
Fortunately, all these files still exist in version 1 and/or version 2 of the code base, so if they wish to be salvaged, they could be.
The campus rover code base is arguably in it's best state that it has ever been in. We eagerly look forward to how it will continue to grow in the future.