Weekly Progress update

1-14-2011
So this first week I got several important things taken care of. The first thing I did was to solder and integrate the killswitch into the rest of the power circuitry. I also added an LED to indicate whether or not it was engaged.

The next thing I did was to integrate the joystick program I had made with the servo controls to get the joystick driving the platform remotely.
Right away we realized that something was wrong with the steering as it pulled hard left, and no amount of programming seemed to fix it entirely. This issue plagued us for several days. After playing with the mechanical side of the steering mechanism, I discovered that the amount that the suspension is compressed changes how much the platform veers left. So I added some zip ties to compress the springs more, and now it drives nearly perfectly straight.

We started testing the driving again, this time at full power, but after about 5 minutes, the robot stopped working. The killswitch mosfet had overheated, detached from the heatsink and died. I needed to replace it and find a way to cool it better. Today, I replaced it, and attached it to a larger heatsink with a built in fan (It's actually a compact CPU cooler :P). After that, I tested it out by driving it around on the grassy hill next to bldg 60 at full power. I found that at full speed, tipping is a serious concern, as it flipped over twice. Next week I plan on modifying the driving code so that the steering sensitivity varies inversely with the speed to help reduce this risk.

The last thing I did was getting a program running with pygame so an image of a robot could be moved around on a satellite image background with the joystick. I also got started on implementing this code with the gps and got the image to move around according to the gps data, but not accurately.

GPS visualizations

Using the Pharos GPS-500 we can get a latitude and longitude coordinate pair. If this pair is then converted to a coordinate system in python, you can observe the visual drift of the signal. This first image is a screen shot of the GPS signal drift while the connected laptop is stationary.


The scale on the image can be compared to the theoretical width of the ball, which is 2 meters. The average drift during the test was 3.3 meters, and the maximum was 7.25 meters. This is pretty accurate, but when the laptop moves its a completely different story.
The following image represents a u shaped walking path. It very nearly resembles the actual path I took, but it has jagged locations where it deviates from the real path.


The final image is a graphical representation of the drift in the x and y coordinates while the laptop is stationary. As you can see there is considerable drift in both coordinate plains, and this poses a problem for precise robot navigation. It is my intention to look into the WaaS system to augment this signal.

In the above image the red line represents X axis drift, and the green line represents y axis drift.

Chassis Modifications

1/12/11

• Adjusted the steering rods to compensate for drift
• determined the maximum and minimum limits for the servo and set the corresponding numerical value on the controller
• Found that drift is dependent on weight in chassis
  
• springs need to be stronger or the suspension needs to be more stiff
• finished soldering together the kill switch
  
  
  Parts list
  
  
  need hot glue
  charger for the Li-Po batteries
  pipe clamps to adjust spring tension
  

IMU experiment 1/12/2011

After much head scratching the IMU began to spew forth loads of relevant data!
when the sensor is shook in only the x direction you can observe the waveform in the red data stream, when it is shook in only the y direction you can observe the waveform in the green data stream, and when shook in the z direction there is a waveform in the blue data stream.

First issue:
The baudrate for communication between the arduino and python was set at 115200 bits per second, and this caused an accumulation of lag in the data.

Solution:
Resetting the baud rate to 4800 eliminated the lag.

Second issue:
The arduino code correlated pins to the accelerometer data incorrectly. It was searching for data on pins 1-5 while the data was being fed out on pins 0-4.

Solution:
Reassign the pin numbers to the correct variables on the arduino.

Third issue:
The signal is choppy if the wires aren't connected to the board in a specific way. I think this is due to a poor quality wire connector.

Proposed solution:
Solder the wires directly to the sensor.

Pre Class Progress

Tasks

• Uninstalled Old Version Software
• Installed
• Python 2.6.6
• Pyserial
• Pygame
• Arduino Software
• Dropbox
• On Screen Keyboard
• Because the keyboard seems to be stuck in function mode and I have yet to figure out why. Therefore, certain keys are currently stuck on special characters.
• Created Email Account (For Dropbox Account)
• robo.magellon@gmail.com
• Arduino
• Lesson 0
• Lesson 1
• Lesson 2
• Lesson 3
• Lesson 4
• Lesson 5
• Get Shaft Encoder Working
• Ad Hoc Process

In Windows Vista or greater, navigate to Start >> Network >> Network and Sharing Center >> Manage Wireless Networks >> Add

• Select "Create an Ad Hoc Network"
• Network Name: "Robo"
• Security: WPA2-Personal
• Key: "***********"

Now that the Ad Hoc network has been created, all computers should select the new network from their list of available wireless networks and connect.


Next, to connect to the computer and initiate a remote desktop session, Navigate to Start >> Network >> Single Click "EEE" >> Right Click "EEE" >> Select "Connect with Remote Desktop Connection"

January 10th 2011

Summary of activities:

GPS usage was discussed.

• Andy attached his laptop to the platform and sent drive and turn signals.

• It was discovered that vex motors can be controlled by the servo control board.

• A Vex battery charger was disassembled to understand the complexity of the electronics necessary to charge a Ni-Cad battery.
• The batteries used for the Rock crawler were identified to be Li-Po type (Lithium-ion Polymer)
  
• A project on the make website was found which details the construction of a Li-Po charge kit for $10
• Andy disassembled the Vexplorer wireless camera to see if the data feed could be used to inform the Magellan platform.
• The compass GUI program was hacked to the fewest lines of code necessary to feed the data into a larger program.
• Identified goals for presentation of the bot at the first 99 meeting

GPS data

The highlighted data stream has the Prefix of $GPGGA.
This prefix denotes that the stream in question is a fix.
Experimenting with the Pharos GPS-500 developed problems with my OS. There were some permissions problems... I will not go into the details.
Anyway, The data is sometimes junk and comes out looking like its in Russian, but sometimes its useful data.
The first number, 195827.782, is a time stamp for the data feed. The time is formatted to Greenwich Mean Time or UTC.
The second number, 3403.0995, is the latitude. The number represents 34 degrees, 03.0995 represents minutes.
The following letter, N, represents that the latitude is north of the equator.
the third number, 11751.1995, is the longitude, same format as the latitude.
The following letter, W, shows that the measurement is west of the prime meridian.

The Data is better if the GPS is run outside, and I think the next step is to get a map in place and follow the data from there.