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)

Magellan Update

For 2015 the platform is using the following hardware:

• Winbook 701  (Intel Baytrail tablet running windows 8.1)
• Logitech 902 Camera 
• Neo 6M GPS
• Razor 9 IMU
• 6 HCS-04 Sonar Sensors
• 70cm Telemetry System
• Hall Effect Quadrature encoders
• Dual Front Bump Switch and Start Button

Major hardware changes for the year include replacing the odroid U2 that we used for AVC with the winbook.  The odroid would not allow us to run the vision software which is windows based.  The winbook has had the following issues:

• Power management issues:  The charging circuit doesn't seem to keep up with power demands during heavy use.   The winbook uses more power then the odroid and needs to be on shore power when on running. 
• Remote desktop.  Since the winbook can only run windows 8.1 home, there is not remote desktop functionality.  A wrapper was written to emulate all remote desktop functionality under a different process so that windows can't kill it. 
• VNC is also used to mirror the winbook when preparing for a run.  This is slow due to the nature of NVC.
• There are challenges with device drivers with windows 8.1 especially with prolific usb->ttl drivers.  In addition the FTDI driver renders devices unusable on any platform requiring the use a linux program call ft232r to reset the PID on the device. 

Additional challenges:

• The usb hub is having problems with devices connecting and disconnecting.

January 29, 2015 Update

Author: Andrew Thai

Overview

Tommy and Trent had gotten one of the coffee makers to work, which may be temporary to today.

First, the servo that Tony installed was secured with a 4-40 screw because the original servo servo was lost and Jason continued research in getting the maps to work with what seemed to be success with downloading a map. Afterward, Jason and Andrew Moved outside and set up the platform for testing. Jason had to go to class, and Ariel had arrived. Ariel created a new course file (testCourseEasy 1-29-2015.txt) which seemed to be more accurate on his iPhone. Both worked on compass calibration with changing the compass.csv file, the file called in the IMUModule, again using Ariel's iPhone. Tommy showed up early from class, and helped run the robot. The behavior of the robot was odd, stopping until nudged forward, where it would then run full speed for a second and going in odd directions. Ariel and Robot, who were monitoring the outputs, saw that we kept losing  serial data. Tommy advised that we may want to try to use the second USB hub that Professor Mason offered for use. The second run, we had decided to use tightVNC to be able to see the prints. We had noticed that the platform will fall into a pattern where it will briefly load GPS latitude and longitude, stop loading and moving anything for a couple seconds, then spam avoid prints (unsure which side). Magellan will proceed to run in a circle or an unknown direction, and repeat the process. Tommy and Andrew suspect that it is either the encoder code or the object avoid code not working and now have Robert, guided by Tommy, is writing a go forward test code (which comes with a 10ftest.txt file) based on the RobotControlBuilder2.py code. Ariel and Andrew quickly reviewed and adjusted the attributes for the servos in RobotControlBuilder2.py before the day ended.

Issues

-Robot is not running course correctly, speculated to be due to object avoidance or encoder errors 

-Have Not Actively Used Telemetry for debugging purposes

-IDLE screen text hard to see while robot is running

New To-Do

-Telemetry: Actively Test Telemetry

-Test Encoders

  If Not Problem, Test Object Avoidance

-Adjust Rear Servo Horn

-Change IDLE text of shell during runs

-Replace USB Hub

Previous To-Do's

-Get/Change Roll Cage

-Replace Sonar Mounts (or replace when they break)

-Angle Mount for Tablet (to save room and easier use)