statespacerobotics/robot2017

2017 Robot code and simulation assets.

This repo follows Vincent Driessen's Git branching model. http://nvie.com/posts/a-successful-git-branching-model/

It is recommended to install git flow to automate common commands for this model. https://github.com/nvie/gitflow

Additionally, tab completion is available. https://github.com/bobthecow/git-flow-completion

robot2017's Issues

Modification of ARUCO stack setup

Modify the ARUCO stack setup as needed to allow multiple camera inputs to it.

High Level State Machine testing and modifications

The High Level State Machine (HLSM) node needs testing for robustness as well as any updates necessary for the new robot.

Framing things

Make sure that the map frame and odometry frame are correct for use with the nav stack -Billy

• Make sure the frame labels are correct. Specifically, the ArUco and beacon pose topics.
• Generate a transform between the map frame and the odom frame.

There are two main frames, the map and the world. These are fixed.
There are base_link and odom frames.

• Base_link is the robot; it's a local frame of reference.
• Odom is semi-fixed. Odom is locally continuous. Whenever you make movements, the odom will be continuous, which is necessary for path planning.

The odom frame is built from IMUs and motor encoders. Error starts to accumulate, but it's continuous. GPS and ArUco are put in a different frame because they aren't continuous and will screw up continuous frames (like odom). ArUco functions really similarly to a GPS.

Robot Pose EKF can take an arbitrary number of poses and velocities, both continuous and noncontinuous sensors, and return a single pose.

Organize ALL the launch files

We want to organize our launch files to make it easier to find the correct files when we're running simulations and when we are running the real robot.

Primary Goals
In the cr17 package, there should be two primary launch files:

• There should be a launch file that runs all of our nodes
• There should be a launch file to run the entire physical robot, including sensors and the launch file that launches all of our nodes (the above item)

In the simulation_2017 package, there should be one primary launch file:

• There should be a launch file that includes the launch file that launches all of our nodes and includes necessary simulation sensors

Secondary Goal

• After these primary goals are met, we can make some launch files particular to certain nodes, nesting them hierarchically.

Finalize message string

We need to hash out a minimalist message string for Telnet control of the minibot. Currently, linear and angular velocities are needed as well as servo position.

ROS joystick control

We need a joystick control node for testing the minibot control stack. Use a single stick and comply with ROS Twist formats for now.

Mapping of obstacles

The obstacle_mapper node needs to be written. It will build an occupancy grid based on the objects that the node(s) used for object detection identify, accounting for possible noise in the detected objects.

Verify autonomous run in gazebo simulation

Run launch file that simulates R2-D2 bot going through process of collecting and dumping dirt in Gazebo

• Field is already set up with beacon

AC: have Aruco and path planning working;
- have bot traverse field, collect, and return, autonomously

Implement PID control

We will have encoder feedback on the esp. We need some form of PID loop for sending commands to the Sabertooth. Consult the docs for the Sabertooth2x5's message format. It should be implemented as a function to generate the next PWM command that is called within the main loop after the WiFi callback. Additionally, consider exposing the constants for change via Telnet or Serial1.

Controller for scooping mechanism

The scoop_controller node needs to be made. This may require two versions, one for CR16 and one for CR17, since they have different designs for the scooping and CR17 should have feedback on the position of parts.

Improving the Navigator Node

The navigator node needs fine tuning.

testing and updating of the particle filter

The particle_filter_localizer node from the previous year needs testing and may need other updates as well, such as using the parameter server.

Detection of when it gets stuck

The stuck_detector node needs to be implemented. It will use information from the wheel encoders and from the current estimated position to determine if the robot is stuck.

Encoder Interrupts

Implement interrupt driven quadrature encoder processing for wheel velocity estimates.

Implementation of object detection

Implementation of object detection. This encompasses the plane_detector node, and any other necessary nodes for this. If more nodes are used, document them in the wiki.

Interface to the mbed

The mbed_interface needs to be implemented. This node will go from ROS to the mbed using the USB chip on the mbed.

Implementation of path planning

Implement the path+planner node. This is for identifying the path through the obstacles.