UP | HOME

ME450: Embedded Systems in Robotics

Guidelines

  • The Guidelines provide important important information about coding standards, expectations, and logistical considerations for this assignment.
  • I recommend reading the guidelines both before starting the assignment and prior to your final submission:

Overview

You will be creating a ROS 2 system that enables a simulated turtle to follow waypoints.

Layout

Workspace

  1. ${ws} is your ROS 2 workspace (e.g., ~/ws/hw1). This is NOT a git repository.
  2. ${ws}/build, ${ws}/log, and ${ws}/install are all directories generated by colcon. They are NOT submitted and NOT part of your git repository.
  3. ${hw1.git} is your Homework 1 Git Repository (e.g., ~/ws/hw1/src/${hw1.git}). You submit only ${hw1.git}

Repository

  • ${hw1.git}/citations.txt is your citations file
  • ${hw1.git}/ai_citations is a directory containing any AI related citation material (if needed)
  • ${hw1.git}/README.me is your README.md, based off of the following template (with the appropriate ${} sections filled in)
  • All packages created are direct child directories of ${hw1.git}

Turtle Control

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

  1. Test each piece and make sure it works before proceeding
  2. Commit to git and merge into main upon completion (though you should also add additional commits when appropriate).
  3. Do not create any ROS API elements (e.g., services/topics/etc) other than those specified in these instructions.
  4. For full credit, the turtlesim/holonomic parameter must be false

Packages

To prepare for the project, create the packages that you need.

  1. The turtlecon package is an ament_python package and should be located at ${hw1.git}/turtlecon
    • All nodes, yaml and launch files belong in this package
  2. The turtle_interfaces package is an ament_cmake package that should be located at ${hw1.git}/turtle_interfaces
    • This package holds any custom interfaces that are created.

Waypoint Node

Create a node called waypoint (in ${hw1.git}/turtlecon/turtlecon/waypoint.py) that

  1. Creates a timer that runs at a fixed frequency based on a parameter called frequency that defaults to 100 Hz
  2. Logs a DEBUG message from that timer that says "Issuing Command!" for each iteration of the timer
  3. Once the timer is setup it should run until the node is terminated.
    • Do not attempt to stop the timer or create multiple timers

Corrupt Node

Create a node called corrupt (in ${hw1.git}/turtlecon/turtlecon/corrupt.py) that

  1. Subscribes to a topic called pure_cmd_vel of type geometry_msgs/msg/Twist
  2. For every pure_cmd_vel message receives publishes a corrupted version on cmd_vel of type geometry_msgs/msg/Twist:
    • Gaussian Noise is added independently to the linear and rotational velocities
    • The noise is zero mean, with standard deviation proportional to noise_coefficient * |velocity|
    • The noise_coefficient is a parameter that defaults to 0.05

Toggle Service

  1. Using the std_srvs/Empty Service type, create a 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 at the control frequency

Load Waypoint Service

Service Type

  1. Create a custom service of type turtle_interfaces/srv/LoadWaypoints that allows sending a sequence of waypoints to a node
    • The Request contains a field called waypoints that is an array of geometry_msgs/msg/Point messages.
      • The z field of each point is ignored.
    • The Response is a field called distance of type float64 with the total straight-line distance the turtle travels if it starts at the first waypoint, visits each waypoint in sequence, and returns to the start.

Service Server

Add a service called load of the turtle_interfaces/srv/LoadWaypoints type to the waypoint node. This service shall:

  1. Reset the turtlesim node to its initial state.
  2. Put the node into the STOPPED state
  3. Draw an isosceles triangle at each waypoint such that
    • The triangle points toward the next waypoint in the sequence.
    • The centroid of the triangle indicates the exact waypoint location and is marked with a dot
    • Drawing should be accomplished by exclusively using services
  4. Place the turtle at the first waypoint, pointing toward the next waypoint
  5. Compute the straight-line distance from traversing one complete cycle of the waypoints and return that as a response.

Turtle Position Subscriber

  1. to the appropriate turtlesim feedback to receive the position and orientation of the turtle
  2. Use the data received to track the actual distance traveled
  3. The data from this subscriber will be used when computing error metrics and (optionally) for control.

Control Publisher

  1. When the toggle service puts the node into the MOVING state, the turtle should start traveling between the waypoints.
    • If no waypoints are loaded log an ERROR message saying No waypoints loaded. Load them with the "load" service and keep the state as STOPPED.
  2. 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.
  3. 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 to the node (defaults to 0.05)
  4. The turtle's path should be visible when following the waypoints
  5. You may use data received

Distance Estimate

ErrorMetric Message Type

  1. Create a custom message type called ErrorMetric in the turtle_interfaces package that contains:
    • complete_loops: An integer counting the number of times the turtle has cycled through all the waypoints.
    • actual_distance: The actual distance traveled
    • error: The difference between the straight-line distance of the path and the actual distance traveled.
    • time: The total time that the turtle has been moving

Publishing ErrorMetrics

  1. Publish an ErrorMetric 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).
    • The time is also cumulative. It should use the time according to rclcpy and when the turtle is STOPPED time does not accumulate.
  2. All metrics should be reset whenever the /load service is called.
  3. Your goal is to implement a control with the error metric as small as possible.

Launch File XML

Write an xml launchfile called ${hw1.git}/turtlecon/launch/waypoints.launch.xml that

  1. Starts the turtlesim_node, waypoint and corrupt nodes.
  2. Loads parameters from ${hw1.git}/turtlecon/config/colors.yaml 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 0.04m
  4. Specify the following parameters for corrupt
    1. noise_coeffient should be 0.04
  5. The waypoints node cannot publish directly to the turtlesim_node. Instead, it's output must be routed through the corrupt node.

Example Run

You should capture an example run, according to the following instructions:

  1. The turtle traverses the following waypoints: (3.8, 5.5), (1.4, 1.5), (2.3, 9.4), (7.1, 6.1), (4.0, 2.7), (8.1, 1.5)
  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 ${hw1.git}/turtle.bag and 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.
    • Capture a screen-cast of the turtle moving based on bag data.
    • Do not expect the bagged run to duplicate the actual run!

README

Here is a specific template for this homework's README.md

# ME450 Embedded Systems Homework 1
Author: ${Your Name}

## Overview
A waypoint following project for ROS 2

## Instructions
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.

## Videos
4. The turtle in action. The error was ${error_metric} meters after one cycle and the cycle was completed in ${time} seconds

   ${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}`

5. Here is a video when the bag is played.

   ${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}`

Author: Matthew Elwin.