Designing the Robot Chassis with Google Sketchup

Today, I spent the majority of the day learning Google Sketchup and making the parts and models that belong on the robot. However, I am running into a few mechanical considerations.

1) the camera is LARGER than I expected. I need to consider taking the camera out of the bubble and/or extending it from the base.

2) the Router is also LARGE. Where should I stick this thing? We also need room for sensors and a battery. Crap... I only have so many links for the car, so it will be more difficult to increase the length of the robot.

Too bad I am not a mechanical engineer...

I hope my team members can give me some suggestions on how to fix this issue of space.

GPS research in progress (1/3/11)

Today, I found out that to do fast debugging for the GPS module I will need a cheap LCD display. More than likely, I will use old code from 319k and use the same cheap module. NEED TO TELL JOHN THIS. NOT SURE IF IT IS ON THE BOM. 

Valvano has his EE345J, graduate class, students design and evaluate a battery-powered GPS and IMU system (lab document link here: http://users.ece.utexas.edu/~valvano/EE385J/Lab5_GPS_IMU_PaineCao.pdf). This design integrates data form multiple sensors in order to enhance accuracy of measured data. I need to email him to get more info on this class project. 

SOFTWARE

How the students designed it is as follows, the program is divided in to 5 major functions. An infinite loop in the main which uses a foreground task that controls the GPS, which continuously reads from the SCI and preprocessing TSIP report packets as they arrive. The report packet as a structer as follows: 

<DLE><ID><data bytes><DLE><ETX>

The <DLE> byte is 0x10. Data bytes 0x10 are padded with an extra <DLE> byte. The foreground loop continuously reads in data from the GPS module. When a new report packet is detected, it saves the data 

bytes, stripping any padding bytes, in a global byte array buffer. Once it detects the end of a report packet, procCmd() is called and is passed the <ID> of the report packet. 

The procCmd() function processes the data bytes in the buffer according to what packet ID it received. The two main packets have IDs 0x46, health of receiver, and 0x84, LLA position in doubleprecision.  The health of receiver packet reports if the GPS module is functioning correctly and how many satellites it has locked on to. This is stored in a global byte variable, gpsState, which can be output on the LCD for debug purposes. The 0x84 packets give latitude and longitude in radians in 8-byte double-precision floating point format. They get stored in a global latitude and longitude variable that tracks position, and converted into positions on the map and stored in global unsigned char variables.

Here is the software flow chart found below.

Of course, the GPS will be on the robot, so this flow chart will not be entirely accurate. I will modify this to incorporate reading control information from the controller (hooked up to the PC/host).

Embedded Sytem Design Software Starter Files (Valvano)

HARDWARE

------------------------------------------------------

GPS Overview (a summary of sparkfun's overview: http://www.sparkfun.com/tutorials/68)

• Performance Concerns
• Start Time- 
• How quickly the module can lock- when a lock is made the module can receive the GPS signal from satellites to calculate position. The amount of time required is referred to as, START TIME.
• Positional Accuracy of the module- 
• How well  it gets and holds the lock in the presence of obstacles (urban setting, canyon areas, etc)
• Dependencies for performance:
• Number of Satellite Channels- the module can simultaneously receive is an important specification. GPS modules today can receive up to 20 channels. More channels mean more places for the modules to look for a signal, corresponding to faster locking times and better locking in urban settings. 
• Onboard processing of the GPS signal- new chipsets such as the SiRF III provide faster and more robust locking than previous SiRF II based designs. Ne featers such as wide area augmentation system (WAAS), or differential GPS (DGPS) provide better positional accuracy by correcting GPS signals using other sources (such as ground stations). 
• Interface
• Easy to use!
• NMEA 0831 compatable
• can oubout standard NMEA messages every second
• reporting speed
• 3D position
• number of stallites in view
• GPS time
• and more...
• NMEA output- is the default, so all the user needs to do is apply power and the module begins spitting out NMEA data.
• protocol differs from module to module
• check data sheet to see what commands and protocols are available
• Batteries and Antennas
• Needs batter

IN PROGRESS!!!

Hardware Overview

I have yet to explain exactly what our robot is attempting to accomplish. However, a quick synopsis is at the top of my blog. Let me divulge a more in-depth discussion of this information to my readers.

The robot is intended to be used as a military-operated vehicle that employs multiple sensors to detect potential bomb threats by collecting radiological and chemical data. Hundreds of men and women die every year in combat due to un-detected bombs and chemical exposure. The Bomb-Sniffing Robot is a proposed solution to this problem. This project’s goal is to save future men and women from dying preventable deaths in combat. As a result, the robot’s design targets military customers as well as civilian bomb squads.


As a side-note, look at this compelling data on the deaths from bombs within Bagdad, Iraq. The number of deaths just keeps rising (information found from http://news.bbc.co.uk/2/shared/spl/hi/in_depth/baghdad_navigator/). 

Now that I hopefully have your attention, lets go over our hardware. The figure below shows the overall hardware diagram. This figure describes the system as it pulls in data and transmits important sensor data.





















The basic operation goes as follows, a user wants to see if there is a bomb or other chemical hazards in an area, but this person does not want to get blown up--so use our Bomb-Sniffing Robot. The user can use the PlayStation controller (hooked up by USB) to control the on board camera's pan/tilt/zoom and robot's direction/speed. From that a GUI sends out the controller commands (via wi-fi) to the robot. Meanwhile, the robot is collecting all sensor data (camera, gps, LPG, propane, carbon monoxide, methane, and radiation). Then the robot transmits to the GUI the sensor information at a constant rate through the wi-fi connection.  The GUI allows the user to see the data in a convenient graphical and numerical format (via graphs).

I will later post an in-depth discussion on our beginning software overview between our two main submodules-- robot and GUI. There you can learn about what is going on in the background and what special features each has to offer. Note that our design is very unique, because you don't need a large amount of on-board memory on the robot, due to the constant transmission of data. Just enough to hold the data for awhile until another transmission can be made.