Weekly Updates

02/22/2001 - 03/01/2001

• Discussions ensued with Dr. Huggins and Dr. Ahn about the control algorithm that we are going to use for the vehicle.  We discussed many varieties of these algorithms and decided that the inherently more accurate heading information was a better approach than previous method of using just the latitude and longitude information.  The use of the GPS heading which will correspond with an external digital compass will allow the autonomous mode of operation to operate more accurately.  Well, in theory anyway.
• Started to transfer the linear actuator circuitry from the somewhat entangled breadboards to a perf board.  Thus far it has been decided that all the power circuitry will go on one board, all low power on another, and the digital compass on yet a third board.  Construction of the power board has just begun; therefore, much more work must be done in future labs to complete this portion

02/14/2001 - 02/21/2001

• We continued work on the drive control that includes the relay as well as a resistor to dissipate some energy and slow down the forward speed.  However, we were going to implement a PWM control to allow for a more accurate control of the speed, but by suggestion, we will simply use a resistor and a relay so as to allow for more time to work on the more crucial steering algorithm. 
• For the latter part of Thursday and Tuesday morning, we discussed different control concepts with both Dr. Ahn and Dr. Dempsey.  The final judgment is to implement a PI controller.  The block diagram and signals for this are described in lab documentation.  We have begun to code the PI controller, but implementation is started only on the proportional part of the controller.  The integrator will be applied after we see that the proportional controller is giving results.
• Extended planning on the steering control involves using the next waypoint as a reference and then finding the steering angle.  Then a digital compass will be used to find the heading (or GPS heading information could be used) and that angle will be used to determine the error signal and correction.  We anticipate oversteer at this point so our first consideration is the stability of the system. 
• Spent entire lab time taking data with the beacon receiver.  Results in general were not very good at all.  Some sessions proved very stable but not consistently enough.

02/07/2001 - 02/13/2001

• We continued working on the steering and linear actuator control.  The steering now successfully moves through seven different positions, full-left, center, full-right, and four equally spaced positions on either side of the center position between the center position and full extension.
• Finally got the data from the G8 into usable data for calculations.  This includes an array of integers, each one holding the place for its respective power of 10, and one floating-point value representing the entire value with only the precision necessary to know our position in this small geographical space.
• Received the differential beacon on Friday, Feb 9.  We assembled the unit and began measurements and testing.  So far, the results are not significant.  In fact, assuming the unit is being used properly, it offers no added accuracy.  We need to investigate a little further and be sure that we are using the beacon correctly.  There is also the chance that the evaluate software isn’t setup properly to be used with this particular beacon.
• While investigating the drive motors, we found out that we were too comfortable with assuming that the in-line resistor was there for the speed-limiter, when in fact, it is not.  To limit the speed, the design uses a series wiring of the motors.  So at first speed, each motor has a voltage drop of 6V (if they are equally balanced).  At second speed, the motors are in parallel, and they receive the same 12V drop from the battery on both.  What we initially would like to try is a parallel configuration, with 6V across each motor.  This will ensure that each motor receives the same voltage and should help the vehicle to drive in a straight path.

01/31/2001 - 02/06/2001

• Converted assembly language actuator program into C code.  Functions are the ability to center itself and can give a parameter to move the rod in 5mm increments to either the left or right.
• The serial port was simply reading the data in, and then writing it out to hyper-terminal for testing purposes.  We allocated memory for the data to be stored and processed.
• Worked on assembly level software to convert the ASCII data values from the GLL message into usable integer values.  They exist in an array form right now, so I am trying to understand how to pass C code pointers to assembly code and use them as data pointers to reference the array.  
• Spent approximately 10 hours preparing the presentation for the project update.

01/21/2001 - 01/30/2001

• Continued working on the serial interface between microprocessor and the G8 evaluation board.  There were problems with the communications so we used HyperTerminal on the PC to send the data  since it was easier to see what the G8 was actually outputting.  Very random errors were occurring and microprocessor would often reset.
• Received compiling errors saying that we had insufficient memory.  Discussed this with Mr. Mattus and fixed this problem (thought it might be related to our serial communication problems).  We must compile as a LARGE file so that the default memory location is in the external data.  Then we only label a variable as internal data when we require speed or many other reasons.
•  Finally discovered that we must disable the interrupt after it is called.  Then, during this interrupt, the transmit and receive code may be run and subsequently the interrupt is enabled before it returns from the interrupt.  Apparently it was INTERRUPTING ITSELF!!    Code ran bug free and we were able to filter out only the latitude and longitude components of the NMEA string.

01/14/2001 - 01/20/2001

** First off we just started this section today (Jan 20) so we are going to have to work backwards so we will be filling it in as time allows.

• Finalized the purchase of Magellan DBR-4 DGPS beacon receiver at eTronics.   Specifications and picture can be found here.

• Researched programming in C for the EMAC board using the C51 ANSI C compiler by Keil Software.

• Researched serial communications with the EMAC board.  Using the serial ports on the EMAC board is not as simple as just using the built in serial port of the 8051.  This serial port is already attached to the computer and is what the monitor and debugging tools use to communicate with the microprocessor.  Because of this the other two serial ports (3 in all) are the only ones that are able to be used and they are completely different (and more complex) than the standard 8051 serial port.  After much research the final code can be found here.

01/07/2001 - 01/13/2001

• Received Ashtech G8 evaluation kit and OEM board, three LMD18200T h-bridge chips, Vector digital compass, and a Warner linear actuator.

• Built and tested hardware for controlling the linear actuator.

• The LMD18200T has three inputs all at TTL levels: 

  • PWM (pulse width modulation)

  • Brake (high=off     low=on)

  • Direction (high=fwd   low=rev)

• Wrote program for EMAC to control the linear actuator.  This basically just turns P1.1 on or off to control brake input and P1.0 to control the direction.  Also P4.1 is turned on and off using a 100Hz interrupt to achieve PWM with 50% duty cycle.  A very important feature is the centering routine.  This routine uses the feedback provided by the internal potentiomter and A/D channel 1 to monitor the position of the rod.  After calculating the exact center position, this routine will automatically return the actuator to its center position and then turn the brake on.  Pressing certain button on keypad do various things:

  • 1=Forward

  • 2=Reverse

  • 3=Brake on

  • C=Brake off

  • 4=Center

• Accuracy of Ashtech G8 Sensor was evaluated.  Long pole had to be fabricated (lots of duct tape) so that antenna could be placed far enough out the window to lock onto satellites.  After many tests it is clear that GPS is not near enough accurate to keep the vehicle on the sidewalk.  In every test the position strayed in various directions and most of the time it strayed out of a 10m radius from where it said it originated.

• These inaccuracies definitely need to be controlled so after discussions with Dr. Huggins and Dr. Ahn it was decided that we either implement the digital compass to offset some error or find a cheaper beacon receiver (to get differential GPS).

  • Differential GPS (DGPS) uses what is called a beacon receiver to receive a radio signal from the U.S. Coast Guard that has corrections embedded in the signal.  These corrections are then sent to the GPS receiver via a RTCM SC-104 link where the receiver makes the necessary calculations to offset the inaccuracies.  This signal is broadcast for free and as long as you are in their coverage area you can have DGPS for no more money than it costs to buy the equipment.

• Many different receivers were found:

  • CSI ASX-3 Beacon Receiver ($700)

  • Magellan DBR-4 Beacon Receiver ($300)

  • Lowrance DGPS Beacon Receiver ($372)

• We decided on the Magellan receiver.

• The software provided by Ashtech called Evaluate enables one to view the position of the antenna, satellites that the receiver is locked onto, and it does some standard deviation calculations and such but the graphing isn't very good.  There is no zoom, no auto scale, and it is difficult to measure distances on the graphs.  It does however let you log data to a text file so that you may replay later.  Therefore, a Matlab program was written to read these log files and then graph the data.  Click here for more information and code.