Friday, February 25, 2011

Cone detection

Crashing into a cone:

video


This video demonstrates the robot tracking an orange cone using a video camera. This is accomplished using roborealm to process the video, and having roborealm communicate with python through an API server. The robot will attempt to crash its right wheel into the cone, and stop once it arrives. The code is in the infant stages, but it will consistently hit the cone, even if it doesn't turn the motors off after it does it.

-B

Thursday, February 24, 2011

Success!!!

Today we finished getting the new suspension attached to the chassis and got the steering aligned. It goes perfectly straight for about 20 meters and then starts to drift a little, but besides a full steering system overhaul, there's not much we can do about it. Tweaking the alignment simply involves adjusting the length of tie rods from the servo to the steering column. I found that one full turn of the adjustment results in roughly 1 degree of change on the wheels alignment
The newly installed suspension works great! The old shocks are still going to need pre-compression, however. We can continue to do it with zip-ties or buy some real clips.

On a different note, I rewrote the gps program to do the mapping with just the encoders and compass. As long as the encoders work as Mitch intended, it should be a very accurate way of keeping track of position. The robot_pos coordinates are no longer in pixels but in meters. This should make things easier in the future. Also, the robot coordinates don't rely on any image updating or processing. The program starts by waiting for a mouseclick on the map and then sets the initial robot position to that spot (This will be replaced by GPS coordinates later). It then requests an input distance and heading, and generates a destination coordinate based on these inputs. It should be a cinch to add on motor controls at this point.

Tuesday, February 22, 2011

Battery life: stress test


The above graph represents the voltage of the motor battery vs. time.
Conditions:
chassis suspended so the wheels do not touch the ground
motor power set to 150 units greater than stop condition
allowed to run without external torque on wheels

A natural exponent function very nearly represents the data, and establishes a horizontal asymptote at 11.26 volts.

It is reasonable to assume that the battery should never be allowed to approach that voltage, as it may refuse to take a charge afterward.

20 minutes of navigation seems to be the limit for safe operation.

-B

Project Meeting - Feb 17th

On Thursday the 17th of February there was a project meeting to discuss remaining tasks.

The result is the following task list.

-Test the run time for a fully charged battery
-Develop graphs and charts to explain the scientific content of the platform
-Test the efficiency of of numerous way points vs. sparse way points
-Test the accuracy and efficiency of traveling via a heading and distance scheme vs. a GPS and pixel scale scheme
-Check the behavior of the platform with constant compass update vs. periodic compass update.

Each of these tasks can be approached scientifically, so the next few weeks will involve gathering this data.

-Brian

Wednesday, February 9, 2011

The lag problem appears to be solved on my laptop.

I inserted one line in the call_gps() function, and it seems to have solved the problem.

The line was
gps.flushOutput()
The video shows how the gps is performing in the space.

video

Monday, February 7, 2011

Front Encoders Mounted and Tested

 Encoders
Today I completed the fourth encoder and mounted encoders 2-4 on the front wheels. Next I created a power rail for the encoders and connected them to the Arduino. After testing each encoder to ensure it was working properly, I tested the accuracy of encoders under motion. I noticed some variation between encoders, but even after 20+ meters the difference was minimal unless one of the encoders stopped on the borderline of a segment then it would trigger on/off repeatedly until moved again. I believe this error is due to the relative size of the segments in comparison to the actual encoders and I feel that a form of averaging could be utilized to compensate for the error programmatically.  

TO DO
Now that these encoders are done, I will focus on establishing more robust code to handle both front and rear encoders. While I am waiting for the new encoders to arrive, I will split my focus between refactoring my code and setting up the Sharp Long Range IR Sensors.






Video

video

Up periscope

Here is the new look for the robomagellan platform:

The shell has had a couple of modifications: First, the magnet sensor has been moved up several inches. Andy claims that the proximity to the laptop caused magnetic interferance, so he attached a board to the sensor and gave the platform a central periscope. I felt that the sensor was too exposed, and returned it to its project box, but utilized the wooden board to raise the whole box up into the air.The kill switch has been giving us trouble... read Andy's previous post for more info on that. So I thought the best solution was to extend the receiving antenna with some extra wire. I wrapped a double wire around the exterior of a carbon composite tube to create a helical antenna.

The range on the kill switch appears to be greater, but we will have to test it in the field to be sure.

Saturday, February 5, 2011

We need a FUNCTIONAL killswtich...

The killswitch is still ineffective. It will not pass inspection at the competition. I have no idea why on earth it still refuses to turn off. I can follow 5 feet behind it, press "OFF" or hold it in all kinds of ways until my thumb falls off, and it still does not die, even with this new switch with an antenna. This failure to stop resulted in irreparable damage to the ultrasonic range finder. (cont....)

Google Code Repository

There is an new google code repository at

Brian is taking the lead on organizing this. You should all get invites and please organize arduino code and python code into separate areas.

Thursday, February 3, 2011

Digital range finder code

Here is some sample code for interacting with the digital range finder.



CODE BEGINS:
----------------------------------------------------------------------

import serial
import pygame
from pygame.locals import *
import time
import math
from visual import *
import threading

init = 1

try:
sonic = serial.Serial(7,baudrate=9600, bytesize=8,parity = 'N',stopbits = 1,timeout=None, xonxoff=0, rtscts=0)
sonic.open
except:
print "Sonic range finder not connected or bad COM port number"
quit()

def parsesonic():
hold = 'a'
while(hold != '\r'):
hold = sonic.read()
sonic.read()
distance = sonic.read(3)
return int(distance)
class object_avoidance_thread(threading.Thread):
def run(self):
while True:
if (parsesonic()< 24):
print "woah man you're too close\n"

while(1==1):
if init == 1:
object_avoidance_thread().start()
init = 0
-----------------------------------------------------------------
CODE ENDS:


The above code causes the robot to output a string whenever an object is closer than 24 inches to it.

Current Tasks

  • Verify Functioning Encoder On Robot
  • Modify Program to Handle Four Encoders
  • Encoders 2 - 4
  • Connect to Arduino chip
  • Refactor Encoder Code
  • Incorporate Sharp Long Range IR Sensors

Encoder Success

video
Mounted Encoder
This video showcases a mounted and functioning wheel encoder and verifies that the programming is recording one full rotation correctly at 6.28 radians per rotation.

Remote Kill Switch

The saga of the remote kill switch really should be documented.

I am bringing in another remote kill with a 15A relay inside.

(www.datasheetcatalog.org/datasheets2/10/104158_1.pdf)

I used spade connectors. Please use these when joining wires as it will save us lots of grief down the road. Place a bit of solder on the connection and then wrap them in electrical tape.

Lets get the remote kill switch back in action so we can start driving again!

Tuesday, February 1, 2011

Video Update: Autonomous Control

video

Encoder Update

Encoder Snag

I hit a minor snag in designing the encoder chip. I completed the circuit on Sunday to find out on Monday that one out of four connectors functioned. Turns out I was reading the 5 band mini resistors incorrectly instead of being 11k OHM resistors they were 1k OHM and I blew two detectors. I learned my lesson about making sure to have my DMM with me. Fortunately, I had ordered some detectors from sparkfun a week ago so I am moving forward with reconstruction of the sensors. This time I am focusing my efforts on fusing the chip to each encoder instead of on a single board to minimize confusion. In addition, I modified the code to allow for 4 sensors. Currently, I need to focus on learning how to write functions in the Arduino language because much of the current code is heavily redundant. I have read the data sheet on the Sharp Long Range IR sensors and expect that construction / implementation should be relatively easy after the encoders are done.

Quick Cone Detector

Here is a quick demo of a cone detector. It returns the x,y coordinates of the center of the cone and the vector from the center of the frame (presumably where the robot is pointing) to the cone.

video
I will post a python snippet when we get to it, but this should give you guys an idea of the range of the cone detection (10 feet or so)

This reminds me that we need to get some cones. Please contact maintenance and public safety to see if we can borrow a couple of standard road cones. If not, I will buy some, but they are not cheap.


Computer vision requires massive CPU utilization so the cone detector will only run at 10 Hz or so.