Homework 3
Logistics
- Create a git repository using the link provided in Canvas.
- Your homework will be submitted via this git repository.
- I will grade whatever is on the
main
branch when I clone the repository. - 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
- Using models from Gazebo Fuel (and the resource spawner) create a world called
world/ddrive.world
with the following features- An asphalt ground plane
- At least two Jersey Barriers
- At least two Cardboard Boxes
- At least two other models of your choosing
- 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
- 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).
- 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 thexacro file
- Each link you add must have the proper collision bounding box and inertia.
- Place
gazebo
specific tags in a separateddrive.gazebo.xacro
file and include it inurdf
xacro
file.
- The dimensional parameters of the robot should be stored in a
- Create a launchfile called
ddrive_rviz.launch.{py,xml}
that launches theurdf
in RViz, along with arobot_state_publisher
- If argument
view_only
is true, then ajoint_state_publisher_gui
is also launched - This launchfile will be useful for debugging.
- If argument
Gazebo Extensions
- Add the "Differential Drive" plugin to your robot, as appropriate (in the
ddrive.gazebo.xacro
file). - Add a new
rviz
configuration that also shows theodom
message inrviz
.- Load this configuration when
view_only
is false inddrive_rviz.launch.{py,xml}
- Load this configuration when
- Modify
ddrive.launch.{py,xml}
so that it- Spawns the URDF model in the gazebo world and starts the simulation.
- Runs
ros2_gz_bridge
so that odometry and joint states are published from the robot to ROS on the appropriate topics - Includes
ddrive_rviz.launch.{py,xml}
to launch rviz.
Control
- 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.
- Make sure that
ddrive.launch.{py,xml}
starts theflip
node
Hints
- 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 theRobotModel
view
- 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
- Use
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:
- Plan a path to a specified position from any starting configuration (but where the orientation of the end-effector remains unspecified)
- Plan a path to a specified orientation from any starting configuration (but where the position of the end-effector remains unspecified)
- Plan a path to a specified pose (position and orientation) from any starting configuration
- Execute any of the above paths either immediately after planning, or saving the path to be inspected at a later time.
- The starting configuration for your path planning methods should default to the current configuration of the robot.
- Add the ability to add a box to the planning scene dynamically
- This section is done in your final project groups and should be submitted as a single git repository
- Everyone is expected to contribute equally (as evidenced by commits and peer evaluations).
- Use the Simple Git Workflow to coordinate git commits
- 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)
- Create a package called
pickmeup
and place it in your individual git repository - 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.
- There are two modes of operation:
- Using the "fake node", the robot goes through the motions but does not actually pick anything up
- Using the "real" mode, the robot moves in the real world and actually picks up the object
- A single launch file called
pickup.launch.{py,xml}
, takes ahardware_type
parameter (fake
is default orreal
) 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
andy
) 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 inrviz
should (when the real robot is running) follow the movement of the real robot.
- Include a link to a video in your README.md of the robot in
rviz
and in the real world accomplishing its task - Include a
mover.repos
file that allows your repository and your group's repository to be easily downloaded withvcs
tool