Gate ReviewClick here for updated MSD 1 Gate Review documents.
- What does the team plan to accomplish by the Detailed
- Finish designing LiDAR odometry and LiDAR localization.
- Research and design navigation upgrades (path planning and following).
- Research and design obstacle avoidance upgrades.
- Finish design of converter current issues and fuse block install.
- Create test plans for the Engineering Requirements.
- Create Bill of Materials.
- Finish GUI design plans.
- Design 12V charging upgrades.
- What tasks have been accomplished so far?
- Finished design for fuse and ground block.
- Finished GUI design plans.
- Made upgraded monitor choice and got approval for the necessary funding to purchase.
- Finished designing and testing feasibility of LiDAR odometry.
- Finished designing and testing feasibility of LiDAR localization.
- Finished design of navigation (path planning, following and obstacle avoidance).
- Created test plans for the Engineering Requirements.
- Test feasibility of AMCL localization.
- Created Bill of Materials.
- Created Issues Register.
- Updated Risk Register.
- Created schedule for MSD II.
- What tasks remain, and who is the owner of each?
- Test navigation feasibility. Ryan and Gio own this.
- What decisions have been made so far?
- Chose navigation stack to do global and local path planning and following.
- Chose LiDAR as our primary odometry source.
- GUI and monitor choice.
- Upgraded wheel encoders will be used as the primary odometry source outdoors.
Detailed Design and Feasibility
- The need for better odometry can most easily be seen using the RViz tool to visualize the real time odometry data. The first image shows both the standard odometry messages in yellow and the fused IMU messages in green, mentioned later in the document. During this test the cart was driven in remote mode under the 5 mph speed limit. The carts driver side front wheel was lined up to a mark on the pavement. The cart is driven around the three flower beds seen in the second image, the star represents the starting and ending location of the path. It is evident here that the odometry data even in just one lap of the track cannot provide a good position estimate.
- Another predominant reason for improving the odometry source is the suspected mechanical slop in the system causing measurement errors. This effect can be seen at the arrow in the first picture, where the steering wheel was moved without the angle of the steering system of the cart changing. A straight path is maintained on the ground, but the path the odometry reports the curve seen below.
- Reasons for this Module
- This IMU communicates to the computer via a USB to UART converter. This is built into the cable and removes the noise issues experienced by phase 3.
- This IMU provides preprocessing and filtering that outputs a yaw, pitch and roll as a ROS message, in addition to allowing access to the raw values.
- There is an existing ROS node to bring the data from the IMU into the ROS system allowing the high compatibility.
- This IMU was under $100 and was donated by D3 Engineering.
- Other units had less robust interfaces that were more susceptible to noise and lacked some compatibility.
- Feasibility of IMU
- The IMU was recommended from a member of D3. We therefore believe it will output better data that is useable compared to the previous IMU. The data can to be fused with the GPS and was intended to work with the motor and steering encoders. The team has not yet implemented the full GPS IMU fusion with a covariance matrix. Even if we did, there is no guarantee that it would improve the odometry to the point where it was usable due to the unreliable encoders that are currently being used.
LiDAR Odometry Design
- The LiDAR odometry system works by matching laser scans from different instances of time.
- It uses key frames to speed up the process until the robot has moved far enough to take another key frame.
- The system has the potential to be as accurate as the LiDAR (3 cm distance accuracy) and is less prone to the time based drift that is incurred by measurement error in wheel based odometry systems.
- The ROS software layer diagram for the new odometry system can be seen below.
Feasibility of LiDAR Odometry
- The system was tested indoors and outdoors as seen in
the pictures below.
- Outdoor test failed to prove feasibility, the picture below was from the standard loop test that was performed for the standard odometry. The cause of this failure is being attributed to the bad interaction between the wheel encoder odometry and the LiDAR odometry. There can only be one publisher of the transform. Also outdoors is not feature dense enough for it to work successfully. Even when the APM was started near a landmark that was feature dense, once it moved away from it, the odometry was entirely unusable.
- The indoor test was performed on the senior design floor without the normal odom publishing. This test of the system produced very good results for feasibility of LiDAR odometry. It is important to note how feature dense the environment is containing many chairs, desks, and walls. The zig-zag is the team pushing the cart back and forth, K-turning it to get back in the cubicle. It did not return exactly to where it started but no provisions for marking the location were made in this test. There were also people often directly in front of the LiDAR.
- From these tests we have chosen to prioritize new encoders as our primary source of odometry. We will also add the IMU after.
- Examples of other projects using only LiDAR to create
accurate odometry with ROS packages publicly available:
- Erle Rover uses the scan_tools package, specifically laser_scan_matching on a similar (Ackermann) vehicle.
Wheel Encoder Design
- Initial designs can be found at Preliminary Detailed Design#Odometry Encoder Upgrades.
- Minimum Acceptable Encoding Resolution
- The general answer to this question is as high as possible. Most robotic platforms push the number much higher than needed by encoding at the motor shaft usually through a gearbox, this is unfeasible for this use case because the gearbox and differential are the major factors that make the odometry unreliable.
- Assuming the magnet and hall apparatus, the maximum number of magnets that can be achieved on the rim of the wheel is 200. With a single latching hall effect sensor there will be 200 usable edges per wheel revolution. To obtain direction information of the wheel a minimum of two sensors are needed with 90 degrees of phase offset between them. This has the added advantage of doubling the number of edges per revolution to 400. As a protection in case there is not enough data to accurately resolve the position of the cart, there will be an extra 2 mounting locations for sensors. This yields 800 tick per revolution.
On Board Storage
Feasibility of storing the necessary LiDAR maps
- 120 GB drive, 63 GB free, 32 GB used by non-OS files, Remaining storage used by OS and core system functions
- Currently, a route from the Pi Quad to Simone Circle, around the Bike Path, and back to Pi Quad has already been recorded. This raw data resulted in a 5GB file prior to any optimization. Once turned into a proper mapping file, as long as the points are located inside these bounds, the size of this file should not increase by a large margin. Using these values, we can approximate that the maximum size required by the LiDAR mapping system will be at most 6GB. This amount takes up just under 10% of our free storage.
DesignThe 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.
FeasibilityThe 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.
Map Generation / Saving and Reusing
DesignThere 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.
FeasibilityAn example hand generated map can be seen below, generated from the satellite imagery in google maps.
A preliminary test of the SLAM system can be seen below.
Map Saving and ReusingIn 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.
Also a SLAM generated map can be saved from the system and then reloaded into the system at a later time.
Brake Sensing Feasibility
- Please refer to the Preliminary Detailed Design#Brake Switch Upgrades for the design info
- This proximity sensor was tested during the feasibility of the new encoder upgrade prototyping. We are very confident that the sensor will appropriately sense the brake linkage bolt. We are also confident that the computer will be able to accurately read the signal because it will be essentially the same circuit as the current estop button.
- We are planning on purchasing a similar proximity sensor with a more compatible voltage range.
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.
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.
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.
- Starting position, starting orientation, destination position, cost map
- A list velocity commands compatible with the current robot's control system
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
- Prior Knowledge
- The last team's path planning was not autonomous, but lends knowledge towards path planning and path following which are best designed in tandem. The APM would receive a list of coordinates which were mapped out manually by the team. The APM would then follow the points. This implementation worked moderately. It would function well at the beginning of the test, but as the error in position due to poor localization propagated throughout time, the AMP would lose track of where it was as it tried to follow the given path. This uncertainty caused it to wobble on its path. However, this testing does show that if the error in the system is low, their planning method and path following algorithms will work. We believe their algorithm can be used because it was specifically designed for the cart. It will require some modifications to switch it from world frame to odom frame. We have not documented this ourselves. Their work can be seen here.
Path Following and Obstacle Avoidance DesignThe 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 FeasibilityDue 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.
Current Path Following Ability
- The current path following algorithm already is able to stop when it gets within a certain radius of the final path waypoint. This has not been tested, confirmed or documented. Phase 3 failed this ER because of problems with their GPS and autonomous.
- Currently the system has software modules available that can automatically e-stop to avoid static obstacles. Phase 3 test results on worksheet S9 specifies this. It is not confirmed if this functionality works because of the removal of the ultrasonic sensors to ease the mobility of the cart in the elevator. We do not plan to test or use the auto e-stop functionality because of the removal of the ultrasonics.
- There is a basic obstacle avoidance system implemented using the LIDAR to divert around a static or dynamic object while autonomously navigating. We have tested and confirmed this as working for static objects. Here is a link to the previous phase demonstrating this.
- At a minimum, an attempt will be made by the APM to avoid dynamic obstacles as of current. This being said the dynamic obstacle can be moving at a range of velocities not all of which are feasible for the cart to avoid.
- The cart has currently only been tested with slowly moving obstacles (walking speed people). This is marked “should” in CR5. We have not researched new any solutions for dynamic obstacles avoidance. Further work on the subject will be considered time permitting.
Fuse Block DesignA portion of the design document can be seen below. Click here for the full document.
GUI UpgradesAs 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.
Design and Flowcharts
ROS Software LayerThis is the entire ROS software layer diagram. here for the entire document.
Bill of Material (BOM)here for the entire Bill of Materials. here for the Purchasing Log.
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.
Unless otherwise specified, all other purchases will be submitted through the PICS system.
Test Plans and Engineering Requirements
Test PlansClick here for the entire document.
Engineering Requirementshere for the entire document.
Risks and Issueshere for the entire document. here for the entire document.
Data SheetSome updates have been made to the Data Sheet. More tests will be completed. here for the entire document.
Future PlansClick here for the current Project Schedule.
Plans for the rest of this semester
- Finish testing the global planner package
- Order parts on the Bill of Materials
- Begin new encoder hardware, software and electrical
Plans for MSD II
- Completed by Build Prep Review around 2/1/17:
- All parts orders delivered.
- New encoder odometry installed and tested.
- ROS and Linux rebuilt, updated and new launch files and scripts created for efficient software development.
- New monitor installed.
- Fuse and ground block installed.
- Completed by Subsystems Review around 2/22/17:
- Preliminary implementation of AMCL, cost map, carrot planner and local planner software packages.
- AMCL and cost map software packages tested and complete.
- ER test plan #6 complete.
- Completed by System Review around 3/23/17:
- New brake switch and mode switching software.
- E-stop fixed
- Cost map, carrot planner and local planner software packages tested and complete.
- GUI updates.
- ER test #7, 8, 10, 11 and 12 complete.
- Completed by Final Customer Demo around 4/11/17:
- ER test #2, 3, 4, 5 and 9 complete.
- Completed by Customer Handoff Review around 5/3/17:
- Final documentation.
- Imagine RIT Festival 5/6/17
- Gate Review around 5/16/17