Autonomous Robotic Vehicle Design Written Report

Khalid Mutlaq Al-Zayed

OmniBot

EEL 4665/5665

Intelligent Machine Design Laboratory

Instructors: A. Antonio Arroyo, PhD Eric M. Schwartz, PhD

Teaching Assistants: Joshua Weaver

Andy Gray Nick Cox

Daniel Frank

Table of Contents

Abstract .......................................................................................................................................... 3

Executive Summary........................................................................................................................ 4

Introduction .................................................................................................................................... 5

Integrated System ........................................................................................................................... 6

Mobile Platform ........................................................................................................................... 11

Actuation ...................................................................................................................................... 14

Sensors ......................................................................................................................................... 16

Behaviors ..................................................................................................................................... 17

Conclusion ................................................................................................................................... 18

Documentation ............................................................................................................................. 19

Appendices ................................................................................................................................... 20

Abstract

OmniBot is an autonomous robotic vehicle (ARV) implementing omnidirectional motion using mecanum wheels. Each mecanuum wheel will require its own gearing, motor, controller, and possibly encoders, all running off the same 12V source. The sensors and motor system will be driven by an Epiphany board utilizing an Atmel ATXmegaA1U chip. The obstacle avoidance system will at least comprise of an array of sonars – possibly mounted on a servo pivot – in conjunction with some surrounding bump and/or flex sensors. An accelerometer, and magnetometer should be able to provide enough localization capabilities. An XBee or other form of wireless communication module should be included in order to extend functionality in the future.

Implementing the mecanum wheel system imposes a variety design constraints/problems. Since every wheel must be driven and mounted separately as well as carry a significant load (the battery) the vehicle itself is quite large. The size of the robot will make obstacle avoidance in all directions more challenging and complex. The omnidirectional system will allow for complex movements and navigation. This will be beneficial in congested environments as well as an interesting system of locomotion to experiment with both technically and visually. Furthermore, the necessary design of the chassis will allow for the robot function as a mobile platform for a variety of functions/extensions.

Keywords: Autonomous, Mecanum, Omnidirectional.

Executive Summary

The primary goals for this project were twofold. The first was to construct a mobile platform capable of carrying large loads with omnidirectional translation capabilities. The second was to provide the platform with the ability to navigate an environment autonomously. The first objective was accomplished completely while the second objective was left with a lot of room for improvement.

The mobile platform was constructed using parts fabricated from aluminum composites. These parts include, but are not limited to; the mecanum wheel plates, hub caps, transmission housing, gears, screws, bolts, hex bars, exterior mesh and mounting brackets. Any parts that required machining were modified by use of hand tools or a dremel. These parts were required to insure the structural integrity of the platform for mounting the mecanum wheels too. Each wheel was rated for an individual load of 80lb. The distributed weight tolerance of the entire platform is approximately 400lb while still being able to achieve omnidirectional movement. This was tested up to load of 340lbs (there wasn’t enough space for more than two people to stand on the platform safely). Each wheel is powered by a 2.5” CIM brushed motor controlled by a Talon SR speed controller.

The autonomous behaviors rely exclusively on the array of eight sonar sensors with four of them mounted to servos. These sensors, in their 360 degree coverage configuration, allow OmniBot to control the mecanum drive platform in a variety of ways. Omnibot can choose to move in the direction of the farthest obstacle while using the distance as an input to control translation speed. Depending on the orientation of the sonars, either obstacle avoidance or wall detection is utilized. When these few behaviors are put into a recursive algorithm then OmniBot has enough information to navigate a very simplistic maze. These behaviors will continue to require tweaking but given the appropriate initial conditions OmniBot can achieve this task.

Introduction

OmniBot is meant to be an autonomous robotic vehicle (ARV) whose intention is to be

able to navigate environments based on obstacle avoidance and mapping of surroundings. It

features mecanum wheels to accomplish omnidirectional movement. Multiple sonar sensors were

utilized to implement the obstacle avoidance system. This ARV should be able to relay sonar

information to a laptop while navigating its environment.

There are many forms of mobile platforms available for various drive trains. Tank or

holonomic drive trains are a couple of others. Mecanums are a relatively under used solution for

omnidirectional translation mainly due to the large amount of overhead required. However, for

many applications have great benefits. Some of their applications are in warehouses, loading

docks, or electric wheel chairs. Also, they look very impressive when moving. Thus this was the

system chosen for this project to revolve around. The first goal was to create a mobile platform

with a large load tolerance able to realize these complex movement patterns made possible by

the mecanum drive train.

The system is constructed and implemented in software to be as modular as possible. The

mobile platform has two modes. Manual and autonomous control of the platform was

implemented to demonstrate different aspects. The autonomous features were intended to

demonstrate some the ease of navigating tight environments when omnidirectional motion is

possible. A simple maze will be constructed for testing and sonar data is also relayed to a laptop

to attempt to create images of the environment at each stage of decision making.

Integrated System

The integration of the multiple systems is accomplished using an Atmel ATXmega128A1U 16bit microprocessor mounted on the Epiphany DIY development board (shown below). The board is equipped with two voltage regulators to deal with maintaining 3.3V

and 5V signals. The 3.3V regulator is located at the center of the board. The 5V regulator is shown on the top right side. It was added to provide the 5V of power to the servo rails which was not included in the basic kit. When attached to the chassis the board is powered by a 12V marine cell battery. The motor package, shown on the top left side of the board, was not added to the board for this project. The overview of the break out board features from the providers’ website is shown below. A link to the out of the box robotics website is in the resources section of the appendix. Figure I.1 shows a general figure of how the electrical systems are connected to the board.

Four timer type 0 PWM channels from Port F control each of the Talon SR speed controllers. Figure I.1 shows which channel was allocated for each of the respective motors. The Talon SR takes a 0.9ms-2.0ms PWM signal at a frequency of 333Hz as an input. Each controller is wired in parallel to the 12V marine cell battery. The controller regulates the voltage applied to each of the 2.5” CIM brushed motors. This provides a linear output response from each of the motors.

The Talon SR Speed Controller is shown above and its specifications to the left.

Each of the motors is mounted to the transmission housing with its own gearbox and a 500key output shaft. The gearboxes and their housing were chosen to provide a large weight tolerance. The output of each gearbox drives each of the mecanum wheels. Both the transmission system and mecanum wheels are shown to the right. Mechanical specifications of the system are covered in greater detail in the Mobile Platform section. In order to implement omnidirectional movement with mecanum wheels a set of two right oriented wheels and two left oriented wheels is required. The implementation and control algorithms for the mecanum wheels are covered in greater detail in the actuation section.

Two types of ultrasonic range finders were used for obstacle avoidance and wall detection. An image and an overview of their specifications are shown above. Four of each of these were purchased. The HC-SR04 used a four pin configuration which added a layer of complication when wiring it. These sonar sensor featured a wider detection angle then the parallax PING))) sensors. The HCSR04s were mounted to servos at each of the corners of the mobile platform. The PING)) sensors were fixed in place on the front, back, left and right sides of the mobile platform. The PING))) ultrasonic range finders have a very narrow detection band and were better suited for fixed point range finding. Sensor and servo mounting is discussed in greater detail in the sensors section.

The HC-SR04 ultrasonic range finder sensors were triggered from the Port E pins and the echo output was received at the upper nibble of pins on Port D. The lower nibble of Port D acted as both the trigger and echo pins for the PING))) ultrasonic range finders. When wiring these sensors and servos the 5V wire was actually wired to separate 5V rails rather than the power rails corresponding to the port pins. The overall configuration is detailed in figure I.1.

Two XBee series 1 modules along with a USB adapter were used to implement wireless communication between the robot and a laptop. The Xbee module is shown tabove and the USB adapter is shown to the right of the page. The wireless modules allow for the mobile platform to be controlled manually for testing or so that OmniBot can transmit environment data to be stored on the laptop. Initially the laptop would have been used to also process the sensor data for decision making. The Epiphany DIY has a break out section of the board for easy integration of an XBee module as well as prewritten libraries for utilizing the module.

A digital compass and accelerometer unit was purchased to provide drift and bump detection but was not integrated into the final design due to time and mounting constraints. The magnetometer was to synchronize environment data with the direction OmniBot attempted to translate in. The accelerometer would have had multiple functions. The firstfunction being back up bump detection. The second would have corrected for unwanted rotation when attempting to move in a straight line. Any rotation detected would have been passed as an offset to the rotation parameter for driving the mecanum wheels. See the actuation section. The third would have been to regulate the velocity of OmniBot.

Mobile Platform

Mecanum wheels were the projects special system. They were chosen to implement the robots omnidirectional actuation objective. The wheels and transmission mounts were purchased from and machined by AndyMark, a parts provider for the FIRST competition. The 8” diameter mecanums were chosen because of their weight tolerance and high number of rollers. The set and hardware components are

My initial order was delayed a few weeks due to parts being out of stock. The first constructions revealed that extra parts and machining was required. Each of the 48 rollers had to be bored out in order roll around the brass tubes. Extra washers were used to keep the rollers from contacting the wheel plates. If, even one roller gets stuck, the performance of that wheel would be drastically impacted. The horizontal translation ability is entirely dependent on these rollers being able to roll with little resistance thus the wheels would not have worked at all in the state they were originally received in.

Every aspect of this ARV was designed around the effective implementation of the Mecanum drive. The only other mechanical system that would have been desired would have been a suspension system. A suspension system would have ensured that each wheel was always making contact with the ground. Instead two hard frame transmission housings with room for two gear boxes on each were chosen. One of the modules and its specifications are shown at the bottom of the page. The gear ratio was stepped down to 10.71:1 because the availability.

The motors and speed controllers were mounted to the transmission housings directly. ½” Hex bars with small concavitys for weight savings were using to attach the two

transmission housings together. The bars were 30” long and were cut with a hacksaw to the appropriate lengths. The holes on each end were threaded by hand with thread forming screws. Machining these parts was one of the more time consuming aspects of this project. Finding the right size and type of screws that would work proved to be a difficult task. Local hardware stores did not have enough stock or the types necessary. Thus all the screws and bolts used had to be ordered from AndyMark as well. However once all the correct parts were ascertained, and machined, the platform turned out to be very sturdy. The

mobile platform has an estimated weight tolerance of 500lb. This ensured that the 12V battery would be supported and would allow the project objectives while simultaneously carrying loads. The frame was topped with a polycarbonate sheet cut to the appropriate size. The majority of this phase of development was spent machining parts and making sure each of the parts functioned mechanically correctly. Another surprisingly time consuming task was making wires. Getting the wires to the right length with the right connectors was extremely time consuming because they would break easily or there would be conductivity issues.

The exterior design of Omnibot went through several phases of development. Initially, the eight sensors were supposed to be mounted directly to wooden pieces that would be mounted on the frame. Four of the sensors were to be mounted on the front, back, left and right of the frame, and four were to be mounted facing diagonally on each of the four corners. After mounting the wheels to the frame, the robot’s exterior design proved to be an issue. The wheels were so large that attaching wooden pieces on which to mount the diagonal facing sensors would have required building a large wooden cage. After taking measurements and drawing out several different design variations, it was clear that this method would be cumbersome.

At this point a trip to the hardware store was in order to restock on wire, and the opportunity arose to search for a new exterior design. At this point, the “aluminum phase” of development began. Thin aluminum sheeting that could easily be bent into round shapes around the wheels was stumbled upon. The aluminum sheeting was also perforated, which eased the process or mounting the material itself as well as the sensors.

These issues having been resolved, appropriate power tools were procured to cut, shape and mount the aluminum. Once the “cage” was firmly mounted, the sensors were carefully measured and screwed onto the exterior at the eight respective areas. At this point the issue of conductivity occurred. The screws conducted electricity through the aluminum which ran the risk of shorting sensors. Many materials were experimented with; from pool noodle pieces to duct tape. This trial and error process actually led to several other design developments, for instance the pool noodle Styrofoam pieces supporting the sideways facing sensors.

The next obstacles were the apparent blind spots between the observations of the sensors.

To decrease the size of these blind spots as much as possible, the corner sensors were mounted onto servos which rotate 180 degrees. The mounting process itself was extensive and, once again, trial and error based. Eventually the most appropriate design, given the available materials, was attaching the sensor to a measured and flat piece of cut cardboard, and then securing the cardboard to the servo. Cardboard worked best because it was flat on the bottom (enabling the attached sensor to face directly outwards).

Actuation

Mecanum wheels were used to accomplish omnidirectional actuation. The system is composed of two right oriented and two left oriented mecanum wheels. Each wheel is controlled separately by a Talon SR speed controller. The Talon SR takes a 0.9ms-2.0ms PWM signal at a frequency of 333Hz as an input. Each controller is wired in parallel to the 12V marine cell battery. The Talon SR also has a 4% dead band in both directions (forward and reverse polarity – centered at 1.5ms). The figure below shows the relationship between RPM and throttle. This

demonstrates the linearity of the devices which was a crucial aspect to effective control of the mecanum drive train. The Talon SRs provide a convenient means to calibrate the controller. This was done but one of the four controllers always ended up

slightly off. This may be due to wiring or the discharge level of the battery. However this could easily be corrected for in software with the help of an accelerometer. If any of the wheels is unable to accurately reach the desired throttle, relative to the other wheels, then it causes unwanted rotational forces during translation.

The figure to the right shows the wheel direction, relative magnitudes, and the resulting direction of translation for most situations. The first actuation function written allowed for each of the controllers to be set manually by passing it offset parameters.

This was a useful function for testing, calibration and for hardcoding movement patterns such as circles or figure eights. Each of the parameters is an 16bit signed offset value added to the neutral zone. However this was a very inefficient method for autonomous control situations because it wasn’t modular enough.

The optimal control equations are shown in the figure to the right. Notice that the orientation of each wheel alternates for each position. The difference between these equations and the software implementation is that the voltages are actually represented by PWM values. Each Vx is added or subtracted neutral zone set point to find the final timer value. The voltage multiplier is a PWM count multiplier. The full code can be found in the Appendices section.

The omniMove function is the software implementation of these control equations. The function parameterizes in a simplistic and efficient manner. The dir and mag parameters are the desired angle and robot speed multiplier. The rot parameter allows the addition of a rotation in on top of the translation direction. This rotation parameter would have been tied to the accelerometer to offset unwanted rotations. A wireless control algorithm uses this function to allow OmniBot to be controlled remotely using the serially connected XBee module. Using the keyboard the user can control every parameter seamlessly. Although being controlled manually by the user, OmniBot uses sensor data stop automatically if the user gets to close to an object.

Sensors

The primary sensor system was the eight ultrasonic range finders positioned every 45 degrees around the mobile platform. To the right shows the left side sensor. The front, left, right and back sensors are 3pin PING))) sensors. These rangefinders have a very narrow band but are more accurate the 4pin HC-SR04s. These were used as fixed sensors since they were better suited for relative positioning rather than obstacle avoidance.

The diagonal rangefinders were mounted to servos to provide 360 degrees of range finder coverage. The HR-SR04s ultrasonic range finder has a wider detection band than its PING))) counter parts thus was better suited for covering the corners. Mounting the sonars to servos alleviated many issues that had been originally overlooked like dead zones but also incurred some measurement issues. Moving the sensor while simultaneously trying to read from the sensor would cause significant measurement errors. Most of this was overcome by writing many different orientation function for the servos. As well as a function that would align the servos in the direction of translation. This function was primarily used for the manual control functions.

To filter out invalid sonar readings a running average function was used. This function would do a burst of up to 10 readings looking for three consecutive consistent readings. The average of these 3 readings is taken to be the final reading. This function reduces some of the error when comparing values between different sonars. Each sonar is referenced as a position between 0 and 7 so that when the read ping function is used individual offsets can also be added to correct for any positioning issues. These offsets are stored in a global array.

Sensors that did not make it into the final design were the light sensors, accelerometer, magnetometer, and bump sensor. The bump sensor would have used the aluminum mesh on the outside and some stripped wire to act as contact sensors. The light sensors were meant for ground detection.

Behaviors

The first behavior that was implemented was synchronizing the direction the servo mounted sonars were pointing with the direction OmniBot was attempting to translate in. This allowed for manually control while simultaneously testing the obstacle avoidance algorithm. However since OmniBot is so large testing this in enclosed environments was ineffectual. The sonars almost always found something to close to the platform and would zero out the translation speed. This was useful for tweaking the threshold values for when the robot should stop immediately.

From a stationary position Omnibot will try to look in all directions and pick the direction with the farthest obstacle. The pickDir() algorithm is as follows;

• Move servos to vertical orientation (Sensors facing forward and backward) • Read front 3 and back 3 sonars, store minimum value for each direction • Move servos to horizontal orientation (Sensors facing left and right) • Read left 3 and right 3 sonars, store minimum value for each direction • Pick the maximum value from the minimum values stored for each direction • Return the direction corresponding to the max value found (0-3: Front,Right,Back,Left)

The pickDir() function is used with the moveInDir() function. This function take the value returned from pickDir() and attempts to move in this direction until reaching a wall or obstacle. Depending on the direction of motion, the servos are rotated such that there are 3 sonars pointing in the direction of motion, 2 sonars pointing at plus or minus 90 degrees of the direction of motion, and one sonar pointing in the opposite direction of the motion. The choices for the directions are limited to forward, backward, left and right. The function use the sonar data in the direction of motion to pick a translation speed for the robot. Thus as the robot approaches something the magnitude of translation is decreased simultaneously. Once a minimum threshold is reached in the direction of translation the function goes back to the stationary state. In the case of moving in the forward direction the two front corner sonars would be oriented to point forward. The back left sonar would point left and the back right sonar would point right. The forwards facing sonars are used to determine how fast OmniBot should move in that direction. The left and right sonars apply a rotation to the direction of translation to attempt to maintain the relative distance of walls on either side. With these two functions OmniBot should be able to navigate a maze like environment.

Conclusion

This project was very mechanically intensive. The mobile platform and mecanum system comprised the majority of the work involved. The robotic vehicle successfully accomplishes omnidirectional motion using the mecanum drive. The drive train is responsive and can accomplish a variety of complex movement patterns. Furthermore omnidirectional motion is achievable while also carrying heavy loads which makes the uses for the platform easily extendable. The code for controlling the mecanum drive and the sensors is modular and portable. The behaviors implemented allow for simple environment navigation and demonstrating the benefits of implementing a omnidirectional drive. To test the final behavior a simple maze is to be constructed for OmniBot to attempt to navigate. The algorithms still require tweaking but will be finalized in the next day. The outcomes of these tests will be posted on the robot website.

One of the major limitations of this project was that it does not have accelerometer or

magnetometer feedback. Although the behaviors would not require these sensors, their utilization would vastly increase the accuracy of translation as well as enable a greater variety of complex behaviors stemming from the ones already created. A circular linked list was to be used to insert behaviors and updates as the various sensors and controllers were polled. Utilizing interrupts to a greater extent would have also been beneficial but were not necessary in many cases.

Ultrasonic range finders are very accurate sensors and greatly exceeded my expectations. However this accuracy also caused unwanted effects. Whenever the sensors are in motion the readings would be skewed. Given more time and math these affects can be mitigated quite accurately even without the addition of the accelerometer.

Given the opportunity to start over , the first major change would be to decrease the

overall size as much as possible. As the size of the platform increase the overall difficulty seemingly increases exponentially. A smaller system would make have been constructed much faster and been much easier to test and debug. With less time spent implementing mechanical or mounting systems more time could have been spent incorporating sensor systems. However, the knowledge gained in terms of mechanical systems, their constructions, and materials was an enormous experiencing. Although making every mistake possible is time consuming and disappointing it was only through this trial and error was the rationale behind the intelligent machine design process illuminated.

Documentation

Transmission Housing:

http://www.andymark.com/NanoTube-p/am-0809.htm Mecanum Wheels:

http://www.andymark.com/Mecanum-s/53.htm Talon SR Speed Controllers:

http://files.andymark.com/Talon_User_Manual_1_3.pdf DC Brushed Motor:

http://www.andymark.com/CIM-motor-FIRST-p/am-0255.htm PING))) Sonar:

http://www.parallax.com/product/28015 HC-SR04 Sonar: https://docs.google.com/document/d/1Y-yZnNhMYy7rwhAgyL_pfa39RsB-x2qR4vP8saG73rE/edit Servos:

http://www.radioshack.com/product/index.jsp?productId=21757496 XBee Series 1:

http://www.adafruit.com/products/128?gclid=CNL7jpb38r0CFUYV7Aodty0Akg XBee USB Adapter:

http://www.adafruit.com/products/247

1. Simplistic Control of Mecanum Drive by: Ian McInerney, FRC Team 2022 2.

Appendix