Overview:
It turns out the GPS problems yesterday was due to activating NMEA child messages instead of just GxGGA messages when checking if the GPS was getting latitude and longitude. Also, the repeating latitude and longitude is due to RobotControlBuilder.py printing the lat and long before an actual refresh of the GPS data. We found this out from putting our print statement information on an excel sheet and noticing that the lat and long output from parseGPS and RobotControlBuilder2.py were different. The GPS does not refresh regularly. Other than this, we ran the course and saw similar behavior as last week, where the robot was going in odd directions, which can be attributed to the inconsistent GPS as well as bad GPS data (sometimes the GPS will output -2.XX e^-XX for lat and long). We have not checked if it is the heading that was wrong, though we have calibrated it before and worked fine when doing testFindCone.
Wednesday, February 18, 2015
Tuesday, February 17, 2015
February 17, 2015
Overview:
Continuing from yesterday's problems, we are unsure on how to make the GPS spit out lattitude and longitude in the NMEA data. We reinstated the settings in the GPS based on the profmason website for ucenter in hopes that would fix the bad GPS data, where the latitude and longitude are constantly the same value.
After trying to run RobotControlBuilder2.py and other various modules, it seems that our python code was not reading our modules. For example, plugging in the IMU directly and running the IMUmodule.py, the output would be that the IMU was not started and only sometimes output a value of 2.0 instead of ("IMU, cannot be started"). In Arduino however, I was able to see all the raw values in the serial monitor. This meant this new problem was due to threadedserial, which had been modified last Friday (Feb. 13).
class ThreadedSerial( threading.Thread ): def __init__( self, module, serialPort, baud, command = 0 ): super(ThreadedSerial, self).__init__() self.name = module self.data = 'No Data' self.vars = {'reading':0} self._vars = {'running':0,'working':0,'override':0,'interrupt':0,'writing':0} self.vars['command'] = command self.ser = serial.Serial( None, baud, timeout = .1 ) self.ser.port = serialPort - 1 self.openPort( )
The issue was "self.ser.port = serialPort - 1," which while trying to run did not have the "- 1" included. After adding the -1 back into the code, all our modules worked again.
Thursday, February 12, 2015
February 12
Overview:
Similar to yesterday, there was interference with working the Magellan platform due to two problems. The first was that the wireless on the tablet kept crashing, and started to work after repeated restarts. Though it took a long time for the tablet to recuperate and connect to wireless, this problem seems integral to the win-tablet's own hardware specs. Second, more importantly, was the Communication Ports (COM ports) of the IMU, Telemetry, and GPS were switching and the hub itself was repeatedly connecting/disconnecting while attempting to run any code. Tomas, Ariel, Robert, and I determined that we must change the current hub and FTDI serial connection set up because of the fickle behavior. At the end of the day, Tommy and I were able to get the IMU communicating with the Arduino Mega, borrowed from the VEX room, but unsuccessfully returning Telemetry. Both members agreed that the Telemetry and the GPS must be on it's own modules because the GPS must be detectable by UCenter, the GPS software of choice, and the Telemetry because it must read from the USB serial instead of print to like the IMU, Sonar, Econder, or Bumper modules.
Similar to yesterday, there was interference with working the Magellan platform due to two problems. The first was that the wireless on the tablet kept crashing, and started to work after repeated restarts. Though it took a long time for the tablet to recuperate and connect to wireless, this problem seems integral to the win-tablet's own hardware specs. Second, more importantly, was the Communication Ports (COM ports) of the IMU, Telemetry, and GPS were switching and the hub itself was repeatedly connecting/disconnecting while attempting to run any code. Tomas, Ariel, Robert, and I determined that we must change the current hub and FTDI serial connection set up because of the fickle behavior. At the end of the day, Tommy and I were able to get the IMU communicating with the Arduino Mega, borrowed from the VEX room, but unsuccessfully returning Telemetry. Both members agreed that the Telemetry and the GPS must be on it's own modules because the GPS must be detectable by UCenter, the GPS software of choice, and the Telemetry because it must read from the USB serial instead of print to like the IMU, Sonar, Econder, or Bumper modules.
To-Do:
-Change HUB and FTDI serials
-Fix the getting close to cone from a couple feet away
-Fine-Tune turn parameters
-Integrate code from testFineCone to RobotControlBuilder2 afteward
-Run Full Course
Thursday, February 5, 2015
February 4, 2015
Log:
-Feel like the robot is going the same way (around 30 degrees on my phone) because running it consecutively showed that it went straight that way instead of turning
right like usual
~Might be the heading code newly put into
the drive loop
-Inputed debugging strings to output heading and distance. The heading values in raw
heading (IMUModule) and heading in testFindCone are different.
~The heading Magellan should have is around 278 according to IMU on robot. The heading
went from 23X to 4X, so it seems that this heading value and PID toward it
does not accomplish anything. I believe the turning/oscilation exhibited was due to
each new heading extracted from being in mid-turn. In the beginning however, the
robot is turning in the direction the cone is at. Once overshot, the robot
just oscilates into a straight line.
-Debug print of coneDirection showed that coneDirection heading was 0, which is why
Magellan goes in the same direction away from the cone.
~After consulting robert, we decided to have the robot find which direction the cone was
at, turn toward it's current heading +- 20 depending on the direction until it sees
the cone again via peaking at the camera. If the robot sees the cone, it will change
the difference in heading to 5 until the cone is centered on the screen. We will
reuse much of Ashuai's code from RobotControlBuilder2, which facilitates this.
-First and second run showed odd behavior, with much studdering with which direction
to turn.
~Need debugging print values to see
what is wrong
-Jason noted that instead of "coneDistance" we should be using "coneDirection" (typo).
Behavior was twitchy, adjustHeading was not being updated, but when the robot saw
the cone, it moved forward and the rest of the code was able to bump it.
~Need to debug twitchyness
-Observed that the robot went the opposite way and turned right when the cone was
left.
~The coneDirection was being modified oppositely by
adjustHeading by adding positive values and subtracting negative
values (hence, going right instead of left).
-Feel like the robot is going the same way (around 30 degrees on my phone) because running it consecutively showed that it went straight that way instead of turning
right like usual
~Might be the heading code newly put into
the drive loop
-Inputed debugging strings to output heading and distance. The heading values in raw
heading (IMUModule) and heading in testFindCone are different.
~The heading Magellan should have is around 278 according to IMU on robot. The heading
went from 23X to 4X, so it seems that this heading value and PID toward it
does not accomplish anything. I believe the turning/oscilation exhibited was due to
each new heading extracted from being in mid-turn. In the beginning however, the
robot is turning in the direction the cone is at. Once overshot, the robot
just oscilates into a straight line.
-Debug print of coneDirection showed that coneDirection heading was 0, which is why
Magellan goes in the same direction away from the cone.
~After consulting robert, we decided to have the robot find which direction the cone was
at, turn toward it's current heading +- 20 depending on the direction until it sees
the cone again via peaking at the camera. If the robot sees the cone, it will change
the difference in heading to 5 until the cone is centered on the screen. We will
reuse much of Ashuai's code from RobotControlBuilder2, which facilitates this.
-First and second run showed odd behavior, with much studdering with which direction
to turn.
~Need debugging print values to see
what is wrong
-Jason noted that instead of "coneDistance" we should be using "coneDirection" (typo).
Behavior was twitchy, adjustHeading was not being updated, but when the robot saw
the cone, it moved forward and the rest of the code was able to bump it.
~Need to debug twitchyness
-Observed that the robot went the opposite way and turned right when the cone was
left.
~The coneDirection was being modified oppositely by
adjustHeading by adding positive values and subtracting negative
values (hence, going right instead of left).
Tuesday, February 3, 2015
February 3, 2015
Overview:
Following yesterday's runs where Magellan would not find the cone, today, testFindCone.py was made to test the cone finding code specifically in RobotControlBuilder2.py. After tuning, some resolutions were made:
-In RobotFunctions.py, line 202-258, the proportional variable for turnpower is now proportionalTurn instead of a hard coded number (which is now 20 instead of 50 previously), and the drive forward when the cone is straight ahead has changed from a non-PID function to a PID function that takes heading every 4 ticks (one rotation).
-Some variables were changed (such as turn power) to allow less dramatic turning when moving toward the cone
Currently, testFindCone,py takes in a file, but does not use it. Inputting a file is mostly to prevent code from breaking as various variables have hard coded numbers for testing, such as coneDistance = 20#coneDistance = 6 * abs(superbot.angle_fix( coneDirection, heading ))/180 + 2 [line 139]. Near the end, we had realized that if the robot goes into programming mode at all, many of the settings are reset. An issue when testing for the robot to approach the cone from a couple feet away (in code, it is indicated in print as "print "Went towards cone 10 ft" " in lines 141 to 149), the robot would not initiate movement unless pushed. This was due to the speed controller being in brushless mode. We tested this hypothesis by running when the robot sees the cone and moves forward, where Magellan exhibited the same behavior. Since Robert, Ariel, and Tommy had to leave for elec10, Andrew stayed behind and reprogrammed the speed controller for tomorrow's use.
To-Do:
-Fix the getting close to cone from a couple feet away
-Fine-Tune turn parameters
-Integrate code from testFineCone to RobotControlBuilder2 afteward
-Run Full Course
[Previously Mentioned Line 202-258 in RF)
if (cone_X > robot.width/2 + tolerance):
#advance right
coneSeenFlag = True
direction = True
turnpower = turn_offset-int(2*(robot.width/2-cone_X)/robot.width*proportionalTurn) + cone_size / 100
#print "Turn Power",turnpower
robot.turn(turnpower)
robot.setDesiredVelocity( conePIDtarget )
if direction == False:
robot.motorPower = 35
robot.drive( robot.drivePID( ) )
robot.drive( robot.drivePID( ) ) #For Spooling
time.sleep( .15 )
last_visible = "right"
print 'going right ',turnpower
#no? well then is it to the left?
elif (cone_X < robot.width/2 - tolerance):
#advance left
coneSeenFlag = True
direction = True
turnpower = turn_offset-int(2*(robot.width/2-cone_X)/robot.width*proportionalTurn) + cone_size / 100
#print "Turn Power",turnpower
robot.turn(turnpower)
robot.setDesiredVelocity( conePIDtarget )
if direction == False:
robot.motorPower = 35
robot.drive( robot.drivePID( ) )
robot.drive( robot.drivePID( ) ) #For Spooling
time.sleep( .15 )
last_visible = "left"
print 'going left ',turnpower
#no? well then is it in the middle?
elif ((cone_X < robot.width/2 + tolerance)&(cone_X > robot.width/2 - tolerance)):
#advance straight
heading = robot.modules['imu'].getHeading()
robot.setTarget(heading)
robot.turn( robot.PID( ) ) #Start Turn
coneSeenFlag = True
direction = True
if last_visible == "left":
robot.turn(-10)#100 should be
elif last_visible == "right":
robot.turn(10)#100 should be 10 test
else:
robot.turn(5)#0
robot.setDesiredVelocity( conePIDtarget )
if direction == False:
robot.motorPower = 35
for i in range(4):
heading = robot.modules['imu'].getHeading()
robot.turn( robot.PID( ) ) #Start Turn
robot.drive( robot.drivePID( ) )
time.sleep( .05 )
#robot.drive( robot.drivePID( ) ) #For Spooling
#time.sleep( .15 )
last_visible = "center"
print 'going straight'
Monday, February 2, 2015
January 30, 2015 Update
Overview
-After testing, we found the encoders are working correctly, and previous jerking is likely due to object avoidance or serial issues
-Adjusted servos and steering for greater accuracy
-RearBump shouldered with pin, but still losing connection with Encoder Arduino Uno
-Repaired USB Hub, successful (Thanks to Ariel's Expert Shouldering)
[Robert's Video of going forward and reverse test]
Issues
N
To-Do List
-Telemetry: Actively Test Telemetry
-Test Encoders
If Not Problem, Test Object Avoidance
-Get/Change Roll Cage
-Replace Sonar Mounts (or replace when they break)
-Angle Mount for Tablet (to save room and easier use)
Subscribe to:
Posts (Atom)