UP | HOME

Homework 3

Logistics

  1. Create a git repository using the link provided in Canvas.
  2. Your homework will be submitted via this git repository.
  3. I will grade whatever is on the main branch when I clone the repository.
  4. Guidelines provides important information about what you should turn-in, including information about your README.md file.

Part I: Gazebo Differential Drive Challenge

The challenge is to create a differential-drive robot that can be simulated in Gazebo and controlled by ROS.

  • The robot will be able to flip over and continue driving
  • The robot will move through a world filled with Jersey Barriers and trash.

Package Structure

The package should be called diff_drive In addition to the standard ROS directories, the package should be structured as

  • config/ (.yaml files)
  • urdf/ (urdf.xacro and .gazebo.xacro files)
  • launch/ (.launch.py files)
  • worlds/ (.sdf files, if needed)
  • models/ (.sdf files, if needed)

There is a hints section at the bottom of each section.

Creating the World

  1. Using models from Gazebo Fuel (and the resource spawner) create a world called world/ddrive.world with the following features
  2. Write a launchfile called launch/ddrive.launch.{py,xml} (python or xml your choice).
    • For now, it should launch gazebo and load the world you just created.

The Xacro URDF

Robot Description

  1. The robot has a body consisting of a rectangular prism. It has two cylindrical wheels on the front and a caster at the rear.
    • There should be a caster on the top and bottom of the robot so that it is symmetrical about its horizontal plane
    • Each caster link should be modified to have no friction in gazebo so that it can slide freely.
    • Feel free to set the masses and dimensions of the robot to suit your needs (though trying to be realistic in terms of mass and density can help).
  2. Create a ddrive.urdf.xacro file to describe the differential-drive robot.
    • The dimensional parameters of the robot should be stored in a .yaml file and referenced in the xacro file
    • Each link you add must have the proper collision bounding box and inertia.
    • Place gazebo specific tags in a separate ddrive.gazebo.xacro file and include it in urdf xacro file.
  3. Create a launchfile called ddrive_rviz.launch.{py,xml} that launches the urdf in RViz, along with a robot_state_publisher
    • If argument view_only is true, then a joint_state_publisher_gui is also launched
    • This launchfile will be useful for debugging.

Gazebo Extensions

  1. Add the "Differential Drive" plugin to your robot, as appropriate (in the ddrive.gazebo.xacro file).
  2. Add a new rviz configuration that also shows the odom message in rviz.
    • Load this configuration when view_only is false in ddrive_rviz.launch.{py,xml}
  3. Modify ddrive.launch.{py,xml} so that it
    1. Spawns the URDF model in the gazebo world and starts the simulation.
    2. Runs ros2_gz_bridge so that odometry and joint states are published from the robot to ROS on the appropriate topics
    3. Includes ddrive_rviz.launch.{py,xml} to launch rviz.

Control

  1. Write a node called flip that makes the robot move back and forth along a line by flipping over itself rather than turning.
    • Both wheels move with the same velocity at all times
    • You will need to use the dynamics of the robot to accomplish this task.
    • You may find that the teleop_twist_keyboard package is useful for letting you get a feel for the dynamics.
    • Precise control is great but not necessary, just have fun doing some flips.
  2. Make sure that ddrive.launch.{py,xml} starts the flip node

Hints

  1. For this exercise, you may wish to use xacro macros to create the visual, collision, and inertial elements from a single set of parameters specifying the geometry and orientation of the link.
    • For example, in this case the visual and collision elements can be identical
    • Macros can be nested. So build them up slowly and view the results incrementally by outputting the urdf file from the xacro file.
    • There is an option for viewing inertias in rviz under the RobotModel view
  2. Just like with ROS nodes, an old gazebo simulation running in the background can be trouble.
    • Use ps aux | grep gazebo to find old gazebo instances

Part II: Motion Planning Interface (Group)

Write a class that enables you to plan and execute paths easily using an already running move group node. It should have, at minimum, the following features:

  1. Plan a path to a specified position from any starting configuration (but where the orientation of the end-effector remains unspecified)
  2. Plan a path to a specified orientation from any starting configuration (but where the position of the end-effector remains unspecified)
  3. Plan a path to a specified pose (position and orientation) from any starting configuration
  4. Execute any of the above paths either immediately after planning, or saving the path to be inspected at a later time.
  5. The starting configuration for your path planning methods should default to the current configuration of the robot.
  6. Add the ability to add a box to the planning scene dynamically
  7. This section is done in your final project groups and should be submitted as a single git repository
  8. Everyone is expected to contribute equally (as evidenced by commits and peer evaluations).
  9. Use the Simple Git Workflow to coordinate git commits
  10. In your README.md, listing all group members as authors and provide instructions on how to use your package (written from the perspective of somebody who is already familiar with ROS 2).

Part III: Planning (Individual)

  1. Create a package called pickmeup and place it in your individual git repository
  2. Use the interface created with your group to perform the following pick-and-place task with the PincherX 100 robot:
    • There is a table (which should be part of the planning scene) and a crumbled piece of paper (or other object of your choice) on the table
    • The PincherX 100 should pick up the object then rotate 90 degrees and drop the object.
  3. There are two modes of operation:
    1. Using the "fake node", the robot goes through the motions but does not actually pick anything up
    2. Using the "real" mode, the robot moves in the real world and actually picks up the object
  4. A single launch file called pickup.launch.{py,xml}, takes a hardware_type parameter (fake is default or real) will be used to perform both tasks.
    • It runs the appropriate Pincher X 100 launchfile with the appropriate options
    • It starts a node called picker, with two parameters (x and y) that specify the location of the object relative to the robot base.
    • Upon starting the node executes the required task.
    • rviz should also be running and the robot in rviz should (when the real robot is running) follow the movement of the real robot.
  5. Include a link to a video in your README.md of the robot in rviz and in the real world accomplishing its task
  6. Include a mover.repos file that allows your repository and your group's repository to be easily downloaded with vcs tool

Author: Matthew Elwin