Implementation

Hardware

Turtlebot

This lies on the full-scale field and is in charge of pushing the crate to the appropriate position.

Webcam

Two webcams are used to detect changes on the small-scale board and locate the Turtlebot and crate.

Crate and Block

The crate and block are the objects that will be moved around

Software Organization

At the very top we begin with two Robotic Operating System (ROS) nodes that access our two webcams. Each webcam node is spun up with AR tracking that is specifically setup for looking at the appropriate AR marker size on the field/board. The nodes publish the camera images and corresponding AR marker coordinates with respect to the webcams.

The coordinates then feed into our main program which handles the control logic that determines where the crate needs to move and how the turtlebot should move to achieve the corresponding crate movement. After determining and saving an optimal path, the program uses proportional control to determine the commands to smoothly follow the decided path. These commands are published to the turtlebot, and then the software then uses the AR tag positions to checkup on the turtlebot's progress.

Software Specifics

Waypoint Navigation

Planned pushing paths for our main control loop are modeled as a waypoint navigation problem. The robot is given a sequence of waypoints which upon navigating in correct order should push the crate into the appropriate place. With the correct control, this reduces our crate pushing problem to optimal waypoint selection. By choosing the correct waypoints to avoid unexpectedly hitting the crate, we can reliably move the crate.

This system is made robust with exclusive proportional control (next paragraph) and appropriate spacing constants that specify the size of the turtlebot and size of the crate.

Exclusive Proportional Control

When it comes to pushing the crate, one assumes that the turtlebot will be travelling in a straight line, but with simple proportional control, the turtlebot moves with both angular and linear velocity at the same time. While this gives efficient, arcing paths, this leads to a fair amount of unpredictability in terms of object interaction, meaning that our crate might be pushed incorrectly. On top of this, navigating paths around the crate to get to the correct side could be catastrophic if the turtlebot ends up constantly adjusting the crate and constantly re-planning paths.

Our solution to this problem is exclusive proportional control where if the turtlebot is within some angular Δ of the next waypoint then the software will exclusively issue proportional linear velocity commands. Otherwise, proportional angular commands are issued. Because of this system, the robot is able to consistently travel straight line trajectories which is important for crate pushing.

AR Coordinates & Snap to Lattice

Using the AR tags we were able to retrieve the coordinates of all objects. Note for the field and board there is an extra AR tag in the corner, this is designated as the board/field's respective origin.

Also to simplify the control, we snapped each coordinate on the board to the closest lattice point. For example, the upper left block (top left image) corresponds to spot (0,0) which can be visualized in Rviz (bottom left image) as ar_marker_14 which lies in the center of that grid square.

The (0,0) coordinate in the board, corresponds to the (0,0) coordinate on the field where the crate (top right image) currently sits. In Rviz we see the corresponding AR markers lying inside the correct grid squares.

Webcam Launch File

With two separate webcams looking over the field and board we couldn't actually use identical nodes for both webcams. Due to the way the AR tracking software detects distances, each webcam node needs to have the sizes of the AR tags it is looking at be manually inputted. Due to this small detail it was necessary to have an efficient way in the launch file to swap which device the nodes use in order to ensure the correct device was attached to the correct node/AR tag size.

Setup

Board (above):

Directly above the grid is a webcam with a top-down view of both blocks. The block in the top left corner is designated to be the board's origin. The second block is the small-scale representation of the crate. Both have AR tags to keep track of their positions.

Field (left):

We attached a webcam (with a USB extender) to the top of a tripod to give us a slightly larger field of view. The field consists of the turtlebot, red crate (next to the turtlebot), and field origin AR marker. Both the crate and turtlebot have AR tags on them for determining the appropriate coordinates.

Complete System Operation

In order to operate the system, first both the board and field should be setup according to the above setup paragraph. With the hardware setup there are a couple of software setup steps:

Connecting and initializing the turtlebots. This involves SSH'ing into the turtlebots and running a minimal bringup sequence
Launching the webcam nodes. This involves using ROS to launch the appropriate webcam AR tracking launch file mentioned earlier. In the event that the webcams are not labelled correctly (board is usb_cam0 and the field is usb_cam1) the webcams should swap USB ports.
Visualizing in Rviz. Using Rviz we must ensure all the relevant AR tags are in frame and detected by the two webcams. At this step we can also ensure the webcams are attached to the correct nodes.
Finally we use ROS to run the main python file that encompasses all of the coordinate transforms, waypoint selection, waypoint planning, and exclusive proportional control.
In order to get the robot to start pushing the crate, move the block (on the board) to a different lattice coordinate. This will tell the software that the block position moved, telling the turtlebot to update the field.

Report abuse