Requirements of POLARIS and Current Progress

From Lofaro Lab Wiki
Revision as of 12:22, 23 May 2015 by Hshah5 (Talk | contribs)

Jump to: navigation, search

This page is meant to provide those interested in the project with an idea of how far along the development of POLARIS is and what still needs to be done in case future students of George Mason wish to continue it.

Project Requirements

The device is required to be compatible with any generic robot. The device must include a camera component. The camera will be used for computer vision in order to recognize markers on the ceilings of the area where localization will occur. The device is required to have USB 2.0 capability and be able to respond to prompts from the user communicating with the device in order to provide the user with map data of the area or current localization data. It must also be portable to provide for ease of transportation and to prevent weighing down the generic robot it is connected to.

The markers utilized for indoor localization must be non-salient. The non-salient markers must be read by a reliable camera through the use of computer vision. The use of computer vision is necessary to provide a method of acquiring, processing, and analyzing the non-salient markers that are required for indoor localization.

The generic robot that is used for demonstrating a delivery system through utilization of the localization device is required to have a method of command retrieval of user input in order to support the delivery system requested by faculty. The user will give a command to the generic robot and the generic robot must be able to retrieve the command and take action by going to the destination specified by the user. An algorithm for obstacle avoidance is required for the generic robot to have the ability to recognize and avoid any obstructions in its path when the device is applied to a navigating robot for demonstration of the device. The algorithm is required so the robot has the ability to avoid the obstacles by computing an alternative route to its desired destination and adjusting its movement accordingly.

Localization:

Localization device must provide:

  • X-Y resolution within 1.0 m
  • Z resolution within 0.0 floor
  • Theta (yaw) resolution within 1.0 degree
  • Update rate ≥ 5.0 Hz
  • The generic robot with a way to load maps of the area of localization. Maps stored on the device must contain meta data (Including room number and name)


Hardware:

  • Device must be enclosed within case with the George Mason University logo
  • Device must run off of USB 2.0~1.1 bus


Software:

  • All programs used must be open source
  • Wiki documentation must be maintained throughout the project describing how to create the device and how to build it
  • Final product must be Debian Linux compatible


Robot:

  • Must have automated system for ground truth map retrieval (Stretch Goal)
  • Mapping robot must use vSLAM or like system when obtaining map
  • Generic delivery robot must have an interface capable of allowing for command retrieval from user
  • Generic delivery robot must be capable of obstacle avoidance as it is autonomous


Current Progress

The device has a serial communication module that plugs and plays in order to allow for compatibility with generic robots. The serial communication module has not yet been fully integrated into the system as it is not communicating with the localization module yet. The user currently needs to manually run the localization module to obtain location data. The starterScript of the localization module must be called by the script that runs everything when the device is powered and an ach channel must be implemented between the serial module and the localization module in order for the device to be completed with regard to software. The device includes a camera component for computer vision in order to recognize markers on the ceilings of the area where localization will occur. The camera views input in the infrared spectrum to allow for non-salience requirements to be fulfilled. The device has USB 2.0 capability (we chose the ODROID XU3 LITE microcontroller to provide this capability) and is capable of responding to prompts for map data of the area or current localization data through the serial communication module. In terms of weight, the device is reasonably light in order to be carried on a generic robot. However, the device currently does not have portable power sources and is run through AC adapters plugged into wall outlets. Progress has been made in the development of portable power sources for the infrared LED ring of the infrared camera and the ODROID XU3 LITE microcontroller. These power sources have not yet been fully implemented in order to be integrated into the device and therefore the device cannot yet be considered portable.

The markers utilized for indoor localization have successfully been made non-salient according to supervisor desires. The markers are made to appear less noticeable on the white ceiling that they were eventually placed on. The non-salient markers are capable of being read by our infrared camera through the use of computer vision.

At the moment, the generic robot delivery system that will demonstrate the device is not complete. A* navigation has been selected as the method for navigation that the robot will use. A GUI interface will be employed for the user to send commands for where the delivery robot should go. Serial communication command prompts to the localization device from the generic robot are addressed in the serial communication module's API POLARIS Serial Communication Protocol

Localization:

Localization device currently provides:

  • Average X-Y resolution within 1.0 m
  • Z resolution within 0.0 floor
  • Theta (yaw) resolution is provided within an average of 1.0 degree, however we believe our method of experimentation for testing the yaw is faulty due to drift in the control orientation value as time goes by. An IMU must be employed to properly test Yaw and the results we have thus far should not be accepted as the final value.
  • Average update rate on our chosen Single Board Computer (SBC) of 18.6 Hz
  • The generic robot with a way to request maps of the area of localization. The maps do not currently provide meta data.


Hardware:

  • Device is not yet properly branded with POLARIS, LofaroLabs, and GMU Volgenau logos.
  • Device is capable of running off of USB 2.0~1.1 bus


Software:

  • All programs used are open source
  • Wiki documentation of device has been maintained
  • Final product runs on Debian Linux (The SBC we chose runs all software on Debian Linux OS)


Robot:

  • Do not yet have automated system for ground truth map retrieval
  • Mapping robot uses Hector SLAM to obtain ground truth map.
  • Generic delivery robot does not yet have an interface capable of allowing for command retrieval from user
  • Generic delivery robot is not yet capable of obstacle avoidance as it is autonomous