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 and prior to submitting the assignment.
    • Your code need not pass colcon test for this assignment, but it is good practice for the future.
  5. In this document, the notation ${ws} means substitute the appropriate value for ${ws}
    • For example, if ${item} = Hello There than "This is the message: ${item}" becomes "This is the message: Hello There"
    • Be sure to remove the ${}

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 in 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 and checkout the ros2 branch.
  3. Create a git repository for homework1 located at ${ws}/src/homework1
    • Your directory structure should look like

      ${ws}                         # NOT a git repository
      ├─── src                      # NOT a git repository
      │     ├── crazy_turtle (ros2) # A git repository on the ros2 branch
      │     └── homework1 (main)    # Your git repository for Homework 1
      
  4. Copy ${ws}/src/crazy_turtle/README.md into ${ws}/src/homework1/inspection.md and add it to your git repository.
  5. inspection.md contains additional exercises that you should complete.
    • Read inspection.md and replace the ${item} substitutions with the answer.
    • This exercise also serves as a quick introduction to some Markdown basics.
  6. Copy crazy_turtle/crazy_turtle/crazy_turtle/mover.py to $ws/$src/homework1/mover.py. 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 control a turtle in turtlesim to follow waypoints, while tracing it's path. Each step in this section can be viewed as a milestone where it would be appropriate to commit to git and merge into main. You can (and should) add additional commits when appropriate.

Package Setup

  1. The turtle_control package is an ament_python package and should be located at ${ws}/src/homework1/turtle_control
    • This package has exec_depends on rclpy and turtlesim
  2. The turtle_interfaces package is an ament_cmake package and should be located at ${ws}/src/homework1/turtle_interfaces
  3. Use ros2 pkg create to create the packages.
  4. Edit package.xml to change the default but required fields to reflect your name, email, and a description of each package.
  5. As you develop the package make sure to maintain consistency with package.xml and add any extra dependencies as they are needed.

Waypoint Node

  1. Create a node called waypoint that (for now) logs a DEBUG message that says "Issuing Command!" at a fixed frequency using a timer.
    • This node will be expanded throughout this assignment and will form the base of the project.
    • The frequency should be specified as a parameter called "frequency" and should default to 90 Hz.
    • You will only see DEBUG messages when the node is run in a mode that enables the DEBUG logger level.
  2. Make sure you can run the node with ros2 run

Hints

  1. First make the node work using a hard-coded frequency, then add in the parameter.
  2. You need to set the logger level when running the node to see DEBUG messages.
  3. To test if your code is working without setting the logger level, use an ERROR message at first and later change it to DEBUG.

Toggle Service

  1. Using the std_srvs/Empty Service type, create service called toggle and have the waypoint node offer it.
    • The node will now have two states: MOVING and STOPPED. It starts in the STOPPED state.
    • When toggle is called, the node switches states.
      • When switching from MOVING to STOPPED the node INFO logs "Stopping." one time.
      • While in the "MOVING" state, the node DEBUG logs "Issuing Command!" repeatedly
      • While moving the turtle should leave a visual trail behind to show where it has been
  2. Your code should not attempt to stop the timer or create multiple timers: instead it should change what the timer is doing based on whether the state is MOVING or STOPPED.

Load Waypoints

  1. Create a custom service of type turtle_interfaces/srv/Waypoints in the turtle_interfaces package that allows you to send an arbitrary number of waypoints to a node and responds with the total straight-line distance that the turtle will travel to complete one cycle of the waypoints (i.e., starting and ending at the same place).
    • The fields in this service are defined as follows:
    • The request has a waypoints field that is an array of geometry_msgs/msg/Point objects. The z field of the point is ignored.
    • The response is a distance of type float64
    • Do not forget to update the package.xml and CMakeLists.txt as needed for the turtle_interfaces package.
  2. Add a service called load of the turtle_interfaces/srv/Waypoints type to the waypoint node. This service shall:
    • Reset the turtlesim node to its initial state.
    • Draw an X at each waypoint.
    • Place the turtle at the first waypoint. The node should be STOPPED and turtle should not move.
    • Compute the straight-line distance from traversing the waypoints and return that as a response.

Hint

  1. The turtle is able to "teleport". Teleportation can be used to draw the X but not to follow the waypoints
  2. See Blocking Calls for a useful pattern that enables calling "teleport" sequentially, while waiting for each step to complete.

Position Feedback

  1. Subscribe to a turtlesim topic that provides the position and orientation of the turtle.
  2. This subscriber should store the received data for later use
  3. The subscriber should not publish any messages or call any services.

Command Publisher

  1. When the toggle service puts the node into the MOVING state, the turtle should start following the most recently loaded waypoints.
    • If no waypoints are loaded log an ERROR message saying No waypoints loaded. Load them with the "load" service.
  2. When MOVING, you should publish cmd_vel commands at the control loop frequency.
    • The cmd_vel velocities must have linear.y = 0 to emulate a differential-drive robot.
  3. If the turtle is STOPPED (by another call to toggle) it should stop moving.
    • Resuming (by another call to toggle) should have the turtle continue along the waypoints.
  4. A turtle reaches a waypoint if it is within some threshold distance of that the waypoint
    • This threshold should be set via a tolerance parameter

Hints

  1. Before working on the control algorithm itself, publish a constant command velocity
    • Verify that the turtle moves
    • use ros2 topic hz to verify the frequency

Distance Estimate

  1. Create a custom message type called ErrorMetric in the turtle_interfaces package that contains 3 values:
    • complete_loops: An integer counting the number of times the turtle has cycled through all the waypoints.
    • actual_distance: The actual distance traveled (this can be estimated as a linear interpolation between position feedback subscriber callbacks).
    • error: When a loop is completed, compute the difference between the straight-line distance of the path and the actual distance traveled.
  2. Publish this message on the /loop_metrics topic every time the turtle completes a new cycle of the waypoints.
    • In this sense, the ErrorMetric is only updated once per full cycle.
    • The actual_distance and error are cumulative (i.e., if the turtle has completed 3 loops this is the actual distance traveled for the 3 loops and the error over that time).
  3. All metrics should be reset whenever the /load service is called.

Launch File XML

Write an xml launchfile called waypoints.launch.xml (put it in the launch/ directory of the turtle_control package). The launchfile should:

  1. Start the turtlesim_node and the waypoint node.
  2. Load parameters from colors.yaml (stored in the config/ directory of the turtle_control package) to set the colors of the turtlesim_node.
    • The color you set should be visually distinct from the default value (e.g., it should not primarily be a shade of blue).
  3. Specify the following parameters for waypoints
    1. frequency should be 100 Hz
    2. tolerance should be, at most, 0.05m

Hint

  1. Don't forget to install the launchfile or config files using setup.py

Example Run

In the example run:

  1. The turtle traverses the following waypoints: (1.4, 1.6), (2.2, 9.4), (7.2, 6.1), (4.0, 2.6), (8.2, 1.5), (4.1, 5.3)
  2. You stop and resume the turtle one time.
  3. The turtle completes more than 1 but less than 2 cycles.
  1. Capture a screen-cast and a ros2 bag capture of /turtle1/cmd_vel while performing this experiment.
    • Save the bag to homework1/turtle.bag and be sure to include it in the git repository
  2. Manually reset the turtlesim and kill the waypoint node.
  3. Use ros2 bag to play-back the bagged data to make the turtle move. Describe what happens in the README.md

README

In the base directory of your repository (e.g. homework1) create a README.md using the following template (be sure to update the ${} with the answers.)

# ME495 Embedded Systems Homework 1
Author: ${Your Name}
1. Use `ros2 launch ${pkg} ${launchfile}` to run the code
2. The `${ros2 service call /load <put arguments here that you used to make the video>}` service loads waypoints for the turtle to follow
3. The `${ros2 service call /stop <put arguments here that you used to make the video>}` starts and stops the turtle.
4. Here is a video of the turtle in action.

   ${embed video here, must show up inline in the README.md when rendered on github. Video file itself should be uploaded as a github issue and linked here, not in the repository}`

Video Upload Instructions

  1. To upload a video:
    1. Create a github issue on your repository, and attach the file to the issue.
    2. The video will then have a github link. Placing that link in the README.md will embed the video.
      • The video link must be on a its own line in the README.md. with a blank line preceding it.
    3. The video must play properly when viewing your README.md on GitHub in order for it to count as having been submitted.
  2. The directory structure of your git repository should look like
    • homework1
    • homework1/inspection.md
    • homework1/README.md
    • homework1/turtle_control
    • homework1/turtle_interfaces
    • homework1/mover.py
    • homework1/turtle.bag
    • homework1/citations.txt
    • homework1/rosgraph.svg

Author: Matthew Elwin.