February 18, 2015

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.

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.

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.

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

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).

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'

February 2

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)