P17241: Autonomous People Mover IV
/public/

Detailed Design

Table of Contents

< back to home page

Gate Review

Click here for updated MSD 1 Gate Review documents.

Progress Report

Detailed Design and Feasibility

Current Odometry

Odometry test

Odometry test

Odometry test area

Odometry test area

IMU

Improved Odometry

LiDAR Odometry Design

Odometry ROS Software Layer - Rev A

Odometry ROS Software Layer - Rev A

Feasibility of LiDAR Odometry

Outdoor LiDAR odometry test (low feature density)

Outdoor LiDAR odometry test (low feature density)

Indoor LiDAR odometry test (very accurate)

Indoor LiDAR odometry test (very accurate)

Wheel Encoder Design

On Board Storage

Feasibility of storing the necessary LiDAR maps

Localization

Design

The plan for localization was to take the map of the operation area and use a ROS node to match a laser scan into that map. This can be done through the use of a particle filter. The particle filter will probabilistically determine the most likely location of the cart in the given map. It is an iterative filter that can be aided with the additional information of the initial position of the cart to lower the number of iterations that it takes the filter to converge on the location of the robot.
Localization ROS Software Layer - Rev A

Localization ROS Software Layer - Rev A

Feasibility

The amcl package takes a map, laser_scan, an initial pose, and uses the robots tf frames to provide an output pose of the robot within the provided map. The package has been tested with another robot that is able to generate proper odometry and therefore a map. The testing proves that it is feasible for the team to localize into an existing map of the operating area once proper odometry has been achieved. Due to the use of the pointcloud_to_laserscan node and the complex outdoor environment it is hard to hand generate a map that is close enough to what the cart will see in real life. This makes the final amcl testing dependent on the odometry.
AMCL algorithm output, mapped area is on the senior design floor with another robot platform

AMCL algorithm output, mapped area is on the senior design floor with another robot platform

Map Generation / Saving and Reusing

Design

There are two main ways that maps can be generated. The first way is to take an actual satellite or road map and mark it up using a photo editor. A gray scale image can be used to indicate the difference between free and occupied space in the occupancy map. There is a configuration file that accompanies the image to tell the ROS system where the image resides in space and the physical dimensions of a pixel.

The second way is to generate the map of the operating area with a SLAM package. The SLAM package will create a map using the odometry and laser scan data on the cart. This will result in a map that is of the same format mentioned above.

Map Generation ROS Software Layer - Rev A

Map Generation ROS Software Layer - Rev A

Feasibility

An example hand generated map can be seen below, generated from the satellite imagery in google maps.
Original satellite data

Original satellite data

Hand generated map of the operating area

Hand generated map of the operating area

A preliminary test of the SLAM system can be seen below.

Preliminary map generation of the SLAM system

Preliminary map generation of the SLAM system

Map Saving and Reusing

In both cases a provision for saving and loading maps is needed. The map_server package does this exact function and was the first package that was investigated for the task. It proved to be easy to use and worked for our use cases. A simple computer drawn map was generated in a photo editor and was loaded into the ROS system. A hand generated map that was loaded onto the cart can be seen below.
Source map to load

Source map to load

Source map loaded into ROS

Source map loaded into ROS

Also a SLAM generated map can be saved from the system and then reloaded into the system at a later time.

SLAM generated map in ROS

SLAM generated map in ROS

SLAM generated map saved to a PGM image file for later use

SLAM generated map saved to a PGM image file for later use

Brake Sensing Feasibility

The following image shows the general overview of how the Navigation Stack works. The Stack itself takes in a transform,odometry, occupancy map, pose stamped, and sensor topics. The output will be the position and direction. This can be used to compare to the way-points that are part of the path plan.

 Navigation ROS Software Layer

Navigation ROS Software Layer

Currently, our research shows that the Navigation stack currently being used has been proven to support functioning path planning plugins. This plugin takes in a costmap on creation. This map utilizes our current map, with the boundaries padded by a predetermined offset. It is automatically generated as a part of the navigation package.

Red lines show the physical location of the walls, while the blue areas are the padding added by the map type.

Red lines show the physical location of the walls, while the blue areas are the padding added by the map type.

The Nav_core package is a rapid interpolation path planning ROS package included with the base navigation package. It is a plugin for the global_planner node, and is responsible for the actual generation of the path. It holds all the packages responsible for the global planner, responsible for the overarching path plan, and the local planner, responsible for reorientation and other small scale path fixes.

Upon running, nav_core takes in a start and goal pose, containing exact locations and quaternion, located within the costmap plane. It runs these points through the global_planner, and generates a "plan", or an array of poses which convert to the path.

This plan is then fed into the local_planner along with the laser scans, and is then given velocity commands in return. These commands will be transformed through custom code into a format compatible with the APM's control system, and then fed into said control system allowing the robot to move.

An alternative method for path planning was originally considered, following tutorial on the navigation package wiki. However, this method ran into a few issues referenced below.

First of all, the tutorial only gives a basic framework for a global planner. It included no actual algorithm to use, expecting you to provide your own. It did not include any local_planner, which would handle small scale error corrections. Most importantly, this method was only needed if the user was to use their own custom algorithm.

Upon more research, we decided to use pre-made plugins. These plugins still use a similar framework, however use proven algorithms in a format that has been proven to work. This saves on time that would have been spent planning, generating, and testing an unneeded extra step in the path planning process.

Path Planning Feasibility

Path Following and Obstacle Avoidance Design

The navigation stack's local planner is the node responsible for actually dealing with driving the cart in the presence of obstacles. It uses the global path generated by the global planner, laser_scan and odometry messages to keep track of the environment around it in the local cost map. The default local planner though is not suitable for the Ackerman steering system presented by the APM. The navigation stack allows for the use of plugins for both the local and global planner. This means that a more suitable planner can be used instead. The teb_local_planner is a local planner that has support for Ackerman drive vehicles.

Path Following and Obstacle Avoidance Feasibility

Due to the plugin structure of the navigation stack, swapping the local planner out should be straightforward. The teb_local_planner has very good documentation on integrating it with the navigation stack. It also has a few demo launch files so that the performance of the planner can be tested without much implementation. This demo was run and the results show that the planner should be suitable for the APM. Demo, can be seen below running on a standalone ROS system.
 TEB local planner demo

TEB local planner demo

Current Path Following Ability

Fuse Block Design

A portion of the design document can be seen below. Click here for the full document.
Fuse Block Design

Fuse Block Design

GUI Upgrades

As per requests, the preliminary GUI layouts have been updated to replace the LiDAR visuals with a costmap output. This fulfills the requirement of showing a current location on a map.
Revised GUI Mockup 1

Revised GUI Mockup 1

Revised GUI Mockup 2

Revised GUI Mockup 2

Design and Flowcharts

ROS Software Layer

This is the entire ROS software layer diagram.
ROS Software Layer

ROS Software Layer

Click here for the entire document.

Bill of Material (BOM)

Bill of Materials for Phase 4 Only

Bill of Materials for Phase 4 Only

Click here for the entire Bill of Materials.
Purchasing Log

Purchasing Log

Click here for the Purchasing Log.

Procurement Plans

Monitor Update

Due to the nature of the monitor being investigated, the purchase will need to be sent directly to either the manufacturer, or a direct distributor. A contact has been established within the manufacturer for further questions, as well as for submitting the order request when ready.

Other Purchases

Unless otherwise specified, all other purchases will be submitted through the PICS system.

Test Plans and Engineering Requirements

Test Plans

Click here for the entire document.

Engineering Requirements

Engineering Requirements - Rev E

Engineering Requirements - Rev E

Click here for the entire document.

Risks and Issues

Updated Risks

Updated Risks

Click here for the entire document.
Current Issues

Current Issues

Click here for the entire document.

Data Sheet

Some updates have been made to the Data Sheet. More tests will be completed.
Updated Data Sheet

Updated Data Sheet

Click here for the entire document.

Future Plans

Click here for the current Project Schedule.

Plans for the rest of this semester

Plans for MSD II


Home | Planning & Execution | Imagine RIT

Problem Definition | Systems Design | Preliminary Detailed Design | Detailed Design

Build & Test Prep | Subsystem Build & Test | Integrated System Build & Test | Integrated System Build & Test with Customer Demo | Customer Handoff & Final Project Documentation