Universal GPS-Guided Robotic Platform

Rochester Institute of Technology

SME Student Chapter 18

2003 Post-Secondary Robot Construction Entry

(alphabetical by surname) James Dawson, Mike Duke, Josh Karpoff, Alejandro Lam, Nate Pendleton, Steve Pomeroy, Zac Poncheri, Andrew Snodgrass, Nick Valerio

Concept

Building upon our ideas from the previous two years (2001, 2002), our team has decided to revise the 2002 design and build a more generic robotic platform. This platform is designed to be robust and versatile to allow the robot to be quickly re-purposed. The key technology focused on is the Universal Serial Bus (USB) to allow for components to be hot-swapped. A good example of how USB can facilitate a robotic application is what we designed for the previous year - a Global Positioning System (GPS) -based autonomously-navigated robot.

The robot's main knowledge of the world is through a GPS receiver and through local proximity sensors. This combines the best of both worlds: global knowledge of its environment (so it knows where its destination is in relation to its current position) and local sensors, so it can avoid any obstacles in its path on the way there. With both global and local sensors, as well as a record of its past movements, the robot could successfully map out a terrain and then trace its way along the "blazed" path. This system can be used to allow the robot to move autonomously around a terrain and with its on-board wireless sensors a human can monitor area the robot autonomously traverses.

Design

The design of this robot is an elaboration on the previous year's robot. We learned a great deal about what works and what doesn't work in a robot of this scale, and applied that knowledge to our current design. The frame of the previous year's robot, for example, was solid aluminum. Though light, this didn't stand up to the forces of the drive train. This year's design uses much sturdier steel tubing and will easily withstand the drive train's forces.

Another major revision was the choice of metal "tank" treads instead of rubber wheels. The fixed 4-wheel-drive mechanism worked fine in our indoor test environment and adequately on concrete, but when placed on grass it failed. We researched the use of treads on a variety of surfaces and found them to be the best choice for a robot of this scale.

As this is the 3rd robot our group has created, we have decided it will be the last; the last platform we build, that is. We have put every effort to design this robot to flexible in both chassis, electronics and software. (In fact, the software is the same software as used for the previous year's robot. We spent a good deal of time creating a flexible software development platform and it has paid off in reusability.) For the chassis, the robot has two main parts to its frame: the mobile base and the "upper deck" which houses most of the electronics. A single USB cable connects the two levels, allowing for easy removal of the upper deck and repurposing.

USB

Using USB was an important design decision for this robot. USB, the same system that connects your home computer's mouse and keyboard to the computer, shares the same design goal as we did: flexibility. A component can simply be plugged in, the software can detect what type of component it is, and the component can immediately be used. This would allow us to design, for instance, a new sensor package that can tie directly into the robot without need to build anything more than a simple hardware interface for it and accompanying sensor drivers.

USB also provides the robot with another key component - a sensor/control network. As the application gets more complex, more components become needed to accomplish the given task. Our previous years' robots had the on-going problem of not having enough input/output. (Generally, this is solved by using expensive, proprietary control interfaces, but we were looking for more accessible approach.) USB allows for 127 such devices, which is more than enough for any robotic application. Our design this year uses only 4-5 such USB components.

GPS

For our robot's application, the first thing we found was that GPS liberated us from a confined area (it practically inverted the area we could operate in: from primarily indoors, to solely outdoors). With that newfound freedom, we decided we could allow the robot to operate on many new types of terrain: from slopes, to grassy hills, to sidewalks - a variety which demanded robust physical design. Not only did these new terrains require a more "buff" robot, but it had to be smarter as well. If the robot would be driving on a sidewalk, it would have to co-exist with others on it and avoid obstacles.

Safety Considerations

The sheer size and potential speed of the Rover caused us to carefully evaluate many safety issues. Its size and weight make it difficult to precisely control its movement. To counter this, the Rover has 6 infrared range-finding sensors which it can use for obstacle avoidance. In addition, it has multiple touch sensors which instruct it to immediately halt what it is doing and re-evaluate its direction. Of course, as the system is designed to be autonomous, a great burden weighs on the software to succeed in giving sane and appropriate movements based on its sensors. With this in mind, the software was written in a modular way such that each component could be individually tested before assembling the whole. And, as all autonomous and semi-autonomous devices should, it has a big, red failsafe cutoff in case of emergency.

Components:

Student-constructed components

Donated components

Purchased components


For More Information Contact:

Steve Pomeroy
Zac Poncheri
Andrew Snodgrass
Last modified: Mon Apr 28 18:13:08 EDT 2003