300 likes | 390 Views
Team Muskie. Geostationary Fishing Boat Motor Control December 2, 2004 Team Members: John Mashburn, Neil Smith, Henson Rara. Team Muskie. Introduction:.
E N D
Team Muskie Geostationary Fishing Boat Motor Control December 2, 2004 Team Members: John Mashburn, Neil Smith, Henson Rara
Team Muskie Introduction: The direction control of current electric trolling motors used in small fishing boats are controlled by a mechanical link to a foot pedal. Operation is awkward at best, clumsy and frustrating at worst. This makes the fishing experience less enjoyable.
Team Muskie Introduction: We set out to replace the foot pedal control with something more elegant. We decided to use GPS combined with a digital compass to create a system that would allow the user to forget about operating the trolling motor and worry about fishing. Our original concept was designed around Walleye fishing.
Team Muskie Introduction: Walleye tend to be found in schools that stay near a single location. Keeping a boat near a single location is difficult because wind and currents will tend to move the boat and the operator has no local reference points. A system designed around GPS would be able to maintain a stationary position without any local reference points.
Team Muskie Introduction: Basic Operation Specifications: • Define Hot Spot • Check Drift for out of bounds state • Perform Position Correction
Team Muskie Objective: To Prove the Concept. Our goal was to build a test platform that demonstrates the feasibility of the concept and to provide a benchmark for further development.
Team Muskie Objective: System Operation Specifications: • Allow user to define Hot Spot and store location in memory. • User will select manual or automatic operation. • Once in automatic mode, the system should check that the current location is within a preset distance from the hot spot. The boat will drift freely when in this state.
Team Muskie Objective: System Operation Specifications: • When an out-of-bounds condition is detected, the system should correctly identify the direction of travel needed to return the boat to the vicinity of the hot spot. This position correction should be done smoothly and cause no dangerous boat movements. • While correcting position, the system should monitor distance in order to stop the drive motor and return the boat to drifting.
Team Muskie Original Design:
Team Muskie Build and Testing: Problems Encountered: • The GPS unit was the only source of feedback. When the system initially detects an out-of-bounds condition, the drive motor needs to be turned on. This is a problem because the direction of thrust is unknown at the moment of turn-on. In order to use the GPS to calculate a velocity vector the boat must be moving. If the direction is unknown for a period the boat could be moving in the wrong direction, a dangerous manner or otherwise undesired fashion.
Team Muskie Build and Testing: Problems Encountered: • The resolution of the Motorola GPS unit is unacceptable. When we tested it outside, it reliably resolved half the width of the quad. • The H-bridge driving the angle adjustment motor produced transients that feed through the microcontroller and disrupted the optical switch. This meant unreliable control of the direction of motion.
Team Muskie Build and Testing: Noise in Optical Switch Without Proper Isolation Multiple Edges Erroneously Counted by Edge Triggered Counter Pin in Microcontroller.
Team Muskie Build and Testing: Solutions: • We tested a Garmin GPS 12XL unit as a possible replacement since it had the option of differential GPS built in. The Garmin unit was more precise than the Motorola unit. So much so that we could reliably use data from the Garmin unit without the differential option. • The addition of an 8-direction hall effect compass allowed us to directly ascertain the direction of the motor upon the initial out-of-bounds detection.
Team Muskie Build and Testing: Solutions: • Simple capacitive filtering was not enough to suppress the motor transients. However, removing the electrical connection entirely through the use of optoisolators did solve the problem. Microcontroller PWM/GND H-Bridge PWM/GND Note: No Physical connection between PWM pins
Team Muskie Build and Testing: Optical Switch Noise Free After Utilization of Optoisolator
Team Muskie Build and Testing: Other Problems: • Time prevented implementation of high-current drive for propulsion motor. Implementing this would require only the inclusion of a driver and additional optoisolators. • Currently the boundary is defined by a square, a circle or approximation is desired.
Team Muskie Challenges and Successes: The first challenge was how to use rectangular coordinates to determine a meaningful operation to perform with the motors. Our first brainstorming session yielded a very plausible solution: Polar coordinates.
N Θ r W E S Team Muskie Challenges and Successes: First we must define an origin and polar coordinates for positions.
N Vector to current position θ Hot Spot W E Φ Direction of Travel S Team Muskie Challenges and Successes: First we must define an origin and polar coordinates for positions. Compare angle of hot spot to current point vector and current heading.
Team Muskie Challenges and Successes: First we must define an origin and polar coordinates for positions. Compare angle to hot spot coordinates and current heading. Difference in angles yields the necessary correction. N Vector to current position Hot Spot β=angle correction needed W E Direction of Travel S
Team Muskie Challenges and Successes: • Infrared beam cutter circuit design and testing. • H-Bridge circuit design and orientation. • Two sided PCB board design for • IR beam cutter circuit • Digital compass • H-Bridge
Team Muskie Challenges and Successes: Another challenge was how to deal with the data in ASCII format provided by the Garmin GPS. $PGRMZ,772,f,2*18 $PGRMM,User*58 $GPBOD,,T,,M,,*47 $GPRTE,1,1,c,0*07 $GPRMC,163827,A,4006.649,N,08813.700,W,000.0,003.8,271004,002.2,W*78 $GPRMB,A,,,,,, $GPGGA,163827,4006.649,N,08813.700,W,1,03,8.5,235.3,M,-33.8,M,,*79 $GPGSA,A,2,,,,,16,,,23,25,,,,8.5,8.5,*1C $GPGSV,3,1,10,01,34,137,00,03,30,150,00,06,03,032,00,13,36,314,30*7B $GPGSV,3,2,10,16,65,052,38,19,07,170,00,20,26,220,00,23,74,297,45*71 $GPGSV,3,3,10,25,28,083,41,27,05,279,00,,,,,,,,*77 $PGRME,33.2,M,,M,33.2,M*00 $GPGLL,4006.649,N,08813.700,W,163828,A*32 $PGRMZ,772,f,2*18
Team Muskie Challenges and Successes: $PGRMZ,772,f,2*18 $PGRMM,User*58 $GPBOD,,T,,M,,*47 $GPRTE,1,1,c,0*07 $GPRMC,163827,A,4006.649,N,08813.700,W,000.0,003.8,271004,002.2,W*78 $GPRMB,A,,,,,, $GPGGA,163827,4006.649,N,08813.700,W,1,03,8.5,235.3,M,-33.8,M,,*79 $GPGSA,A,2,,,,,16,,,23,25,,,,8.5,8.5,*1C $GPGSV,3,1,10,01,34,137,00,03,30,150,00,06,03,032,00,13,36,314,30*7B $GPGSV,3,2,10,16,65,052,38,19,07,170,00,20,26,220,00,23,74,297,45*71 $GPGSV,3,3,10,25,28,083,41,27,05,279,00,,,,,,,,*77 $PGRME,33.2,M,,M,33.2,M*00 $GPGLL,4006.649,N,08813.700,W,163828,A*32 $PGRMZ,772,f,2*18 $PGRMM,User*58 $GPBOD,,T,,M,,*47 $GPRTE,1,1,c,0*07 This block repeated every 2 seconds
Team Muskie Challenges and Successes: PIC program recognizing chosen header:
Team Muskie Challenges and Successes: • USART (RS-232) I/O aided debugging, data stream output in HyperTerminal • Implementation of arcTan via look-up-table including wrapper to correct for quadrant yielding 360 degree output domain • Conversion of compass output to angle for calculations • Difficulty in angle comparison made simpler by using octants. • Fluency in assembly language
Team Muskie Future Development: • The use of sign and magnitude made calculations difficult. We would replace this with a magnitude only convention to greatly simplify calculations. • A different compass or additional compass to increase resolution if needed at initial start up. • Define drift boundary by octagon or other circle approximation. • Second boundary needed to define end of position correction. • Optimize components for battery operation
Team Muskie Demonstration:
Team Muskie Demonstration:
Team Muskie Demonstration:
Team Muskie Demonstration: