UP | HOME

ME495: Embedded Systems in Robotics

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. See Guidelines for important information about coding standards
    • Read over the guidelines prior to starting this assignment, they contain important information about what you should turn-in.
  5. In this document, the notation ${ws} means to substitute ${ws} with whatever value is appropriate (like a bash variable substitution).
    • For example, if ${item} = Hello There than "This is the message: ${item}" becomes "This is the message: Hello There"

Part I: Inspection

Here you will inspect a poorly-documented ROS package called crazy_turtle and improve its documentation.

  1. Create a new ROS workspace. Your workspace directory is ${ws}.
    • Do not have any spaces the full path to your workspace: this may cause trouble later
  2. Clone https://github.com/m-elwin/crazy_turtle into the source space (i.e., ${ws}/src) of the workspace.
  3. Your homework repository (call it ${hw}) should also be under ${ws}/src

  4. Your Workspace should look like the following (assuming that ${ws} = ws and ${hw} = turtle_hw: 

    ws/                    # This directory is NOT a git repository
ws/src                 # This directory is NOT a git repository
ws/src/crazy_turtle    # This directory is a git repository, but it is my git repository not yours.
ws/src/turtle_hw       # This directory is the git repository you are using for this assignment.
  5. Copy ${ws}/src/crazy_turtle/README.md into ${ws}/src/${hw}/inspection.md and add it to your git repository.
  6. inspection.md contains additional exercises that you should complete. Follow inspection.md and replace the ${item} substitutions with the answer.
    • This exercise also serves as a quick introduction to some markdown basics.
  7. Copy crazy_turtle/nodes/mover to $ws/$src/$hw/mover. Edit the file and search for ${item} substitutions, replacing them with the appropriate word or phrase.

Part II: Turtle Control

In this section you will write a package called turtle_control that makes a turtle in turtlesim follow waypoints.

First, you will have a turtle draw the waypoints in turtlesim. Next, a different turtle will follow those waypoints.

  • Each task below (with one exception) can be roughly followed in order.
  • I suggest that before beginning you read through to understand the full scope of the problem.
  • It also makes sense to work on the Launchfile in parallel, as having a launchfile early makes testing and debugging easier.

Package Setup

  1. The package you create should be called turtle_control and contained in a single git repository
  2. Create the package.xml and CMakeLists.txt in the turtle_control repository.
    • I recommend using catkin_create_pkg so you can read the comments in the generated files and learn about the format.
    • Edit the package.xml to change the default but required fields to reflect your name, email, and a description of this package.
    • The package exec_depends on rospy and message_runtime (since we use rospy and python messages when the code runs.
    • The package depends on turtlesim because we use messages/services defined in that package.
    • The package build_depends on message_generation because we will be created custom messages and services.
    • There will be other dependencies that come up as you work on this assignment. Be sure to add them to package.xml and CMakeLists.txt as appropriate
  3. Add package.xml and CMakeLists.txt to your git repository and commit them.
  4. At this stage an ls -a in the base directory of your repository should show .git, package.xml, CMakeLists.txt and (if appropriate for you) .gitignore

Drawing the Waypoints

Node: setup

  1. The setup node is responsible for drawing all of the waypoints. Code this node in nodes/setup
  2. The waypoints should be stored in config/waypoint.yaml as a list of coordinates (each coordinate is itself a list of length 2).
    • For example, a list of 3 waypoints is [[1,2], [3,4], [5,6]]
    • The waypoints will be loaded into the parameter server as /waypoints
    • To start out, you can hard-code the waypoints
  3. The setup node should implement a service called draw of type std_srvs/Empty.
    • First, the service resets the turtlesim and clears all drawings
    • Next the service draws all the waypoints, using an X shape
    • You can draw line segments by teleporting the turtle while lifting and dropping its pen, as appropriate.
  4. Use rosrun to run your node, rosparam to load the yaml file into the parameter server, and rosservice to call the service

Velocity Translator

Custom Message: TurtleVelocity

  1. Velocities in ROS are 3-D and use the geometry_msgs/Twist type. For 2D velocities, linear.x is the forward velocity and angular.z is the rotational velocity.
  2. Create a custom message called TurtleVelocity, with the following two fields:
    • linear (float64): the linear velocity of the turtle in m/s
    • angular (float64): the angular velocity of the turtle in rad/s.
    • Be sure to add comments (the # character begins a comment) describing the fields.
    • Message definitions go under the msg subdirectory of your package (e.g., turtle_control/msg).
  3. To properly use the custom message, follow the instructions as laid out by the long block comment in CMakeLists.txt
  4. Make sure your package compiles cleanly with catkin_make and has no linting errors from catkin_lint before proceeding
    • The errors from catkin_lint help explain why catkin_make fails.

Node: translate

  1. Write a node called translate that converts between geometry_msgs/Twist and turtle_control/TurtleVelocity messages
  2. The node subscribes to a topic called turtle_cmd of type TurtleVelocity
    • The subscriber logs the input as a debug-level message
    • The subscriber publishes a corresponding geometry_msgs/Twist message on the cmd_vel topic
  3. Test the node by using ROS commands to send messages while watching the ROS log and the cmd_vel topic.
    • To see the debugging message you will need to adjust the logger level of your node's rosout to debug.
    • You can use either rqt_logger_level or change settings in rqt_console.

Waypoint Follower

Write a node called follow that causes turtle1 to follow a series of waypoints. When the turtle reaches the last waypoint it should head to the first waypoint and restart the cycle.

Parameters

  1. The waypoints are loaded into the Parameter server from config/waypoint.yaml (this is the same file and parameter used by the setup node)
  2. Private parameter dist_thresh is used to determine when the turtle is close enough to its destination to move to the next waypoint.
  3. You may also add additional parameters if appropriate for your algorithm.

Subscribers

  1. The turtle may subscribe to the pose topic from the turtlesim to read the pose, as reported by the turtle.

Services

  1. Create a custom service type called Start
    • Inputs, are x (float64) and y (float64) coordinates
    • Output is distance (float64)
  2. The node implements a service called restart of type turtle_control/Start
    • If the x and y coordinates of the starting location are out-of-bounds, return None to indicate an error
    • The service calls the draw service offered by the setup node to clear the arena and draw the waypoints
    • The service resets the position of the turtle to it's starting location
    • The service computes the theoretical distance traveled by the robot after traveling from its starting location to all the waypoints (not including any wrap-around/waypoints visited twice)
    • The service starts the turtle moving and then returns the previously computed distance

Publishers

  1. The node should publish a TurtleVelocity message on the turtle_cmd topic to control the turtle and make it follow the waypoints.
    • The translate node subscribes to turtle_cmd and publish a cmd_vel for the turtle to follow
  2. The turtle should not start moving until the restart service has been called once.

Launchfile

  1. Write a launchfile called launch/run_waypoints.launch that loads all the parameters, launches the turtlesim, translate, follow, and setup nodes.
  2. The launchfile should connect all the nodes together to make the turtle follow the waypoints
  3. Instructions for how to use your package (to be put in the README) consist of the launchfile command to use, followed by an example call to the reset service.

Rosbag

  1. Use rosbag to capture enough cmd_vel commands for the turtle to visit each waypoint twice, when starting from (x, y) (you may choose any x and y.
    • Add the bagged data as a turtle_control/waypoint.bag (e.g., the root directory of your repository)
  2. Kill the translate node to stop the turtle from moving.
  3. Manually call the setup/draw service to reset the arena and call a service to move the turtle to (x, y).
  4. Use rosbag to play back your bagged data and make the turtle move.
    • You should not expect the trajectory to be duplicated, due to the inexact timing with ROS bags (see here)

Demonstration

  1. Install simplescreenrecorder (via apt) or different screen recording software and use it to create a video of your code working.
  2. Add your video to the README.md by placing it on a video-sharing website and writing out a link to it.

Author: Matthew Elwin