Feint Kiss

[Tom Harper]

A couple of weeks ago I was looking for a tutorial on RC UAV when i ran across the Way Point Sequencer thread. MX, LukeZ, MR. RC CAM et al provide a lot of insight into the problem and it's solution. But MR. RC-CAM's statement was a grabber:

"PIC18Fxxxx based waypoint engine design that utilized a low parts count board, that could determine bearing and distance to a route with a half dozen waypoints, and that included a simple user interface using a serial port connected PC. That alone is a huge project. It would be very easy to expand it from there (open source it)." He also admonished to KEEP IT SIMPLE.

I gave it some thought and came up with a plan. First limit the problem to the range of an RC model since that is the most common application. I chose square of 4 nautical miles. A nautical mile is 6080 feet. Now consider the (4 mile square) matrix as an overlay on a map of your geography of interest. If you register the lower right corner of the matrix on any point in Lat and Lon then any point in the matrix can be represented to a resolution of one foot with an (X,Y) pair of integers whose max value is 24, 320. Which fits nicely into a 16 bit binary integer.

This is an open code project. Anyone who wants it for hobby purposes can get a copy by sending me a PM with their email address. No charge but if anyone makes a PC board, I wouldn't object to a couple. The acronym? Flat Earth INTeger system - Keep It Simple Stupid.

For way points you could either use the UART or a small pin matrix in the airplane. Each of 65,000 way points 100 ft apart can be identified with only two 8 bit digits. I think the way to do it is have modes:

00 - Entered by UART
01 - Search grid calculated by the controller - starting coordinates in pin board
10 - line pattern, starting points in pin board and delta of each new pair in pin board
11- ?

The approach I am using is to develop some tools first, write the code in a symbolic language, test it with an emulator then convert the controller code to assembly language for any processor of interest. My target is the TI 16MHz, 16 bit, 2k ROM processor. It's a nice architecture and sells for less than $2 from DigiKey. The processor will interface directly with an OEM GPS block so it probably will not have all of the sentences. I am assuming the basic $GPGLL sentence. The processor does everything else.

So far I have the following:

1 - The core routines of the controller. These are integer routines that use microprocessor algorithms. Sixteen bits is enough for most operations. The sum of squares needs a 32 bit integer. I use reduction by sequential squares for square root. There are three tables: a 32 line table for Arc Sine*128, a 32 line table for Sine*128 and an 8 line table for expanding Arc Sine above ~60 deg. I estimate the present code to be less than 600 lines in assembly language.

The waypoint aquisition radius is proportional to the speed of the model and can be set by the user. When a waypoint is acquired the rudder is set to zero, a new waypoint is calculated and the old one is cast off. Then control resumes.

2 - A pair of Excel worksheets are used as an interface between the controller and the emulator. One worksheet contains the list of waypoints - presently in full lon/Lat but they could be in 8 bit matrix coordinates. The second worksheet contains the Lon/Lat coordinates calculated by the emulator as the present position of the model. This is based on the speed of the model, the rudder setting, wind strength and direction and the last position of the model. The controller reads this list as though it were the output of the GPS. At present I do not use sentence format but will when I write that part of the program. In the row from which it gets the new position the controller writes all of the values used in calculating it's actions. This is vital for debugging.

3 - A software emulator in VB6. The emulator reads the control settings taken by the controller, adds wind (or whatever), calculates the new position of the model and places the result in the Excel worksheet. It also presents a scale representation of the flight on the computer screen.


The basic thing is working. I'm no navigation genius. I just got out my Plane Geometry book and the Analytic Trigonometry book - I must have taken the courses because they have my notes in the margins. Then it was trial and much error.

[sodman12]

nautical mile is only 5529 feet. just thought i would point that out.

[CrashingDutchman]

hmmm different opinions on how many feet a nautical mile is. Wikipedia (http://en.wikipedia.org/wiki/Nautical_mile) says that 1 nautical mile 6076.1155 feet.

Edit: Maybe they got it from Google (http://www.google.nl/search?hl=nl&q=convert+1+nautical+mile+to+feet&btnG=Google+zoeken&meta=)?

[Tom Harper]

Thanks guys,

The 6080 came from my calculations. I may have rounded up someplace.

[clolson]

FlightGear says:

#define SG_NM_TO_METER 1852.0000
#define SG_METER_TO_FEET 3.28083989501312335958

So 1852 * 3.28083989501312335958 = 6076.1155 (rounded to 4 decimal places.)

Curt.

[sodman12]

hmmm
very intresting

[MX]

"PIC18Fxxxx based waypoint engine design that utilized a low parts count board, that could determine bearing and distance to a route with a half dozen waypoints, and that included a simple user interface using a serial port connected PC. That alone is a huge project. It would be very easy to expand it from there (open source it)." He also admonished to KEEP IT SIMPLE...


Tom,

If you read further in the WP Sequencer thread, you'll find that we did this. See http://www.hexpertsystems.com/wp.

MX

[Tom Harper]

MX,

Thanks for the response. I have some beginner questions:

I thought you did it in high level language with built in trig functions. Did you use integer binary?

It looks like the sequencer takes raw info from an OEM GPS module and puts together a $GPRMB sentence to output to a navigation system. I didn't understand the references to the RCAP. I tried to find it on the web and everything had been discontinued. Is that the navigation system? Does the WP sequencer output a servo control pulse?

I think what I'm doing is a little different. I want the processor to do all of the navigation tasks. Also I'd like to have the processor calculate the waypoints from an internal template. I fly search patterns for aerial photography - overlapping racetracks. Not much difference from one to the next. I think the first waypoint is the only one I need. I'm probably doing a lot of wheel re-inventing - but, if you invent the wheel you know how to fix it when it breaks.

BTW: A guy named Lauer used to work for me at National Semiconductor. He commuted from Grass Valley to Santa Clara in a Beech Bonanza. Probably still consults on microprocessors. Ever run across him?

[MX]

MX,

Thanks for the response. I have some beginner questions:

I thought you did it in high level language with built in trig functions. Did you use integer binary?

Yes, it's floating point with trig functions. One of our requirements was to use waypoints with lat/lon values, and floating point was used to handle the wide range of values.

It looks like the sequencer takes raw info from an OEM GPS module and puts together a $GPRMB sentence to output to a navigation system. I didn't understand the references to the RCAP. I tried to find it on the web and everything had been discontinued. Is that the navigation system? Does the WP sequencer output a servo control pulse?

RCAP does the servo pulse, but we've talked about merging the two.

I think what I'm doing is a little different. I want the processor to do all of the navigation tasks. Also I'd like to have the processor calculate the waypoints from an internal template. I fly search patterns for aerial photography - overlapping racetracks. Not much difference from one to the next. I think the first waypoint is the only one I need. I'm probably doing a lot of wheel re-inventing - but, if you invent the wheel you know how to fix it when it breaks.

I wrote a windows app for configuring the waypoint sequencer. One function we talked about adding is the ability for the app to calculate the waypoints given a starting lat/lon and a set of heading / distance values. Seems like keeping that off of the microcontroller is better.

BTW: A guy named Lauer used to work for me at National Semiconductor. He commuted from Grass Valley to Santa Clara in a Beech Bonanza. Probably still consults on microprocessors. Ever run across him?

I know some Lauers, but none that fit that description. Maybe related.


---

[Tom Harper]

MX,

Yeah - possibly Lauer's kids.

Thanks for the response.

[MX]

BTW, I don't mean to put down your effort here. I just want to make sure we don't reinvent the wheel. We have much to do.

Have you done anything to calculate lat/lon waypoints given a starting lat/lon and your search pattern? It would be nice to add something like this to the Waypoint PC application. Maybe have a set of standard search patterns ("computer, execute search pattern Riker1") that we could choose from, and a scaling factor, then generate the waypoints for the pattern.

MX

[Tom Harper]

MX,

I can add the search grid next. Then I want to work on drift detection and compensation.

I've added a UART chip. The TI 430 has I2C and SPI but not UART. I think the processor can handle it in software but I don't want to spend time on it now.

The internal oscillator is supposed to be 1% stable at 16MHZ. That's good enough for the PWM. If it works I don't need a crystal.

I've settled on the attached schematic. The output of the microcontroller is gated by a quad AND/OR. The gate detector is just the IC from a servo. The primary output is Rudder. The Throttle control is for altitude hold. Aileron is a possible for experimentation. The elevator input from the leveler is for use with the altitude hold.

Given up on the pin grid for setting waypoints. It may make sense later but think it's easier to just set the lower right reference point and the waypoints in the on board NV ram.

I've shown a peripheral for recording flight data. Jeffs555 has given me some links - the MMC memory units interface directly on the SPI bus. Spark Fun has sockets for them. That could be convenient for uploading waypoints as well as recording flight data. Just snap one in the socket and away you go.

The parts in the diagram are all 14 pin or less so it has a low parts count of small packages with very low power.

Tom

[MX]

...I've shown a peripheral for recording flight data. What I would really like to use is a memory stick. In fact a memory stick would be great for loading waypoints. Anybody know the protocol for memory stick USB? Your ARM7 should eat it up!
...

I don't know about a memory stick, but the SD flash cards are easy to talk to with SPI. You can also port a freely available FAT file system so you can just plug the card into a PC to look at the data. I just did this for another project.

MX

[Tom Harper]

MX,

Yeah, I just edited the above for MMC.

Those things will be ideal.

[Tom Harper]

Think I'm beginning to understand this stuff (dangerous, sophomoric attitude). The OEM GPS units output only basic sentences that provide information on GPS. Navigational information is created by the manufacturer's (Magellan, Garmin etc.) processor. So there are no navigational conveniences or interferences. It won't jump way points because there aren't any.

There is no heading information. The GPS unit provides only Course Over Ground (measured heading), Speed Over Ground and Position. Course over ground is heading if there is no wind. That's why it works in the Emulator.

I modified the FEINT software to use integer values referrenced to a single Longitude/Latitude point which is the lower right corner of the matrix. I'm not using the 8 bit values for a start. These are 16 bit integers. The way points in the screen photo are in feet referred to the lower right corner. Since the topo map has a 'feet' scale it's easy to select a lower right reference and measure the way points with the topo scale:

WP1.....X 3000.....Y 1750
WP2.....X 3500.....Y 2000
WP3.....X 3500.....Y 3000
WP4.....X 3500.....Y 3500
WP5.....X 3500.....Y 4500
WP6.....X 3550.....Y 4000
WP7.....X 3350.....Y 3500
WP8.....X 3350.....Y 3000
Etc.....

The processor code still looks to be small. Next I'll work on 'track made good" which will yield drift. Also will figure out how to get VB6 to output the emulator results. The SavePicture statement saves the picture without the waypoints and track. Any suggestions?

[d_wheel]

MX,

I tried to find it on the web and everything had been discontinued.

Did you try here?

http://scalerobotics.com/store/catalog/product_info.php?products_id=30

Later;

D.W.

[Tom Harper]

d wheel,

Thanks - No tech info but just seeing the board helps!

I've dedided to use an OEM GPS unit for a minimum system. The TI development system arrived today. Very nice package. So now I can start on the actual processor code.

Thanks again,

Tom

[Tom Harper]

The system is basically functioning. For those who may be interested I will cover the routines in individual posts. Since I started this project cold, I will simply repeat my learning process. Comments and critique are welcome (be kind).

Sine, Cosine, ArcSine

All values of Sine (except two) are fractions. Since this is an integer system we need to divide by reciprocals instead of multiplying by fractions:

.5 X 4 is the same as 4 /(1/.5) which is 4/2

To expose decimal places we need to divide into a something greater than 1:

1/.866 is still 1 (as an integer) 1000/.866 is 1154

So, for a triangle ABC, if I want to find the side (A) where the included angle (a) has a sine of .6 and side (C) is 5:

A = (1000 X 5) / (1000 / .6) = 3 or A = (K X C) / (K / Sine(a))

Since the Sine value is supplied by a table the decimal operation is handled during the creation of the table and the processor sees only integers.

To keep things simple the system uses only one table of 0 to 90 degrees.

My first attempt was a Sine table of 32 lines with a K value of 128. The result was fair. The system could navigate but had major problems on headings above 70 degrees. I expanded the range from 70 to 90 with a second smaller table. That helped but there were still problems.

On some headings decisions were sloppy. The model (under emulation) would circle right instead of simply turning left. It would make long runs away from the way point and then turn into it. Very bad approach angles.

I increased the number of lines to 45 and K to 512. That worked very well. The indecision and circling stopped. Function was OK but long runs leaned 2 or 3 degrees away from the way point and turned toward it at about the half way point.

Increased the size of the table to 90 lines and K to 1024. That produces good results. Each element in the table is 16 bits so it is 180 bytes long. It does not resolve the difference between 89 and 90 degrees. To do that requires a K value of 4096. That pushes the first three elements of the table to 24 bit values. I think 90 elements with K=1024 is optimum.

To find the sine of an angle the table is searched using the angle in degrees as the index:

aSine = Table(a)

For ArcSine I search the table by successive approximation. I take the middle value of the table and compare it to the sine(a). If the table value is high I add half the remainder to my index. If low I subtract half the remainder from my index. It converges in 6 approximations. The index of the last approximation is the angle in degrees.

Successive approximation would allow the table to be located in an external memory. Look up is accomplished with six or less data transfers instead of the entire table. If I get pressed for code space I'll do just that.

Cosine is obtained by reading the table in reverse - err....I think....haven't tried it yet.

Since the table covers only 0-90 degrees the result must be placed in the proper quadrant.

[Tom Harper]

Distance off track is an easy computation. I record the bearing to the next way point when it is stored. That is assumed to be the ideal track.

Then:

first angle is Bearing between present and previous Way Points.
second angle is present bearing to Way Point
C= Distance to Way Point
a=difference between first and second angle

Cross track error = Sine(a) X C

I can calculate it but so far my correction schames have not worked.

[Tom Harper]

The simplest method for square root of binary integers is subtraction of sequential odd numbers:

9 - 1 = 8
8 - 3 = 5
6 - 5 = 0

Three subtractions were required so the square root of 9 is 3. This routine requires as many passes as the answer. Typical calculations will yield answers around 2000 at the high end. I am estimating 2 ms for square root.

The other two methods that I can think of would be binary Logarithms and Newton's method. Binary logs require a look up table for correction. I think it's worth considering for the whole math pack. But, not for the first cut. The same with Newtons method. Later.

For the first system I am using subtraction of odd numbers. If you have a simpler scheme - lay it on me!

[Tom Harper]

Drift correction requires measuring the crosstrack error and adding a proportional bias to the rudder control value. Too much and you get oscillation. Just enough and you get a track that closely parallels the Ideal. Definitely within the ability of the integer system.

My first attempts were to locate the track and drive over to it. Bad deal!

The solution requires that a proportional bias be added to the normal control output. I knew that but couldn't seem to get it into code. The scheme shown sets up a large bias value and adds the normal control function to it. In these photos, there are not enough proportional steps so you can see sharp bends at the decision points. Since the control amount is based on cross track error the model can never reach the ideal track. If it did the bias signal would be eliminated and the system would oscillate.

The solution is simple. One routine calculates the drift bias (Drift) and a second calculates the direction (M) and amount (Yaw) of control needed to raise the way point. Then the two are combined:

Rudder = (M * Yaw) + Drift

These emulations are for a 65 fps speed, 15 degree per second max turn rate, 20 mph SW wind.

[Tom Harper]

In view of the goal of keeping the system simple, I have settled on this scematic. Following the experiences of others I have added external indicators and will use the UART for loading Way Points. The GPS will have to be unplugged or switched for this operation, but it allows Way Points to be loaded without removing the system from the model.

For the first unit I've left out the external memory. It can be added later. Same for altitude control - that's next.

[Tom Harper]

The GPS unit and components arrived from Spark Fun. I found a PC board from a past project. Removed the signal lines and left the power and ground runs. The plan was to drop in the 3.3V regulator but all the pins are different. No big deal. just a little messy. Everything is socketed including the 6 position switch (bottom of 20 pin socket).

Time to put the GPS back in it's box and write a program to read the mode switch and exercise all the pins on the processor.

[Tom Harper]

Got my $20 development system and software from TI. Wow! That's really a big twenty bucks worth. Took a while to get used to the software. Assemblers have changed a lot since the last time I wrote code.

I did two quick routines - Square Root (16 bytes), BCD to BINARY (10 bytes). Looks like the average is two bytes per instruction. So the 2K of program memory becomes 1K lines of code. I need about 200 bytes for tables. That leaves 900 lines. But, with a sample period of once per second there can be a trade off between lines of code and execution time.

Also found that two pins are dedicated to programming the device. So I will have to share some functions. I can put the LEDs on the servo inputs. The servos won't respond to a level. Just drop it to a pulse every 20ms or so and they will be happy. I did keep the function switch, at least until the thing is working.

[Tom Harper]

Settled on the following for the first cut basic system:

1. 24 waypoints stored in NV 'Information' memory

2. 8 words of NV memory reserved for Lower Right Reference point, camera control and future command functions.

3. One control surface control output and one camera control output.

4. RS232 connection to PC for system debug (connection to emulator), waypoint setting and flight data.

So far I have completed the math pack in MSP430 assembly code in 192 bytes of program memory. Add 180 bytes for the table. That's only 372 bytes out of 2000. I think it will fit with some room to spare.

Wrote a short program for the PC UART interface. At present it selects and displays GPS sentences - useful.

The schematic is taking form:

[Tom Harper]

Made some inquiries and found that there is no short cut for the RS232 interface. Fortunately there is a $1.45 device from SparkFun that does it all without the +- 12V supplies.

I'm going to use the Comm Port on the PC to load patterns for debugging the circuit board. Should start board check out next week.

This should be close to final for the schematic.

[Tom Harper]

Kiss again - I reduced the schematic to what will be on the first unit.

Anything in color on the schematic has been verified. Anything in blue is complete and the function has been checked out.

Spent a frustrating evening getting the GPS to talk to the PC. Turned out that the input to the RCVR has to be held hi through a resistor. Connected it to the output of the RS232 driver. The circuit is an inverter with an internal resistor to ground. Works fine and eliminates the resistor.

In the process I discovered that Magellan has a very low cost RS232 interface. They just use a 0 to +6V signal. Doing that could reduce parts count. But, for now, the Intersil chip is a solid solution so I'll leave it in.

The EM-406 is extremely sensitive! It quickly locks onto 3 satellites when it is just sitting on my workbench. I have to put my Magellan 315 in the window to do the same thing.

[Tom Harper]

Omitted the programming switch in favor of a jumper select on the PC board (altered the schematic above). I don't think having an exposed switch that can defeat system operation is a good idea. The RS232 connector will be mounted on the fuselage and allow external connection but I will have to get to the board and move the jumper to load way points.

Next step is to add the microprocessor and start communicating with the PC through the UART.

[Tom Harper]

The Olimex programming adapter does not work with the two wire JTAG or the 14 pin device. After considerable wasted time I found that the USB unit supplied by TI does the job fine.

Set up the interrupt service routine to provide three timing functions:

1. 25ms interval for the servo control outputs

2. Software variable (1ms to 2ms) pulse for servo control

3. 900ms interval for reading the output of the GPS. The system runs synchronous with the GPS so the UART is turned off and nothing is processed until the correct sentence is anticipated.

It works on the board. Next I'll check out the Servo Switch and then start on the UART.

[Tom Harper]

Finally got the UART and SPI interface working. The UART accepts the output of the GPS unit. It also communicates with the PC over the RS232 link.

Next step is to store waypoints in the on board non-volatile memory. When that is functioning I can begin converting the navigation software into MSP340f2012 assembly code. The RS232 link will allow it to interface with the emulator for debugging and test.

[Tom Harper]

Spent some time consolidating the development system. The $20 system from TI is amazing. Three wires connect to your application for in circuit programming and debugging of the microcontroller. I had been using the detachable board that is also part of the system. But, that is not necessary. It just plugs right into your application. Very nice!

I added the LED driver and the ICE connector to the schematic above. The LED is handy for debugging a real time system.

Completed routine to parse the NMEA sentences. Works fine with messages sent down the RS 232 cable from my desk top. I'll be using the $GPGLL sentence for navigation. The parsing routine identifies the beginning of both navigation and waypoint sentences. A $GPTPH (not NMEA) header switches the processor from navigation to programming mode. There is a user input bit on the UART. I may use it to confirm programming mode.

The math routines, initialization, parsing and servo control routines have consumed 942 of the 2000 bytes available. Next in line:

+ Way point storage in non-volatile memory

+ Convert the navigation routines from VB6 to MSP430 code

+ Interface with my system emulator for testing

+ Refine the servo algorithms

Should fit OK.

[Tom Harper]

The Waypoints are a combined effort between the PC and the FEINT system. Preprocessing in the PC saves code and memory. For the first system I am assuming a range of 1 mile. These small models are barely visible beyond 2000ft so 1 mile is a good start. The matrix resolution is 16 ft. That allows a Waypoint (X,Y) pair of coordinates in a single 16 bit word. Each segment of non-volatile memory is 64 bytes = 32 Waypoints in each of 4 segments. More than enough to begin with.

An Excel spreadsheet is used for waypoint entry. That provides a user record in a standard file format. Entry can be in absolute Latitude and Longitude coordinates or in X,Y feet from the reference point. An advantage of entering coordinates in feet is that they will work with any reference. So, once a grid pattern is entered - for photo runs or search etc. - it can be used at any location by simply entering the Longitude and Latitude of the SE corner of the search area. Any conversion or compaction, by the download software is also shown on the spreadsheet.

Added selector pins for the user input on the UART. Programming (Waypoint download) now requires that two jumpers be moved. This is for safety and so that FEINT can detect programming mode on power up. In programming mode the interrupts and timers are not initiated.

Also added another LED. The LED's are handy for debugging. Both come on after power up in programming mode.

The Waypoint download software is working and the FEINT system stores the Waypoints in non-volatile memory.

Next I have to parse the in flight GPS sentence. Then it may be time for the navigation routines - at last!

[kd7ost]

Wow,

Lots of great work in that project Tom.

Dan

[Tom Harper]

Thanks Dan - now let's see if I can finish it!

Tom

[LukeZ]

Tom, there hasn't been much comment in your thread here, but I'm sure there's plenty of people, like myself, lurking. You've done good work so far, and hardly without any encouragement! :rolleyes:

Keep up the good work. Your keep-it-simple approach is nice to see. I think this project could have some good uses. I like that you can enter a grid pattern and have it work for any location just by updating the starting coordinate. Would be useful for surveying.

Anyways, I'll be watching your progress.


Luke

[Tom Harper]

Thanks for the encouragement Luke.

Entering waypoints is tedious so I changed that program. Now it uses a screen image. You enter the upper left and lower right coordinates in Latitude and Longitude and then use the mouse to click off waypoints. The program enters the waypoints into the Excel spreadsheet. I am using clips from Terra Server but you can use any image. It could even be a sketch taped to the screen.

[t_j_walker]

I have to echo what Luke said. I have been lurking for awhile as well. Keep up the good work Tom. I am looking forward to seeing your project flying.

Tim

[Tom Harper]

Thanks Tim - I'll keep posting the narrative.

[Tom Harper]

Not much progress. My day job got in the way - and the RS232 link crashed. I think Windows changed it's mind and I couldn't figure out why. Any way I set up another computer close to the work station. That computer functions in place of the GPS so I can change message content for debugging.

Cleaned things up. It's all working again and I don't have to walk across the room to get a GPS message.

[Tom Harper]

Completed the reception and scaling of the GPS input. The reference position is subtracted from the current GPS position. Only the fractional portion of the lon/lat is used. So for Latitude 37 23.2475, only .2475 is used. .2475 is treated as an integer = 2475. To convert this to linear feet the Latitude is multiplied by .4 and the longitude by .7. To keep everything in integers you multiply by 4 for Latitude and 7 for Longitude. The quotient in both cases is then divided by 10.

The multiplication results in some very large integers. So, the divide routine had to be extended to handle 32/32 bit operations. Only the difference between the reference and current position is converted to feet, but that is still a large integer.

To keep from getting lost in the code I have used flow charts. The calling routine is not byte efficient but it is easier to manage than linear code. The first two flow charts represent completed code. I am working my way down the third one.

[HELModels]

Tom,

This is the project I want to try. PM.

Correction, This is another project I want to try. :)

[Tom Harper]

Storch,

Jump right in.

Some seniors at NMT are working on an even simpler version. Their's has only 4 components plus the GPS. Will probably be small enough for an SS.

[Tom Harper]

Completed the interrupt service routine. Interrupts are dedicated to the PWM outputs with the side benefit of a 1 second time reference. This processor has one 16 bit timer. At present I want 2 On/Off channels and one proportional channel.

The servo pulses are from 1 to 2 ms wide with a repetition rate of 25 ms.

The timer is set for a period of 25 ms. When it overflows the PWM outputs are set high. The timer is than set for 1 ms. On the next overflow the bits controlling the On.Off outputs are tested. If 0 the output is reset. If 1 the output remains high. Comparator 1 is set with a value that corresponds to the rudder position. The timer is set for 1 ms and the Comparator interrupt is enabled. When the Comparator value is reached the proportional output is set to 0. At the end of the second 1 ms period all outputs are set to 0.

The 25 ms periods are counted to give a 1 second reference. When the count nears 1 second the processor will begin looking for the desired GPS sentence.

I'd like a second proportional channel. There is a second comparator that can be used in the same way. Will do that later. Stick to basics for now.

[philthyy]

Ok, I've been lurking for quite some time now too, and thought I would put in some words of encouragement! Really awesome project, and I'm amazed at how fast you move on this stuff. Most of its over my head, I'm still just an end user kind of guy, but I like to read this stuff and absorb as much as I can...especially since when this stuff hits the market I am going to get my greedy little hands on it and go have fun!

[Tom Harper]

Phil,

I notice that the price for GPS modules is dropping fast. The one I am using is now $55. Also the 100 pc price is ~$32. By next year you may get one free in a box of cereal.

[Tom Harper]

Ah, tedium. Set up the GPS simulator to give me positions in all 4 coordinates. Calculated the numbers for each position, at each step through the microcontroller code, and then single stepped through it converting the hex values to decimal at each stage (and correcting lots of code when it didn't match).

I had a couple of handicaps. My really clever 32/32 bit divide was lousy. Had to rewrite it to a standard subtract and restore. Then the wife and I went up to the big city for a day. In our absence, the cleaning lady (obsessive woman) got into my sacred lair and ate the RS232 cable with her vacuum cleaner. Arrrrgh!

I've recovered and have worked my way down the "Process Waypoint" column of the flow chart through the block that says "Calculate Distance to Target" and it works!

Now on to bearing to target.

[Tom Harper]

I made progress today. I didn't break anything and it's calculating Bearing within the 1 degree window.

I'm at 1572 bytes. I can compact a lot of code. We'll see if it fits.

[philthyy]

"In our absence, the cleaning lady (obsessive woman) got into my sacred lair and ate the RS232 cable with her vacuum cleaner. Arrrrgh!"

Hee hee! I have fits when ANYone gets into my "sacred lair." I know how you must feel...

[Tom Harper]

Completed distance over ground, heading and velocity. Now I have to feed it some realistic paths and verify the calulations. The points look reasonable in hex but I need to check them out.

Also changed from the $GPGLL sentence to $GPGGA. $GPGLL was just for starters. It is a short sentence that was handy for initial coding.

Considered the RMC sentence which has velocity and heading relative to true north. I decided to calculate heading relative to my flat earth grid which also gives me velocity. The calculation does not increase the code at all. So the GGA sentence makes more sense. It is shorter and contains altitude.

Also changed the parsing code to recognize $GPGGB as the NV RAM Write header. It saves a few bytes. I am over 1527 bytes of 2000. Time to cut corners. But I still think it will fit.

[Tom Harper]

Since I am doing everything in integers with a range of 0 to 90 degrees, what I end up with is a vector and a quadrant number. The Quadrants are labeled clockwise 1 to 4. The bearing quadrant (QB) contains the vector whose angle is bearing to waypoint from present position and whose length is distance to waypoint. The heading quadrant (QH) contains the vector whose angle is the direction of progress over ground from last position and whose length is velocity in feet per second.

There were a lot of redundancies in the code I used for emulation since I converted everything to a 360 degree circle.

Went back to a rules based approach using only the quadrants and vectors. Then modified the emulator code to fit the rules. After some tweaking, it all worked. So, that's what I'll use.

The parameters stored in the MSP430f2012 memory are:

QB: range 1 to 4
QH: range 1 to 4
QB-QH: range -3 to +3
|QB-QH|: range 0 to 3
Bearing: range 0 to 90 degrees
Heading: range 0 to 90 degrees
Heading - Bearing: range -90 to +90
YAW = |Heading - Bearing|: 0 to 90
M: Equal to -1 for right turn and +1 for left
Rudder: Range 38 to 218

The control output is PWM from 1ms to 2ms. The interrupt service routine is scaled so that 256 = 1ms. The first ms fixed in the routine. The second is set to the value of 'Rudder'. So the range of the servo input scales as 1.15 ms to 1.85ms. This gives full throw without getting too near the stops. A zero rudder value is 128.

So the rules are:

Quadrants Opposite:

If (|QB-QH| =2) then (if QB=3 ; if Heading < Bearing then M=1) Else (if Heading < Bearing then M=-1)

Quadrants Right Hand Adjacent:

If ((QB-QH) = 1 or -3) then M=1

Quadrants Left Hand Adjacent:

If ((QB-QH) = -1 or 3) then M=-1

If none of the above conditions are met the Quadrants are coincident:

If (Heading < Bearing) then M=1 Else M=-1


The control vector is calculated as:

Rudder = 128 + (M * YAW)


This code is small. I have now used 1956 of 2000 bytes available. That's close but there is still some redundant code to toss out.

It assembles OK. Now to check it out.

[LukeZ]

Tom, sounds like you're getting close! I'll be watching with interest.


Luke

[Tom Harper]

Let's hope!

[Tom Harper]

The day job has definitely become a distraction. The Festival will be over next week and I can get back to the task at hand.

I did connect the finished unit to the software emulator. But, that was a really bad idea. Couldn't make it work with minor mods. So, had to set up some routines to just exercise the navigation unit. To act like a moving GPS that is communicating at 4800 baud over the RS232 link.

It seems to work OK. Takes in the varying GPS positions and responds with the correct calculations. However, after 23 iterations it gets tired an starts returning zeros. I'll work on that problem once the Festival is over.

[Tom Harper]

The Festival and the holidays are over so back to the project at hand.

The system was 'working' in the sense that it ran, for a while, without stopping and it yielded reasonable numbers. But, it was far from actually functioning. Debugging software is akin to self treating self inflicted wounds so I won't bore you with all of the false paths taken. But, now the system is working and interfacing with the emulator.

I've added connector pins and a grounded metal back plate to the circuit board. (as a reminder, this board was salvaged from a past project). This is shown in the first two photos. The microcontroller has 28 waypoints stored in it's non volatile memory. It could store up to 84 if that were productive in an application. Prior to flight, Waypoints are downloaded from a PC using the RS232 port. The emulator functions as a substitute for both the GPS and the airplane. The navigation system sends a position, heading and rudder position to the emulator. The emulator responds with a $GPGGA sentence that represents where the model should be, based on the data sent and an assumed velocity of 50 fps. Processing time in the microcontroller is less than 20ms. The position of the emulated model is plotted on the PC screen. The waypoints are shown as red circles and the flown path as dots. Each dot is 50 feet/1 second. A photo of the screen is attached.

Next step is to add the interupt routine that provides the PWM output. It also establishes a 1 second time base for accessing the GPS unit. I only have about 100 bytes of code space left so I'm going to have to crunch some code.

The first code saving move is to compact the sine routine. Presently I use 90 words to provide 1 degree resolution. I've tested a scheme that generates straight line chords along sine curve. The sine values are multiplied by 1024 so they can be expressed as integers. They then have the range of 1024 to 0. Examination shows that the rate of decrease of these values is regular and with a little tweaking can be made monotonic. The pattern is:

Value.............Degrees

1024..............90
1023..............89
1022..............88
1021..............87
1020..............86
1019..............85
1017..............84
1015..............83
1012..............82
1009..............81
1006..............80
1002...........

count down by 1 six times then by 2 twice then by 3 three times etc,

That reduces it to the form they taught us in school:

Y = a - bX

The sine table can then be reconstructed from a smaller table of values of 'b' and 'X'. 'a' is the accumulated sum. Since 'X' is sequential and monotonic it simply requires a counter that increments every time a new value of 'b' is accessed. The table requires only 18 bytes (18 values of 'b') and can be stored in the non volatile information memory so it does not take up programming space.

To use the table, the triangulation equation is modified:

Sine(a) = Side A / Side C

becomes

1024*Sine(a) = (1024*Side A) / Side C

Each value of 'a' is compared to 'Sine(a)'. When the compare is valid the current 'x' is the value of the angle in Degrees.



Tom

[Tom Harper]

Completed the code for the servo driver. Now When I run the GPS emulator I can watch the servo make corrections. I can see that this will be a handy check out technique when I get it in the airplane. It will verify that the throws are adequate and the everything moves in the right direction.

The photo shows the Feint Kiss unit plugged into a development fixture for power only. The short cable is normally plugged into another PC to download software through the JTAG port. The cable that goes to the D9 shell is the RS232 connection to the PC. This is a parallel connection to the GPS connector on the board. During emulation the PC substitutes for the GPS. The servo is plugged into the connector at the top of the board. I takes the 3V levels out of the Microcontroller with no problems.

Waypoints are stored in the Navigation Unit and progress is plotted by the blue line on the screen. The screen photo is from Google Earth which turns out to be more accurate than a topo map.

Next step is to get it running synchronously with the real GPS unit then store some local waypoints and drive it around the neighborhood.

Getting closer to flying, but not quite there yet. Have to route the servo output through a switching network to allow control by either the transmitter or the Nav system. Also need to change some scaling constants and second guess some of the software. The goal is sometime in January.

[kd7ost]

Getting close Tom. It's pretty exciting.

Dan

[Tom Harper]

Dan,

As I get closer I see more that needs to be done. Also have to resist changing everything. I think it is important to fly it before I start changing things. This very much a learning process.

I now understand your comments (in the wapoint sequencer thread) about flying through the waypoint. I can see this in the emulator data. As soon as it enters the waypoint 'umbrella' it grabs a new waypoint and begins the turn. Your proposed scheme of recognizing the umbrella then waiting until the 'distance to target' value begins to increase before loading the next waypoint may be the best solution. I need to force a decision on the data available because I cannot count on getting any closer to the waypoint.

Also, I think it needs to freeze the heading. Otherwise it could spiral into, and circle, the waypoint at a constant distance. I've seen it do that on the emulator.

Another benefit of this may be that the waypoint 'umbrella' could be set wider. Holding a fixed heading would then get the model as close to the target as possible under existing conditions.

All of that has to wait until it's been in the air.

Tom

[kd7ost]

I know in a Garmin handheld unit, like any eTrex, foretrex, geko, 72, 76 all of them have a more flexible waypoint sequencing algorithm. The range to waypoint, or umbrella as you’re referring to it is a flexible distance based on speed, distance and direction to or from that waypoint. I don’t think its practical in our applications but when we fly using a PDC-10 and a geko just to pick an example, the geko will sequence to the next waypoint if I’ve been blown off course by a fair amount as long as it sees I’m still moving away from the waypoint. It makes this decision pretty fast too. I mean I don’t observe my plane flying past a waypoint and missing it a little bit, try to turn back and then eventually move on. At 45 to 50 mph once it flies past or through that waypoint and the distance is growing at that speed, it simply sequences on.

I know if I try it on foot, I might be traveling at ½ to 2 mph. The GPS compass rose or a servo test jig will show me the GPS try’s to turn back and make the point closer. Even if I’m only feet away. It doesn’t try very long though.

At higher speeds, it sees the distance to waypoint growing larger once past and just sequences along.

Don’t know if this helps any more. You’re doing magic stuff with software. I’m pretty sketchy on how that stuff works. I just know our speeds are generally pretty slow and I think it’s best to use departure sequencing to ensure we make that waypoint as close as wind drift allows.

Dan

[Tom Harper]

In our application I think we want to force the model to make the waypoint (within the umbrella specified) and once within that circle we can apply the departure sequence rule. On a windy day the umbrella can be set very large.

I think it depends on the application. I can see cases where I want the model to make the waypoint even if it has to circle back. In others it doesn't matter. That could be coded with other waypoint information - but not this time. Good stuff to add on the next one.

[Tom Harper]

Completed the WayPoint entry program. The screen is shown in the photo below. It requires an image with the Latitude and Longitude coordinates of the upper left and lower right corners. The coordinates can be entered from the keyboard or loaded automatically from an Excel worksheet. Any image can be used - Google Earth, previous AP, topo or even a sketch. Under field conditions the image might be blank and the path entered by estimation.

To enter waypoints you need to have Excel open with a worksheet named the same as your image file. You then click on the "Allow WP Entry" button and then click on the start point of your series of WPs. The path illustrated starts in my driveway which is the little pointy line on the lower left side of the white line. When you click on the second WP the white line appears and traces all of the WPs entered. The line is white and broad so that it will print well regardless of the background.

Each waypoint is displayed in the row of boxes under the image. The coordinates are in feet from the lower right corner of the image. There are 23 WPs displayed on the screen. The current limit is 32. The WPs can be erased and entry started over if required. When entry is complete you click on the "Save WPs" button and the program saves all of the WPs to a list on the Excel Worksheet and Saves the image with the WP path to a .bmp file so it can be printed. The second picture below is a B/W copy of a saved image.

Next task is to download the WPs into the microcontroller. This will take a little time. I'll use the present software routines but need to modify them some. The original scheme of compacting the X,Y points to fit into one byte each is not necessary. So I'll change that and a few other things in the download process.

[Tom Harper]

Dan,

I has occured to me that a modification of the software in the microcontroller would provide the Lat/lon overlay you want for your photos. It wouldnt print on the image but it would provide a list of GPS data for each numbered photo. It could record Lat/lon, Altitude, speed and heading. It could be connected in parallel with your PDC-10, so only one GPS would be required. The results could be read into your lap top (USB) at the end of each flight or the memory chip could be removed and read later.

I'll finish this project first, but I'll think about it on the side.

Tom

[Tom Harper]

The point and click WayPoint download is working. The Sine table is downloaded with the waypoints. I'll change this by pre-loading the table information into the locked NV RAM block (above 010C0h). That will allow 64+ way points. Each waypoint is now a 16 bit value. That makes the Flat Earth grid a ten mile square with a resolution of 2 meters.

The microcontroller software is stable. I can make substantial changes without running into problems. That's fortunate because I still need to compact some code.

Most problems now seem to be with the emulator. It doesn't like to recognize the start point I specify. In the screen photo below, the model comes in from the top right, instead of starting in my back yard like I told it to. But, it goes straight to the first way point and then follows the path from point to point. When it runs over the last way point it heads straight for 0,0 which is the lower right corner. I have to change that so it returns to the start point.

Today I'll connect the real GPS. Maybe I can drive it around the neighborhood.

[kd7ost]

Dan,

I has occured to me that a modification of the software in the microcontroller would provide the Lat/lon overlay you want for your photos. It wouldnt print on the image but it would provide a list of GPS data for each numbered photo. It could record Lat/lon, Altitude, speed and heading. It could be connected in parallel with your PDC-10, so only one GPS would be required. The results could be read into your lap top (USB) at the end of each flight or the memory chip could be removed and read later.

I'll finish this project first, but I'll think about it on the side.

Tom

Incredible news Tom,

I'm holding my breath. ;)

Dan

[Tom Harper]

Dan,

At the rate this project is going - you'd better exhale!

With the hope that springs eternal in the engineer's breast, I plugged in a new nmih pack, a switch harness and the SirFlll GPS. Stuck it all in a little box and placed it carefully behind the window of the car. Flipped the switch and waited for the little red light to blink. When the light began blinking I drove out off and watched the servo position - zilch! Not even noise chatter. I should have known there was more stuff to do. Likely problems:

- It might think it is up in Escondida like it does on the emulator - not likely.

- It may not be reading the signal from the GPS - possible.

- The flat earth grid may not be registered with the long/lat grid - likely.

- Something I've never seen before - very likely.

So, back to the bench and numbers!

[kd7ost]

You sure it's not just the box with the Lemons on it? :D

Just kidding of course. Taking a breath and good luck. It's probably just 1 or 25 things. ;)

Dan

[Tom Harper]

Oh yeah - the lemons!

I should have noticed.

[Tom Harper]

Think I skipped an important step. Need to make a little plug in board with some LEDs on it. Then program the FEINT unit to turn on one LED when it has GPS 'lock' and another when it is in the way point umbrella. First it needs to recognize that it is sitting on my work bench. Then when I carry it down the street the LED should turn off.

KISS!

[kd7ost]

Brilliant. :D

Dan

[Tom Harper]

Oh yeah, and take it out of the lemon box!

[Tom Harper]

Fised the start point problem - I was giving it the wrong Long/Lat. Also did some clean up and found a number of loose ends in the process. Current emulation is shown below. It starts where it is supposed to and makes all of the waypoints.

Made a 3 LED board and added code to turn on LEDs when it is processing GPS input. I get a red LED when it is processing a $GPGGA sentence and a green LED when it is processing anything else. On the emulator this works fine. The emulator transmits only the $GPGGA sentence. The red LED blinks at a one second rate. The green LED flickers once in a while indicating that it dropped a data sample. With such a tight link this should not happen. I'll check for noise or faulty transmissions.

Connected the GPS and verified the signal on the scope. Also ran the GPS output to the PC and read the sentences. It transmits, in order:

$GPGGA,.....
$GPGSA,.....
$GPRMC,.....

The lon/lat numbers are the same as I use to start the emulator. It should work.

When I connect the GPS to the FEINT system I can see the green light blink as it rejects the non GGA sentences, then the red LED blinks three or four times then the green and then nothing. It just loses interest.

While writing this some possible causes have come to mind. It has to be associated with the fact that the emulator transmits only the GGA sentence and all it's transmissions are cleanly spaced one second apart.

[zenoid]

interesting, and I'am actually doing car trips to test my GPS stuff like you do.
(is it a land rover you drive ?)
I didn't came across all your post but got questions :
How many GGA samples per second do you read ?
Did you log/convert to KML to viz trips using google planet earth ?
Good luck

[Tom Harper]

zenoid,

The GPS sends out one GGA sentence per second.

Presently I use Google Earth for the background maps. They're handy because I can read the long/lat of arbitrary points. Not sure what you mean about conversions. Google expresses seconds as (ie) 34 03 30.00. I convert this to fractional minutes so my input would be 34 03.5000.

Yes, the wife and I drive Land Rovers. Great for exploring the wilds of central New Mexico.

[zenoid]

About conversion, I focused on my app too much sorry. I elaborate : my apps logs tracks in an .igc format which is the standard for real glider comps. So using a web service, I convert this to .kml to see my flight using google earth.
To directly use .igc format you can use some glider software like seeYou for instance. The .igc can embed some waypoint as taskpoint, and then after the flight, seeYou and other will tell you all the stats and points you did plus many other things.

My system is just a telemetry suite(not UAV) that render on a PDA, display TAS, baro alt, vario, stats, ... and a track up style screen to do glider race like in real life. I've added speech synth to avoid loosing your sailplane from sight.
Good luck.

[Tom Harper]

Thenks for the clarification. My plots are made using software I wrote in Visual Basic.

[Tom Harper]

I did quite a bit of clean up - looking for those 24 other things proposed by Dan. Also got the emulator to begin at the 'start point' and operate with more accuracy. Everything worked better, but it still did not go anyplace when I plugged in the GPS unit.

This AM I set it up so that the input was from the GPS unit and the output went to the emulator. The result was a single correct transmission and then it stopped. That was the same indication I got from the LEDs. I was encouraged by the fact that the single transmitted position was in my back yard.

Forced a software break to see where the program was spending it's time. It was testing the ready line on the UART. The test was to see if the line had dropped. Early on I had a problem with the processor taking the data and getting back to the UART before it had dropped it's ready line so I had to wait until it was down. The problem now is that in the 20ms or so that it takes to process the position data the UART drops the ready line and raises it again with new data. No need to wait anymore.

So, I deleted that operation, put the stuff back in the box (not the lemon box) and headed for the car. The servo went to neutral as I pulled out of the driveway, then hard left at the waypoint and hard right at the next. It moved right as I drove down the street because on the emulator plot it cuts through the Mayor's back yard. Couldn't do that in the vehicle. I followed the servo to Spring street. I went through the waypoint and on across the street. The servo was hard right until I made a U turn and then it was hard left until I turned onto Spring street. All of the waypoints were as expected, right back into my driveway.

How about that - it works.

The control algorithm is too severe. I may need some smoothing. But, other than that, I need to see how it works in the model. I'm sure that will be a new experience!

[kd7ost]

Sounds like one big huge chunk of success Tom.

Congratulations. That's a fair piece down the road al of the sudden.

Dan

[Tom Harper]

Yep - I may get this thing in the air before the winds start.

Tom

[LukeZ]

Tom this is encouraging news. Nice to see a project get to this level; I know that's very hard to do.

I love the Earl Grey boxes! Used to be kids selling them in our neighborhood when I was in college. Even though I was broke they still got me to buy one, just for the box. ;)

Luke

[Tom Harper]

Luke,

I couldn't resist those. I dumped out the tea and saved the balsa boxes. Seemed a bit extravagant for a company to use balsa in a consumer product.

This project has been interesting. I'd hung up the my development systems because everything I owned supported obsolete processors(NSC Cop8), But, with a $20 system from TI anybody can do it. Also, distributors have started selling small quantities to the broad base of DIYs. These are good times for computer geeks.

I know what you mean about getting a project over the hump and seeing it work. There is a lot of clean up to do but that will be the fun part.

Being retired is great. No schedule to meet. No customer changing the spec. No manager whining about engineers being perfectionists. Just enjoy the task.

[LukeZ]

Aha! So you're retired! I knew you had some trick up your sleeve... :D


Luke

[Tom Harper]

Yep, it makes a big difference!

[Tom Harper]

In keeping with the KISS goal, I have limited this system to UAV for rudder only. No camera, altitude etc. So, it's almost finished. I need to provide an input that tells it when UAV is active. Otherwise it would register waypoint hits while it was under RC control.

I will modify the software for the on/off input and also for the last waypoint. Decided to have it repeat the waypoints if it is not turned off after it runs through the entire list.

Photos are of final hardware and schematic. Hope to fly it in the next couple of weeks.

[Tom Harper]

Dusted off the LT-40. Should be a more stable test platform than my paper AP models. Had to install two outboard aileron servos to free up room in the fuselage. The other servos are on the bottom of the fuse. Placed a platform over them. Then a thin layer of foam and a thicker layer with cut outs for the Rcvr, Data Logger and Leveler. And, a top layer of foam with cutouts for the battery, Nav system and GPS unit. The Rcvr battery is forward.

The Rcvr switch is forward and low. The Navigation System switch is aft and high. The forward 9 pin D-sub connector is for the battery chargers. The aft connector is RS232 for waypoint programming. Those are nice sturdy connectors. I like'm.

The cable that is plugged into the top of the board is the RS232 connection. I have run the system on the emulator to check out the electrical and mechanical phasing.

Next step is to get a Google photo of the flying field and plot the waypoints for the first flight. Then download the waypoints with the system in the model. And, verify the path by running the emulator. Should not be a problem, but who knows?

In any case that will have to wait until tomorrow. The weather man says we will be snowed in. Great building day!

[kd7ost]

Nice progress and great looking install Tom. Have fun in the snow. ;)
I can't wait to see the results. Good luck.

Dan

[LukeZ]

Ahh, nothing I like seeing more than the inside of an airplane, all stuffed with electronic gizmodry!

Happy flying!


Luke

[Tom Harper]

Decided to use a repeating square for first flights. There are 28 waypoint pairs in the pattern. The waypoint program provides a print out so I can remember what the model is supposed to do. The print out is a attached. Our flying field is on the New Mexico Tech campus. The circle in the lower right is the Socorro Fire Academy.

Programming waypoints in the model is unreliable. It erases the NV memory but does not program the new data. When I put the unit back on the bench with the same RS232 cable it programs fine. The battery may be low although it shows 5 volts on the meter. Still may not be able to deliver a sudden current pulse. Will charge it and see what happens.

[Tom Harper]

Modified the software so it holds the first waypoint until control is turned over to the navigation system. Also changed the routine so that it repeats the waypoint list when it runs over the end. Setting the first waypoint near the launch location will result in an automatic return.

The photo shows the battery charger. I have collected a pile of those black box power supplies that plug into the wall. Finally saw that the specs are molded into the back of the case. So I found one with a 12V > 1/2 amp output for a charger.

The battery packs are 2.1 AH. I used a couple of low drop out 5V regulators with 22 ohm resistors to give me a charge current of 230 ma each. The D-sub connector makes a sturdy mount.

It's time to button it up and wait for a decent flying day!

[phubner]

Tom,
I love the fact that I thought I was brilliant in my idea to build my UAV with a microcontroller, and I see you already have! I have decided on a Parallax propeller chip (yes the name IS ironic!) for my platform and am at the high level software design phase. My prototype board is on pre-order (also for $20:-) ) and expected shortly. If I can get half as far as you, I will be ecstatic!

Thanks for the inspiration!

Paul

[phubner]

One more question for all

Am I foolish (or "How foolish am I?") for assuming that my plane will stay upright under autopilot control? I do not have any horizon-sensing /uprighting circuitry planned. My idea is that if I keep my turns flat by being gentle, I shouldn't have to manually retake control because i am inverted.

Thoughts?

Paul

[Tom Harper]

Paul,

Kind of a co-pilot situation. Most folks recommend a leveler. Since I'm new to this I will let them answer.

I will do a design review soon. I failed on some goals and exceeded others. I have already ported the code to a different processor. The design review may be of some help to you.

Tom

[Dan_Jones]

Tom,
Keep up the good work!

You have already inspired more people than can ever reply here. I do like the fact that you are only using the gps and having good luck with it. Some other implementations do require other sensors. BTW, I have found that the atan2(double X, double Y) function to be helpful in calculating the direction to head in when traveling towards GPS waypoints. But if it ain't broke, don't fix it. :)

Paul,
As long as there is enough dihedral in the wing, leveling shouldn't be necessary except for the elevator to maintain altitude.

Dan

[Tom Harper]

Dan,

Sounds interesting. Tell me more about atan2. FEINT 2 is in design.

Tom

[Dan_Jones]

First, I wish I would have found your thread before I got my implementation to work. I did originally want my code to calculate what quadrant the aircraft was pointed in, just like some of the code you posted. However, with the atan2(x,y) function, it returns the [-PI tp +PI] angle output based on the X and Y errors that I get by simply subtracting the current GPS location from the target (waypoint) GPS location. The angle can be converted to degrees easily, but keep in mind that the 0 degree position is at 3:00, 90 degrees is at 12:00, 180 degrees is at 9:00, and 270 degrees is at 6:00. Based on your implementation, you may need to convert that coordinate system to some other coordinate system. I don't think you need to worry about that, but I did. So that gets you the direction that you need to travel. Getting the direction you are currently pointed in can be done essentially the same way by subtracting the current location from the past location. Add 180 degrees and presto! The servo should be nudged in the correct direction until your current direction equals your waypoint direction. There is no need for quadrant work because the atan2 function takes care of it.

[Tom Harper]

Dan,

Thanks! This is a work in progress. I'll see how it fits.

Tom

[Tom Harper]

Carl and I have agreed to a flying day next Thursday. Carl is the pilot of my flying creations.

This is a good time to put the design in perspective.

The inspiration for this project was Mr. RC-CAM's statement in the Waypoint Sequencer thread:

"PIC18Fxxxx based waypoint engine design that utilized a low parts count board, that could determine bearing and distance to a route with a half dozen waypoints, and that included a simple user interface using a serial port connected PC. That alone is a huge project. It would be very easy to expand it from there (open source it)." He also admonished to KEEP IT SIMPLE.

To this I added minimum parts count and minimum cost.

So, how does it compare to the goals:

Hits:

I chose the TI family over PIC because of the low cost of ownership and the in circuit (JTAG) programming. For $20 I had everything. IF PIC offers the same thing then chalk it up to my ignorance.

The MSP430f2012 is a 2K processor with NV memory and SPI interface in a 14pin DIP package. It is adequate to the task and the code is portable to larger members of the family.

This system has 32 waypoints. It will handle up to 48. The waypoints are stored as 16 bit pairs.

Waypoints are entered through an RS232 connection to a PC. Communication is 2 way so the link can also be used to recover logged data.

It calculates Bearing and distance to waypoint. It also calculates Heading and progress made good over the ground (which yields ground speed).

Integer math is sufficient for the task. Navigation does not require floating point or high level language. Gotta admit though, it would have been easier.

It is compact and has a low parts count. All parts are in DIP packages so they are socketed.

It should operate well within RC transmitter range.

Misses:

An initial goal was to use a pin board for waypoint and data entry. That was a bad idea. Jumpers will be useful for field selection of the waypoint 'umbrella' to match wind conditions, and maybe some other parameters, but not waypoints.

The Flat Earth approach has it's limitations. If the grid is not large enough you cross boundaries and create ambiguities. That is why I expanded it to a 100 square mile grid. The solution to the problem is to use a 32 bit number for the reference. I'll do that next time. This system is sufficient for now.

All program memory space has been used. I can still squeeze bytes out of it, but not enough to do data logging or altitude control. There is not enough room to allow fully autonomous control.

The parts count is low but not minimal. The same is true of cost. There are 7 packages with a total cost of less than $20. That does not include the servo module or the GPS. Not bad, but not minimum. The trade off is ease of handling. I can't even see the pins on a TSSOP package, let alone solder to them!

Conclusions:

This has been a very interesting project. I now know how to spell GPS and NMEA and have the tools to progress further. I am sure that some flight experience will result in major modifications to the control algorithm.

The 2K of code forms a core for communications and control. I have ported it to an 8K processor with minor architecture conflicts. It will be a good building block for the future.

Onward to FEINT 2.

[phubner]

Tom,

Thanks for the report.
I can't wait to see the flight results! Best of luck next week. Take lots of pic/vids !

Paul

[Tom Harper]

This morning is out for flying. Cold and snow.

We'll watch it hour to hour until we get a break. Probably sometime this weekend.

[Tom Harper]

Beautiful day!

The Norvel is new to this LT-40 so we spent some time on rigging and trim. Got it tamed for hands off flight and flipped the switch. The model went into a gentle left turn and nothing else. I turned off the GPS system and ground control resumed. Carl brought it down so we could check for problems. Found a jumper in the wrong place.

Back in the air - flipped the switch again. The model turned toward the way point then began a gentle right turn and stayed there. Arrgh!

Oh well - the Norvel .40 hauls the LT-40, the 12 oz tank provides infinite flight time for test and the RC/GPS control switch works in the air. That's not all bad. Back to the bench. May try again Thursday.

The pic is Carl checking the nose gear before take off.

Tom

[Tom Harper]

Everything checks out OK on the bench. I know the servo link and switch were functioning in the air so it is not a signal level problem.

The likely culprit is the connector between the GPS module and the FEINT board. I did not check that carefully when I removed it from the model (dumb!). The foam is packed in such a way that there is strain on the cable so it is possible that the connector was not seated in it's socket. I'll change the foam mount and check out the wiring from the connector to the board.

Should be able to add a green LED that stays on when the software is actually processing $GPGGA sentences.

Hope to get into the air again tomorrow.

[Tom Harper]

Hmmm...need more bench time. When the emulator presents a $GPGGA sentence to the UART input pin the system processes it. When the GPS presents the same sentence to the same pin, nothing happens. One of THOSE things!