/public/

Integrated System Build & Test

Table of Contents 1 GUI 1.1 Software 2 Mapping 3 Localization 4 Navigation 4.1 Hardware 5 Brake Monitor Sensor 5.1 Mechanical 5.2 Electrical 5.3 Software 6 Energy Monitoring System (EMS) 6.1 Electrical 6.2 Mechanical 6.3 Software 7 Risk and Problem Tracking 8 Schedule 9 Plans for next phase

< back to home page

GUI

A GUI layout, seen below, is nearing completion. Of the functions shown below, the GUI has the ability to:

• Change the control mode
• Send destination information
• Receive battery information (physical hardware required)
• Change and update the images for the travel map (located below the battery bars)

However, one of the major set-backs discovered is the excessive amount of work needed to get the costmap to properly display through rqt. Numerous hours have gone into this, yet nearly no headway has been made.

To supplement this issue, an alternative GUI has been created. This GUI, seen below, has all the same features of the first GUI, aside from the travel map.

This sidebar would be placed next to the RVIZ window, which currently has the capability of displaying any of the maps we need as well as can display the paths taken.

Software

Mapping

Mapping is fully functional. The APM is able to map and location and save the map. Currently an issue exists with curb detection. It is either able to pick up curbs and also pick up some of the ground or it is able to ignore the ground and the curbs as well. There is an old ROS package with no documentation that is supposed to remove the ground without removing the curbs. The package works to a certain extent. It still removes curbs or leaves the ground in about half of the time. Right now this issue is not being focused on since the test area has high walls. These walls allow for good testing of the localization and path planning aspects of the project.

Localization

As of now, localization works well when the APM is not in autonomous mode. The odometry and AMCL both function well together. AMCL is giving accurate results within our test area. When the APM is put into autonomous mode, the APM attempts to follow the plan and the particle filter becomes inaccurate over longer distances. All of the particles spread out quickly and the APM is no longer localized within the map. The reason for the shift in accuracy is unknown. More testing will hopefully shed light on this issue.

Navigation

Both the navigation stack and teb_local_planner are almost fully functional. The APM is currently able to generate a global plan and navigate it without any obstacles in the way. Although it has not yet been tested with obstacles, only an open area. As it moves, the APM gitters from side to side. This is potentially a consequence of the ground being view by the lidar as an obstacle and the obstacle avoidance algorithm trying to evade it. Once the ground removal software is working well, the noise in the path follow should be removed. The next steps will be to navigate around static obstacles (that is obstacles that are not mapped, but stationary within the testing area). After that, reliable curb detection and ground removal will become a priority.

Hardware

The APM is experiencing severe performance issues across the board. When our current software layout is running, 85% to 100% of the CPU is being used. The hope is that by upgrading the PC, the algorithms will run better. This performance increase may give the APM the ability to perform its desired functions with greater reliability. Here are the new specifications for the computer:

• Intel Core i7-6900K 32.GHz 8-Core Processor
• EVGA Micro 2 Micro ATX LGA2011-3 Motherboard
• G.Skill Aegis 16GB DDR4-2400
• Corsair H60 Liquid Cooler

Brake Monitor Sensor

Mechanical

• The Hall effect sensor has been installed. A metal washer was glued to a nut and threaded on the brake rod to increase the detection surface area for the sensor.

The updated brake frame drawing can be found here

Electrical

Software

Software has been written to detect the sensor's change, and send a signal to the control system on the cart. This software also sends the signal to the assorted sub-systems, in an attempt to deal with changes from other sources.

Energy Monitoring System (EMS)

Electrical

• A schematic has been finalized and can be viewed here.
• A full working prototype has not been designed as currently individual components/sensors are being tested.

Mechanical

Software

EMS Arduino software was created, which monitors the current and voltage levels across the two batteries. In addition, the front-end UI has locations for displaying the battery levels. The intermediate publisher-subscriber system is set up for when the system is fully installed onto the cart.

Risk and Problem Tracking

• Update your Risk Management
• Update your problem tracking.

Schedule

Click here for Revision O Project Schedule.

Plans for next phase

---

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