Exploration 3: RPS & Data Logging

Autonomous vehicles cannot rely too heavily on one system to achieve autonomous navigation.  Robot Positioning system (RPS) provides the robot another way to navigate by providing its position on the course, and the purpose of this exploration was to explore how RPS can aid in navigating the robot and to collect data from RPS for processing.

Some equipment used in this exploration was the Crayola Bots powered by the Proteus, QT Creator, and MATLAB.  To begin, the group mounted the QR code to the top of the robot.  Next, a program was run that initialized the RPS menu, enabled the RPS, and printed the RPS data to the screen.  Four locations on the robot course were then tested to determine their RPS position.  Next, an RPS shaft encoding program was implemented that tested the robot’s ability to navigate to precise RPS positions and headings.  Next, the data logging program was downloaded on the Proteus, and this program saved robot positions as the robot moved around the course to a data file on a SD card.  A MATLAB code was written to plot the RPS positions from the data file onto a picture on the robot course.  Lastly, the program that determined the RPS position of the 4 points was modified to write the location of the points to the SD card.

This exploration provided the group with many useful observations about RPS.  First, its inconsistency was shown when it stopped working on four of the courses during the exploration.  Another issue was high robot power caused the robot to continuously overshoot the desired RPS position.  Another issue was after the robot reached 359 degrees and rotated one more degree it was at 0 degrees.  This was counteracted by changing the code so that if the desired angle was 0 and the angle was between 180 and 359 degrees, the robot would turn right, increasing its angle until it reached 0 degrees.  The inconsistency with RPS is the main reason it can’t be the main source of navigation.  RPS can be used to check positions for the robot and as a backup plan if the shaft encoding fails.  However, there must also be a non-RPS version of the code if the RPS is not working.  Data logging can be useful in trying to make the robot more consistent because seeing how each run deviates from others will be great in determining the variations and trying to eliminate them.  To mount the QR code the group plans to use two erector set pieces that will be screwed to the chassis.  A plastic platform can be 3D printed where the QR code can be placed.

RPS provides the robot another way to navigate and can be used to complement shaft encoding for navigation.  However, there are many errors associated with RPS including overshooting desired positions and inconsistent readings.  These errors can be fixed by not using the RPS as the primary source of navigation and decreasing the motor power when using RPS.