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 (Individual)

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 optionally the resource spawner) create a world called worlds/ddrive.world.sdf 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.
  3. IMPORTANT Make sure that the world sdf file does not contain any absolute paths. It seems that the resource spawner will use absolute paths on your local machine. You will likely need to manually edit the sdf file and replace file:// absolute paths with model:// relative paths. See Resource Spawner Notes for more details.

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)

The ROS 2 API for motion planning revolves around actions, services, and topics provided by the /move_group node. However, filling in the appropriate messages, requests, and goals can become tedious.

Instead, the goal is to make a library that abstracts the lower-level ROS API away and makes planning easier.

The project can roughly be divided into the following components. It is important to read about all the components to get a wider understanding of the project itself.

Group Organization

  • This part is done in your final project groups and should be submitted as a single git repository via the link on canvas.
  • Everyone is expected to contribute equally (as evidenced by commits and peer evaluations).
  • Use the Simple Git Workflow to coordinate git commits with each other
    • It is important that you follow the workflow so that everybody's contributions are incorporated and counted.
  • In your README.md, list 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).
    • Authors of the package need not be cited in citations.txt

Dividing the Work

  • I have divided the project into components that can be worked on mostly independently, once interfaces between them are designed.
  • I have also rated the effort required for each task
    • Each person should take on approximately 4 units of effort as their primary responsibility, and should also try to work on at least two areas.
    • Each person should be available to help on any of the sections.
  • Motion Planning: 8 units
  • Planning Scene: 2 units
  • Robot State: 2 units
  • Integration: 4 units
  • Sample Task 4 units

Work Flow

  1. It makes sense to setup the project so that different people are working in different files.
  2. If one module depends on another, define the module boundaries early and implement stubs. Then fill in the stubs later.
  3. In some cases, the best way to help is via pair programming: one student works at the keyboard while another looks on and helps.
    • If you do pair programming, it is important that you take turns so that each partner can have commits.
    • Especially at the beginning, as you are trying to establish the structure of the project, everyone being together and working on the same project makes sense.
  4. It is crucial to follow the Simple Git Workflow and integrate your code into the main branch frequently
    • The longer the team diverges, the harder it is to integrate the code later.
  5. Prior to getting to fancy and dividing up the tasks, it makes sense to work together on the MoveIt Activity to get up to speed on how MoveIt works and get some basic functionality working.

Motion Planning

Write a class called MotionPlanner that enables a user to:

  1. Plan a path from any valid starting joint configuration to any valid goal joint configuration.
    • If the starting configuration is not provided, the current robot position is used.
  2. Plan a path from a specified pose (position and orientation) from any starting configuration
    • If the starting configuration is not provided, the current robot position is used.
    • If the goal position is not specified, the plan should achieve the specified orientation (at any position)
    • If the goal orientation is not specified, the plan should achieve the specified position (at any orientation)
  3. Plan a Cartesian path from any valid starting pose to a goal pose.
    • If the starting configuration is not provided, the current robot position is used.
  4. Plan a path from any valid starting pose to a named configuration
  5. Any of the paths should be able to
    1. Be executed immediately after planning
    2. Be saved and inspected at a later time
  6. Estimated Work Effort: 8 Work Units

Planning Scene

Write a class called PlanningScene that enables a user to:

  1. Add or remove boxes to the planning scene dynamically, at any location
  2. Attach and detach collision objects to the robot's end-effector.
  3. Load a planning scene from parameters that specify the locations and sizes of objects.
  4. Estimated Work Effort: 1 Work Unit

Robot State

Write a class called RobotState that enables a user to:

  1. Perform inverse kinematics on the robot from an arbitrary end-effector pose
    • If no pose is specified, use the current location
  2. Perform forward kinematics on the robot from an arbitrary joint state
    • If no pose is specified, use the current location
  3. Retrieve the most up-to-date joint configuration or end-effector pose from the robot.
  4. Estimated Work Effort: 2 Work Units

Integration

The goal of integration is to combine the MotionPlanner, PlanningScene, and RobotState (referred to as MotionPlanningInterface) with each other and present it in a form that makes it easy to incorporate into a custom node (referred to as UserNode).

Here are some challenges:

  1. What UserNode does is not known at the time of creating the MotionPlanningInterface.
    • The user needs to be able to create UserNode in the usual way, while also using MotionPlanningInterface
  2. MotionPlanningInterface requires a Node object in order to maintain the RobotState and use the ROS API provided by the move_group node.
    • These components must all share the same Node.
  3. Some of the above functionality takes a long time (such as planning and moving the arm) so UserNode needs to have the ability to either wait for the task to complete or initiate a task, work on something else, and check for the result later.
  4. Estimated Work Effort: 4 Work Units

Sample Task

Setting The Scene

For this task you will assume full knowledge of locations and sizes of the following objects:

  1. A Table: this should be part of the planning scene.
  2. An object: the goal should be to grab this object and move it somewhere else
  3. An obstacle: this obstacle should be in between the end-effector and the object such that moving in a straight line would cause the robot to hit the obstacle

The Node

Write a node called pick_node that does the following in response to a call to it's /pick service:

  1. Moves the arm directly above the object
  2. Opens the gripper
  3. Moves directly downwards until the object is between the grippers
  4. Closes the grippers
  5. Lifts the object slightly off the table
  6. Attaches a rectangle (roughly corresponding to the size of the object) to the end-effector
  7. Moves the object to the other side of the obstacle
  8. Releases the object and detaches the rectangle

The Launchfile

Write a launchfile called pickplace.launch.{xml,py} (your choice of xml or python that

  1. Takes an argument called demo
    • If demo is true, it starts the Franka demo.launch.py
    • If demo is false, it just starts rviz (and assumes the proper nodes are running on station).
  2. Starts the Franka demonstration.
  3. Runs the pick_node

The Videos

  • Take a screencast of the robot performing it's task in demonstration mode.
  • Take a video of the the robot performing the task in the real world.
  • Include both videos in the README.md and make sure that they play properly on GitHub.

Testing and Documentation

  1. Write an integration test that uses the kinematic Franka simulation to command the Franka Panda robot to move from one pose to another and verify that the pose is achieved.
  2. Write an integration test, using the Franka Panda Robot demonstration that creates a planning scene object and attempts to move the robot into that object and verify that planning fails.
  3. Running rosdoc2 on your library should provide usable API documentation.

Author: Matthew Elwin.