Senior Project 2011: The Robot

Intelligent Ground VehicleMech544 Design Clinic Final Project

Josh George, Caleb Gillespie, Andrew Steele, Patrick Wilsey, Clifford Zimmer

Mechanical Engineering, University of Cincinnati

Introduction

This report is a conclusion of our senior design project for the graduating year 2011, the design of a new robotic system for the Intelligent Ground Vehicle Competition (IGVC). It details our processes and how we undertook the design itself, a thorough description of the robot’s design itself (including the physical, electrical, and programming aspects of its makeup), a section about current known issues and how we propose fixing them, and finally a section detailing recommendations about next year’s IGVC competition based on observances and general experience.

2

Contents

Introduction………………………………………………………………………………………………………………2

1. Design Process…………………………………………………………………………………………………….4

2. Current Design

a. Hardware…………………………………………………………………………………………………5

b. Electronics……………………………………………………………………………………………….4

c. Software………………………………………………………………………………………………….5

3. Known Issues………………………………………………………………………………………………………6

4. Future Competition……………………………………………………………………………………………..7

Conclusion…………………………………………………………………………………………………………………8

3

1. Design Process

Initially our group was tasked with solving drivetrain issues with the current robot. The main issues brought to light with the current drivetrain were:

Lack of servo capability Overpowered for desired application No adjustable gear drive for changing contest rules

However, upon discussing the old design in more detail, more issues were found with the design. Chief among these were:

Inefficient and complicated voltage conversion Poorly conceived wiring Adapted motion control equipment, not optimal for IGV needs Poor weight distribution Blind spots and bulky turn radius Lack of water proofing Little modularity (difficult to repair) Poor aesthetic appeal

Therefore, the team decided it to be in the best interest of the robot team and for design experience to conceive an improved structural design for future competitions. Using the previously noted issues, a list of key design goals was created:

Simplicity – Less complicated systems leave less opportunity for failures and make it easier to perform root cause analysis in solving problems.

Reliability – The physical platform for this competition is of relatively little significance, the software is the deciding factor. Most resources should be put to use solving software issues, not troubleshooting constant hardware failures.

Adaptability – The design should leave enough open space to allow for future expansion within the vehicle, as well as provide space on the sensor mast for additional future components. Also, the drive train should be created in such a way that gear ratios can be changed, and input voltage to the motors could be increased if necessary.

Given these constraints, it was decided that the following list of design parameters was necessary for implementation of the new robot design:

Low center of gravity to increase stability

4

Three points of contact with the ground to decrease complication of suspension systems

Sturdy frame design to reduce flexing and provide solid mounting points for equipment

Rigid single mast to decrease the moment of inertia of the vehicle and therefore minimize residual motion from bumps or changes in elevation

Location of drive wheels at the dimensional center of the vehicle to allow pivoting in place

Location of drive wheels at a width equal to the length of the vehicle at its greatest diagonal breadth in order to eliminate blind spots and the possibility of collision with objects while pivoting

Elimination of the DC-AC conversion currently utilized on the Bearcat Cub, implementing DC-DC step-up conversion instead in order to reduce complication and increase reliability

Implementation of servo motor technology in order to enhance the robot’s ability to track its location and make precise motions

Sizing of motor equipment to more appropriately meet the needs of the robot and reduce power draw and weight

Use of an integrated MCU/motor system to avoid the need for amplifiers and enhance the communication between the motors and the computer program

Substitution of the Xbox Kinect for the current camera arrays in order to explore new technology in order to remain at the forefront of innovation in the robotics field, as well as reduction of cost

Aesthetically appealing geometry and materials specifications as well as extensive careful metalwork to maintain a balance in form and function

Low center of gravity

The vehicle was designed to be as low to the ground as possible while still allowing substantial clearance for ruts, divots, or changes in elevation or grade. As a model for these needs we looked to the powered wheelchair market for guidance concerning the needs of a similarly sized vehicle. The largest wheels we found common on these vehicles measured 14 inches in diameter, but most of these vehicles also had runners located below the radial distance to the ground. After looking over the design requirements and calculating the sum of moments for the vehicle under various circumstances we decided a higher frame elevation was feasible and more desirable for us. A key concern was striking a balance between caster size and ground clearance. Too little ground clearance limited us to small casters which could more easily get stuck in wet ground or in divots and ruts, but a higher clearance would increase the moment

5

arms of all the masses of the vehicle, decreasing stability. We implemented a design by which we could place load-bearing members below the frame which supported the wheels, allowing us a 1.5” advantage in the y-direction for mass location. This increases the required applied moment to the vehicle which might be experienced during sudden deceleration in order to cause the vehicle to rotate onto its nose (which has no caster as later discussed).

Three points of contact with the ground

At first, the design team had discussed a four-point design with a spring-loaded caster to ensure that the front of the vehicle would avoid a traumatic ground impact. However, it was quickly clear that this would be burdensome from a design standpoint as well as complicated and possibly unnecessary. After the design was finalized it became evident that incredible forces would be required to turn the robot on its nose, and the simplicity of the three-point design was favored with no front caster.

Sturdy frame design

The new Cub 2 frame was fully custom built utilizing machining techniques rather than relying on standard 80/20 attachment methods. This reduces some modularity of the vehicle but with the benefit of greatly increased rigidity and some measure of added simplicity as lining up the male and female components of the 80/20 fasteners can be tedious and difficult. While right angles were included in the design, several 45 degree angles and triangulation were implemented as well to reduce planar flexing due to varying forces.

Rigid single mast

The Bearcat Cub utilizes two masts connected by a crossbar. While this is a simple and effective method, there were several issues with this design:

The weight of the 80/20 required vs. a single mast is greater than 100% There is a lot of resistance to motion in the z-direction and some resistance to

motion in the y-direction, but almost none to motion in the x-direction. This leads to residual motion after bumps and considerable sway in the mast during normal operation

The double mast is visually unappealing

The single mast utilizes tie-down lines with turnbuckles to allow tension adjustment, creating a much more rigid shaft with much less weight.

6

Location of drive wheels at the dimensional center of the vehicle

The drive wheels were located at the exact center of the vehicle front-to-back. This allows for the robot to pivot in place in order to avoid obstacles. In theory this eliminates blind spots because the robot can pivot 360 degrees and see everything around it without the threat of coming into contact with anything.

Location of drive wheels at a width equal to the length of the vehicle at its greatest diagonal breadth

Similarly to the location of the wheels at the dimensional center, the location of the wheels at a width equal to the greatest extent of the vehicle frame creates a “footprint” that is dimensionally equal when the vehicle turns in place.

Elimination of the DC-AC conversion currently utilized on the Bearcat Cub

DC-DC converters are now more affordable and far more energy efficient than when the Bearcat Cub was originally designed. This greatly reduces complication of the electrical system and also reduces a consistent point of failure from the vehicle.

Implementation of servo motor technology

Servo motors count clicks per rotation in order to track precisely what the angle of the motor is. This precision allows for very small motion very easily, while at the same time precisely tracking the number of rotations the motor has traveled over any given time. This will prove useful as software is developed to command precise movements and measure distances by wheel rotations to supplement visual methods.

Sizing of motor equipment to more appropriately meet the needs of the robot

The motors were selected in order to provide appropriate torque requirements. The current motors provide 50 pounds of combined force at the wheels, which is enough to accelerate the vehicle over various terrain types rather easily, but not overpowered so that wheel spin is induced or power drain is too great.

Use of an integrated MCU/motor system

Quicksilver Controls was chosen upon the recommendation of Mark McCrate because of the integrated, plug-and-play nature of their systems design. While the process was more complicated than anticipated, this technology still has the potential to make

7

software programming far easier once the team has learned how to properly utilize the system. Direct signal-level communication should be a huge advantage for this technology, and the ability to beta test within the Quicksilver software and learn their command lines from demo programs should prove advantageous.

Substitution of the Xbox Kinect for the current camera arrays

This was done in order to implement a cheaper, yet comparable solution to the Bumblebee technology implemented on the Bearcat Cub, but unfortunately infrared interference from ambient sunlight is great enough to render depth perception of the Kinect useless. This should still be a great tool for indoor robots as well as demo software for future development within the club.

Aesthetically appealing geometry and materials specifications

The Bearcat Cub 2 has definitely succeeded in this respect, drawing a great amount of attention from teams at the IGVC despite its inability to run this year. The brushed aluminum finish is very appealing, as well as the simplicity of a single sensor mast. The team decided to go with aluminum because of its light weight and low cost relative to Plexiglas, as well as superior workability. Also, aluminum would allow a team in the future to paint the robot if they desired, but the senior design team feels an aluminum finish is very aesthetically appealing and would be desirable to remain as so on the robot.

8

2. Current Design

a. Hardware

i. Frame/Structure

The robot structure itself is as shown below. It is principally composed of extruded 80/20 aluminum which allows for a lightweight yet durable structure that also grants a high degree of modularity so that any changes can be made quickly and easily. The frame was designed to provide the maximum of support for all the components and provide a mounting structure for the drivetrain and power system. The configuration uses three wheels, two for drive mounted in the middle and one for support mounted in the rear. This configuration is allowed by our weight distribution which has most of the weight concentrated between all three wheels. The front will have a skid mounted on it to keep it from hitting the ground hard. This configuration mounts the drive wheels in the middle of the robot to allow it to turn about its center. In addition to the layout shown, the robot will also have a single mast stretching up from the middle of the vehicle that will hold the sensor system, supported by four tension cables tied to the four corners.

Figure 1: Initial Frame Layout

ii. Power System

The robot runs on two 12 Volt batteries connected in parallel to provide 12 Volts of power to the robots electrical components. The drive motors and Sick LiDAR run on 24 Volts and require a DC/DC converter to operate properly. Each motor runs on one separate converter and the LiDAR is connected to one of the converters. All components are connected in parallel

9

at two terminal blocks. All other electronic components are also connected to the power system as well through a serial hub. It should be noted that the whole power system routes through a single governing switchboard as shown below.

iii. Drive System

The robot itself uses one Quicksilver NEMA 34 servomotor per drive wheel, each connected to a SilverNugget N3 motion controller. These motors each drive the 14” diameter wheels (each wheel with approximately 5” wide treads) separately via heavy duty chain-and-gear drive. The gears put the motor’s rotation through a 4:1 reduction (the wheel shaft turns four times slower) than the drive shaft, providing a speed of somewhere roughly in the 3-6 mph range (actual top speed is as yet to be tested at the moment of writing this report). The drive system is displayed in the diagram below (generated via AutoCAD), in pink. A picture of the chain (including a tensioner) is also displayed below.

Figure 2: Drive System Layout

10

Figure 3: Chain Drive

iv. Safety/Durability Consideration

In building the robot safety and durability were major factors. Two emergency stop measures were implemented (as per competition rules, a manual button is mounted on the frame over two feet above the ground and a remote stop with a range of over 100 feet), and a safety light was built on the structure to signal when the robot is in operation. In addition, to protect the robot itself it is mostly enclosed in a shell made up of aluminum sheets joined together. This shell is design so that it is easy to remove in order that the robot itself is easy to repair and service, yet still durable enough to keep dirt and debris out. In addition, all components have been sized so that the Cub II can withstand the stresses and strains of competition operation. The picture below shows the safety light, the manual e-stop (below the light), and the remote e-stop (in front of the light).

Figure 4: Safety Equipment

b. Electronics

11

Figure 5: Bearcat Cub II Sensor Diagram

i. Computer

The laptop computer being used to control the robot is a Dell Latitude D830. The computer runs with a 2.6 GHz processor and 3.5 GB of RAM. All data gathered by the sensors is collected and analyzed by the Quick Control and other programs.

ii. Cameras

The Xbox Kinect provides the primary sensing capabilities for the robot. The Kinect relies on its two cameras and an IR projector to see. The two cameras are color CMOS sensing and IR sensing and have depth sensing capabilities. The Kinect has a horizontal field of view of 57°, a vertical field of view of 43°, and an operating range of 1.2 – 3.5 meters. The cameras send data via USB at 30 frames per second.

iii. Light Detection and Ranging (LiDAR)

The Sick LMS200 LiDAR using laser detection and ranging and is the primary sensor for seeing preventing collisions. It has a 180° field of view with a 75 Hz scanning frequency. It has an operating range of 0 – 80 meters. It interfaces via two serial RS-422 connectors for power and control.

iv. Global Positioning System

A Garmin GPS 18x OEM is used for passive navigation and tracking. It is not interfaced to provide steering and guidance for the robot. The GPS receiver

12

has an acquisition time of less than 45 seconds and updates at 1 record per second. The GPS interfaces with the laptop via an RS232 serial connector.

c. Software

i. Mapping

The autonomous program will actively map the course as it goes by plotting GPS coordinates in a log file. This log file will be used in order to make sure that the robot does not turn itself around and finish at the starting point due to a difficult obstacle. Mapping will be used solely for advancing the robot's progress. In the future, this mapping code can be used to have the vehicle autonomously “escape” from the course via the same path, but no plans are made to develop this feature this year as it is not specifically part of the competition.

ii. Lane Detection

The lanes will be solid white painted lines on grass. Using the Kinect color camera as raw input, a line detection algorithm is used to separate drivable area from the out-of-bounds area. The robot is not permitted to cross any line at least 1” wide that it detects as a “white line.” This width factor assumes error in the Kinect sensor to accurately detect anomalies in the grass which could cause severe problems during the competition.

iii. Path Finding

The Bearcat Cub is designed to drive as directly as possible to each waypoint. The program uses an iterative method that constantly checks for lanes and obstacles. If an obstacle or edge line is found, the algorithm actively checks to see if it is on a collision course. If there is no collision course, then there is no change in robot behavior. However, when a collision is imminent, the robot adjusts course in order to prevent a collision or going out-of-bounds.

For hazards detected via the LiDAR, the avoidance algorithm has time to respond due to the LiDAR's range. However, when detecting edge lines or obstacles through the Kinect, the robot is designed to slow down much more in order to compensate for the smaller range of the optical sensor. After passing the obstacle or getting out of range of the boundary line, the robot readjusts its course straight to the waypoint. Once a waypoint has been reached (within a margin of error), the next waypoint becomes active and the first is neglected. Due to our zero-point turning radius, this active priority shifting can work even right next to obstacles without a collision.

13

3. Known Issues

Below is a table of problems that arose during the building and competition phases of the robot. The believe root cause and the seriousness of the problem are also given. The level of seriousness is on a scale for 1 to 5 with 5 being the most severe. The proposed solutions listed are solutions the team came up with to subdue the problem.

Problem Cause Seriousness SolutionsLogic ground pin on serial hub burnt out on 5 ports

Back current created by motors

5 Install clamp modules and ensure cables properly soldered and insulated

Back current returned from motors

No clamp modules 5 Install clamp modules and ensure cables properly soldered and insulated

LiDAR data cable fried Back current created by motors

5 Install clamp modules and ensure cables properly soldered and insulated

Kinect IR sensor overwhelmed by direct sunlight

Sunlight washes out IR field projected by Kinect

3 Use stereo camera or other vision system for outdoor use. Use LiDAR solely for depth sensing. Use light filtering film.

GPS not precise enough for new rules. Cannot qualify

Need better quality device that has better precision and accuracy

5 Utilize calibration services such as NOAA, or Canadian Gov't. Buy more highly accurate compass and GPS device.

Insufficient payload space 2 batteries combined volume, 1 battery may be sufficient for power

5 Remove a battery. Test for battery length of service to verify one is sufficient. Install payload box

Wheels fit loosely to axles Bolts incorrectly sized 3 Use new bolts/pins that are correctly sized

Laptop overheating prevention

Sunlight producing heat 5 Install laptop hood and use a cooling fan plate

Wireless e-stop doesn't have enough range

Current device has a range of 30 ft. 100ft needed.

5 Get a wireless transmitter with better range. >100ft

Chain-tensioner Simple design implement

2 Design device to ensure chain stays on tensioner

Multidisciplinary team Current team all mechanicals

5 Get electrical and computer engineers on board to get more specialization into designing and building the robot

3rd wheel castor longevity Made of plastic, potential for damage greater

3 Get a rubber wheel/castor

14

4. Future Competition

In this section, observations from the 2011 competition, including the hardware used by competing universities, and issues common to the competitors, will be outlined and examined. The mechanical design used by the teams varied widely in everything from size to effectiveness. Most of the top teams used a prefabricated mechanical platform so they could focus on the software side of the competition, and not be distracted by hardware failure. One team used a Yamaha wheelchair which they controlled by tapping into the joystick controller and sending signals from a laptop. Another purchased a military grade vehicle from Segway. One team used a vehicle very similar in size and design to ours, with excellent results. This vehicle had been perfected over the course of several seasons of competition. The vehicles varied in size from the required minimum (slightly smaller than our design) all the way to the size of a small golf cart.

Our design falls among the smaller and more agile of the robots competing. Much of the hardware and sensory equipment used was common to nearly all robots. Sick LiDAR was used by a large majority of teams. A large portion of the teams also used the same model GPS utilized by the Bearcat Cub 1. This model gives excellent accuracy and reliability, although many teams struggled to hit required waypoints to within the specified range. A wide variety of motion control units were used, although none stood out as being particularly well thought of. Most teams had at least some complaints concerning the units used on their vehicle.

Intelligent navigation software was run on a wide variety of platforms. One team utilized MATLAB, which is easily programmed and provides an excellent graphical interface, but suffers from a slow refresh rate. Several other groups utilized Labview, run over a Microsoft Windows platform. At least one other team used ROS (Robot Operating System) which is run through Ubuntu Linux. This system offers many advantages including drivers and libraries supporting a variety of popular hardware and sensory equipment. Although the competition was warm and extremely sunny, glare on the cameras proved to be a smaller issue than originally thought, and had no effect on the performance of our Sony Camcorders, although some teams complained of issues with webcams, and were forced to place a dark lens over them to reduce this issue. Some teams also experienced issues with their color recognition algorithms, as the vehicles were required to navigate orange and green flags against a backdrop of green grass.

Overall, reliable hardware is absolutely necessary to a good run, since it allows the design team to focus on the software aspect of the competition, which was the main focus of most teams.

15

Conclusion

The new Bearcat Cub II has been designed as an improvement over the past years’ vehicle. It will hopefully replace the Bearcat Cub I as the flagship vehicle of the UC robotics team in the next year or year after competition. It predicted performance should be significantly improved over previous model designs and its structure able and makeup should be much more adjustable and open to customization and adaptation. As a design team we learned a great deal about mechanical design when working with this robot. In addition, we learned about troubleshooting and how to approach a variety of problems and issues while working under a deadline. This project has proven to teach us as a team and individually a lot as well as providing what we believe to be a valid and important contribution to the UC robotics team.

16