Standalone Waypoint Sequencer [Archive]

LukeZ

May 10, 2006, 01:26 PM

I thought this topic might deserve its own thread. There are a few posts over in the RCAP2 thread (http://www.rcgroups.com/forums/showthread.php?t=484568) that kind of got us started on this - around #288 (http://www.rcgroups.com/forums/showthread.php?t=484568&page=20#post5454633).

Currently if you want waypoint functionality you need to buy a commercial, hand-held GPS or the like, which are bulky for UAV/AP/FPV use and may not have all the features one desires for such a task.

Therefore, the question is, what might be involved in creating a microcontroller-based "waypoint sequencer" for use with OEM GPS modules? What would be the list of features it should possess? And what are the various ways in which such a thing might be of use? Obviously it would go well with the RCAP2, but are there other applications?

When I started this thread, Mr. RC-CAM was just about to tell us how hard this project would be ;) , and muc had given us some useful links, which I hope he'll re-post here.

Luke

Mr.RC-CAM

May 10, 2006, 01:39 PM

Mr. RC-CAM was just about to tell us how hard this project would be Yes, but that hopefully inspires someone to tackle it. :)

For features, I think you should re-list what you already posted in the mother thread. However, to increase the chance of project survival, it would be best to reduce the list to the bare essentials for now. Perhaps start with something that can support ten waypoints and a minimal user interface. That will allow for field validation of the basic waypoint engine.

Speaking of the user interface, I suggest an Palm Pilot. The early versions are cheap ($50 refurbished), portable, and it appears that decent development tools are freely available.

HLGNut

May 10, 2006, 01:47 PM

HI,

I've been following this thread for some time.

I found this site some time ago and bookmarked it.

http://users.libero.it/riccardo.rocca/roboat.htm

Perhaps it would give someone some ideas on coding. He used a Motorola M68HC908GP20 but I'm sure it could be done with a PIC.

Cheers,

- Bob -

LukeZ

May 10, 2006, 01:50 PM

Possible feature list of a standalone waypoint sequencer:

1. Adjustable waypoint proximity range - to specify how close you need to get to your waypoint in order for it to be considered attained, and sequenced to the next.
2. Selectable arrival or departure sequencing.
3. Selectable one-time-through or repeatable courses.
4. Selectable GPS baud rate in order to be compatible with multiple engines.
5. Triggerable (TTL or RC PWM perhaps) "go-home" feature.
6. Triggerable "pause-and-loiter" feature (and consequently, a "resume" option as well).
7. Plenty of memory for lots of waypoints.
8. Firmware upgradeable through Bootloader. ;)
9. Waypoint-specific instructions: loiter for 10 minutes at waypoint Y, trip an output pin on arrival at waypoint X, etc...

The idea is that waypoint creation would be done on a PC, ideally through some already available, and perhaps free, software (something like Google Earth perhaps). A small Windows utility would upload a text file of these waypoints to the microcontroller through a serial connection. The Windows utility could also be used to manage/configure the options.

In the spirit of keeping it simple, I'd think a serial connection to the PIC/micro should be all that's needed - if someone really wants to use USB, just get an adapter.

Luke

LukeZ

May 10, 2006, 01:56 PM

I suppose we could now all argue about what micro and language should be used, but I'm guessing that will just be the choice of whatever sap decides to take this on. ;) :D

Luke

joelhaasnoot

May 10, 2006, 01:59 PM

Mr.RC-CAM

May 10, 2006, 02:02 PM

I found this site some time ago and bookmarked it.Excellent resource. Plenty of working examples using integer math instead of floating point. That is just what the doctor ordered. Looks like all the hardest/nastiest work is done. :) The missing puzzle piece is a decently experienced programmer, with plenty of free time, and a desire to share it as open source.

If I was granted one wish: code it in C using a PIC or ATMEL MCU.

A Palm device has one wired serial port and one IR port. I'm assuming you would need an output and an input (GPS module), so you might have to do something there... The Palm would not need to interface to the GPS module. It would only need to be connected to the embedded controller to download new waypoints (then it would be removed). It could be done with the IR, but the RS-232 port is fine too.

LukeZ

May 10, 2006, 02:06 PM

I think a Palm is an excellent idea, I just have no clue how you would interface it. A Palm device has one wired serial port and one IR port. I'm assuming you would need an output and an input (GPS module), so you might have to do something there... A Palm would be prefect, you could remove the screen and the plastic and have a very light weight programmable device, that would run 20+ hours on AAA batteries.Several PICs have two USARTs, or in any case, you could bit-bang one to the Palm/PC interface, and use the other one (hardware USART) for connection to the GPS. So I don't think that's a problem.

However, what do you mean by "remove the screen and plastic"? I don't think you'd need to carry your interface aloft - program the device on the ground, then disconnect and let it go. Otherwise then we're not too much different from removing the screen and plastic from our e-Trex or Geckos... Right? Or no? :confused:

Luke

LukeZ

May 10, 2006, 02:15 PM

If I was granted one wish: code it in C using a PIC or ATMEL MCU.If I were to do it, I'd use a PIC18Fxxx and Microchip's free C compiler. This way it truly would be open source, and anyone could edit and re-flash the code without cost. I know most people developing PICs in C use CCS or Hi-Tech, but those are either not free, or else the free version doesn't work with 18F chips (PICC lite for example)...

Luke

Mr.RC-CAM

May 10, 2006, 02:19 PM

Several PICs have two USARTs, or in any case, you could bit-bang one to the Palm/PC interface, and use the other one (hardware USART) for connection to the GPS. So I don't think that's a problem. It's even easier than that. You only need one serial port on the embedded controller. It can be shared with the GPS module and the occasional host connection. I'm doing that on my GPS OSD project and it works dandy. BTW, if IR was used for the host connectivity, then there are ways to do that without using the serial port.

If I were to do it, I'd use a PIC18Fxxx and Microchip's free C compiler.Sounds good. I can port that to CCS easier than I can write the app. :)

Steve McBride

May 10, 2006, 02:51 PM

Will you guys be developing around a particular GPS module? I would assume that by the time it came down to it, you'll need to pick the interface connector for the GPS - or will this be a 'roll your own' circuit?

I'd be happy to loan my Trimble Lassen IQ module, antenna and eval board to someone developing the waypoint engine if needed. I don't use it nearly as much as I had hoped because I sort of need a waypoint engine :)

http://www.trimble.com/gpsbc_lasseniq.shtml

This unit is only 12 channels, but seems to do a wonderfully accurate job. Has two serial lines on it, both programmable for baud rate and data type (NMEA, lassen's stuff, etc).

I'll be watching this thread closely. Good luck guys.

Steve

CrashingDutchman

May 10, 2006, 04:26 PM

I think that a standalone board (using PIC) had an advantage over using a palm since incorporating altitude will be easier (?).

May 10, 2006, 04:31 PM

LukeZ

May 10, 2006, 04:42 PM

Sounds like you guys misunderstood the Palm idea. The Palm would be the user interface to configure and enter the waypoints to a board that contained some microprocessor that actually does the waypoint distance and direction calculations.

MXRight - I don't see a Palm as necessary to any of this, just another tool to download waypoints on to the PIC.

Luke

Mr.RC-CAM

May 10, 2006, 05:25 PM

I don't see a Palm as necessary to any of this, just another tool to download waypoints on to the PIC. Definitely not needed at this point. But later on, a cheap (and useful) user interface would be needed. Rather than carry a laptop to the field, something less expensive would be nice. Hence, the Palm idea.

Frankly, I would set my initial design goals down a couple of notches for now. I would be VERY impressed if someone posted a 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).

I've seen several project ideas on the forum that slowly died because the design goals became too ambitious too soon. Baby steps, as they say. It would be nice to see this project really happen. :)

LukeZ

May 10, 2006, 05:39 PM

Mr. RC-CAM, what do you see this device outputing? I'm not very knowledgeable about GPS, but I'm guessing there is some already-defined GPS string format that has distance and bearing to waypoint embedded in it? (Otherwise, how do the hand-helds do it?)

Would the PIC need to be able to output GPS sentences in multiple formats? And how many formats will it need to be able to read (or can it just pick up a few strings that are common to all manufacturers, i.e., lat & long)?

Is there an already-defined waypoint/track format, or can it be proprietary for the purposes of this project? I'm thinking it's just a list of latitudes and longitudes... One could add meta-data or -instructions to these waypoints in a more advanced version (loiter at waypoint X for five minutes, take a picture at waypoint Y, etc...)

Luke

Mr.RC-CAM

May 10, 2006, 06:20 PM

what do you see this device outputing? ... I'm guessing there is some already-defined GPS string format that has distance and bearing to waypoint embedded in it?It would need to transparently pass-thru the very useful $GPGGA and $GPRMC sentences (and perhaps skip the other sentences that are often provided). Once it does this, it would then append it's calculated waypoint data as an emulated $GPRMB sentence.

The embedded processor will have only a few hundred milliseconds to do all your waypoint stuff, or else the next group of sentences will clobber it. The popular Geko takes 2-secs to do this, which would be much better if it was reduced to the preferred 1-sec update time that is found on the GPS OEM modules.

Is there an already-defined waypoint/track format, or can it be proprietary for the purposes of this project? It's handled in the standard $GPRMB sentence. The host has to do some simple integer math to derive the waypoint bearing, but other than that it is essentially ready to use data. Although the data fields could be more customized for our needs, it would be best to stick with the standard data dictionary.

workshop

May 10, 2006, 07:14 PM

I'm partial to the BASIC-Stamp type microcontrollers over the PIC. Parallax just announced a new chip with eight processor cores, shared memory and a process controller. It used the familiar BASIC programming language and seems to me to be the ticket for an open source hardware/software development project.

Imagine: One processor reads and codes GPS serial data, one reads the BP sensor and makes corrections while one manages wing leveling and the other is busy computing range data and yet another is making sequencing decisions.

For successful open source, the code must be easy to read and there needs to be a central librarian and $$$ guy in the loop too. My company might talk to the guys at Parallax about sponsoring a project.

http://www.parallax.com/propeller

Jeff W. Parisse
www.teslacoil.com

d_wheel

May 10, 2006, 09:49 PM

Excellent resource. Plenty of working examples using integer math instead of floating point. That is just what the doctor ordered. Looks like all the hardest/nastiest work is done.

Yes, basically the same way I did my most successful project (using the basic stamp). Also, the waypoints are hard coded, as in that same project. Since it is now possible to easily load the RCAP program using a boot loader, this could be one possible method for entering waypoint data until a more sophisticated method is coded. Simply enter them in the correct data area, run the boot loader, and you are set.

Too bad I can't find a reasonably priced compiler for the RCAP pic. I would attempt to convert my basic stamp code for this project.

Later;

D.W.

May 10, 2006, 09:52 PM

It would need to transparently pass-thru the very useful $GPGGA and $GPRMC sentences (and perhaps skip the other sentences that are often provided). Once it does this, it would then append it's calculated waypoint data as an emulated $GPRMB sentence.

The embedded processor will have only a few hundred milliseconds to do all your waypoint stuff, or else the next group of sentences will clobber it. The popular Geko takes 2-secs to do this, which would be much better if it was reduced to the preferred 1-sec update time that is found on the GPS OEM modules.

It's handled in the standard $GPRMB sentence. The host has to do some simple integer math to derive the waypoint bearing, but other than that it is essentially ready to use data. Although the data fields could be more customized for our needs, it would be best to stick with the standard data dictionary.

I've been working on just such a project. I had the same idea: to generate the RMB sentences while the GPS oem module supplies the rest.

I've got some code running now on an ARM7 that takes two sets of Lat/Lon data and computes the range and bearing. Do we need the cross track error or just the direction to turn?

On the ARM7, running at 60MHz, it does the calculation in 642 microseconds. That's compiled C code without any hardware floating point assistance (using C FP libraries). Now I'll just have to see how that ports to some lighter hardware. I've been playing with the Parallax 8-core processor for another project, but the calculations would have to be done in assembly to get them done fast enough. The spin code is interpreted and is pretty slow. Recoding the calculations in fixed point assembly would not be trivial. I'll probably target a processor that I can use a C compiler on.

MX

LukeZ

May 10, 2006, 09:54 PM

Imagine: One processor reads and codes GPS serial data, one reads the BP sensor and makes corrections while one manages wing leveling and the other is busy computing range data and yet another is making sequencing decisions.Jeff, as much as this sounds good, I think at that point we're almost to an entirely different project; nearly a full autopilot.

I guess in my mind this would be a project with a very specific appplication - a chip, or small board, that combined with an OEM GPS module, would give one waypoint capabilities. It would be easy to design-into other projects; basically this is just a PIC with some code. But I wasn't thinking of including features of those "other projects" into this one.

Which is not to say someone shouldn't build some conglomerate circuit. :) This could be included in an upgraded RCAP2 board, and BP altitude sensing could be added as well, any number of things. But like Mr. RC-CAM said, I think it does make sense at the beginning stage to focus solely on the sequencing engine.

As for BASIC vs. C vs. some other language, everyone has their preferences - but in my experience, none of that really ever matters. As I joked about earlier, if the project gets done at all, the choice about what language to use is almost always made entirely by the guy who decides to take it on! Rarely have I seen true collaborative software development projects take place here. (Actually never, but I can't be everywhere at once ;) )

Luke

d_wheel

May 10, 2006, 09:58 PM

Do we need the cross track error or just the direction to turn?

MX

I've tried both. Cross track error is the only way to go.

Later;

D.W.

Mr.RC-CAM

May 10, 2006, 10:35 PM

I've got some code running now on an ARM7 that takes two sets of Lat/Lon data and computes the range and bearing. Do we need the cross track error or just the direction to turn? I'd have to say your basic waypoint calcs are done then. The RCAP does not use the Xtrak error, or the steering flag. I understand that these two fields are legacies from old marine navigation apps. They may be of some use for someone, but so far I have not figured out where they would be needed.

Generally speaking, the important $GPRMB sentence fields are the waypoint validity flag, bearing to waypoint, range to waypoint, and last/next waypoint ID numbers. The others can be dummy fields, at least for the things we see around here.

MX, what did you have planned for your implementation? Commercialization?

jackc

May 11, 2006, 02:06 AM

I have some BS2 Code here that strips the $GPRMC sentence out of the GPS data output and sends it out a BS2 pin to a TNC @ 4800 baud. Ugly looking code but it worked for me 6 years ago!

Jackc
Australia.

d_wheel

May 11, 2006, 12:35 PM

The RCAP does not use the Xtrak error, or the steering flag. I understand that these two fields are legacies from old marine navigation apps. They may be of some use for someone, but so far I have not figured out where they would be needed.

Either I misunderstand what crosstrack error means, or others don't fly in the kind of winds we see here in west Texas. My understanding is that crosstrack error tells us how far we are off of the desired ground track. If we are flying without it in a cross wind, the ground track will be a curved path instead of the desired straight line. It is not uncommon for my airplane to be flying with a 20 degree crab while attempting to stay on track. If I am in error about the meaning, please fill me in.

Later;

D.W.

Mr.RC-CAM

May 11, 2006, 01:22 PM

My understanding is that crosstrack error tells us how far we are off of the desired ground track.I understand that is its purpose. RCAP does not use it though. Other waypoint apps I have looked at ignore it too. But, it sounds like it is being used by some of us, so the data should probably be included in the DiY waypoint engine. But if this field is used, then wouldn't the XTRAK steerage flag be needed too? {I understand they are companions}. A good turtorial on these two fields would be helpful.

d_wheel

May 11, 2006, 01:58 PM

I understand that is its purpose. RCAP does not use it though.

If we are going to use our own waypoint engine, we won't be getting any of this data from the GPS anyway. It is only generated if we use the waypoint engine built into the GPS. RCAP, or our new sequencer, will have to calculate headings, crosstrack errors, distances, etc.

Or is their some other reason for the waypoint engine that I don't understand?

Later;

D.W.

Mr.RC-CAM

May 11, 2006, 02:25 PM

Or is their some other reason for the waypoint engine that I don't understand?It is the very thing that is used to calculate the waypoint bearing, distances, etc. Otherwise, the host must do this, which is a processing burden.

For example, at this point the RCAP only needs to calculate the steering deviation using simple integer math. The required waypoint bearing and destination data comes from the waypoint engine inside the Geko 201. If we pushed these data calculations into the current RCAP host, it would probably choke it. That does not mean it isn't a good idea, but for practical hobby use it is nice to have it handled externally.

So, a DiY waypoint engine interface, that is compatible with affordable OEM GPS modules, is being suggested here.

typicalaimster

May 11, 2006, 02:32 PM

Or is their some other reason for the waypoint engine that I don't understand?

Some OEM GPS's will update more often than the 2 seconds my Garmin GPS will update. If built right a waypoint engine and OEM GPS device will have a much smaller footprint than a standard handheld GPS.

May 11, 2006, 02:50 PM

If we are going to use our own waypoint engine, we won't be getting any of this data from the GPS anyway. It is only generated if we use the waypoint engine built into the GPS. RCAP, or our new sequencer, will have to calculate headings, crosstrack errors, distances, etc.

Or is their some other reason for the waypoint engine that I don't understand?

Later;

D.W.

We'll still be using a GPS, just not a GPS with waypoint engine. I have a little oem GPS module (http://www.sparkfun.com/commerce/product_info.php?products_id=465) that just gives me the basics: latitude, longitude, speed, heading, etc. Using the lat/lon from the GPS, and the lat/lon from the desired waypoint, the code I have now could generate the RMB sentence with the range and bearing to the waypoint. All RCAP has to do is pull the heading from the RMC sentence and the bearing from the RMB sentence and adust rudder to compensate.

MX, what did you have planned for your implementation? Commercialization?

I don't know yet. I was just working on this since I don't have a GPS that will work with RCAP (mine's a Magellan 330M which apparently works a little differently), plus, I'd rather put the tiny little oem module onboard, instead of a big handheld. What do people want here? Would they like just some source code? Or a chip that's ready to plug in-between a GPS and the RCAP?

MX

d_wheel

May 11, 2006, 03:07 PM

So, a DiY waypoint engine interface, that is compatible with affordable OEM GPS modules, is being suggested here.

I think I am with you now. Pull the lat/lon from a gps, calculate everything the RCAP needs to do it's thing, then ship it to RCAP using a data string it can understand. Is that about it?

Later;

D.W.

LukeZ

May 11, 2006, 03:09 PM

If built right a waypoint engine and OEM GPS device will have a much smaller footprint than a standard handheld GPS....which also means, less weight. Not to mention, this could be substantially cheaper than a handheld. And have better options/features.

Luke

May 11, 2006, 03:11 PM

I think I am with you now. Pull the lat/lon from a gps, calculate everything the RCAP needs to do it's thing, then ship it to RCAP using a data string it can understand. Is that about it?

Later;

D.W.

That's it.

Pull current lat/lon from GPS, calculate range and bearing from the next waypoint, pass on to RCAP. Easy, right? :rolleyes:

MX

May 11, 2006, 03:12 PM

...which also means, less weight. Not to mention, this could be substantially cheaper than a handheld. And have better options/features.

Luke

and less power, smaller, customizeable to our specific needs...

MX

terryk

May 11, 2006, 03:18 PM

For me what's required is a functional replacement for the GEKO, something we could plug into the RCAP instead of it.
Therefore the waypoint engine must:
1) Output what the RCAP cares about amongst those Geko NMEA words, heading to next way point and actual track.

2)The waypoint engine would be fed from an oem GPS module so must be capable of decoding that output.

3)It should be capable of been downloaded with a set of waypoints, from a palm top or laptop

terry

LukeZ

May 11, 2006, 03:25 PM

What do people want here? Would they like just some source code? Or a chip that's ready to plug in-between a GPS and the RCAP?How about both? ;)

Just a chip would be nice for those that want an easy-to-use system. The source code might be nice if we want to add features, as I could see this perhaps being useful for things besides just the RCAP. However, I understand you run a business and open-sourcing all your code isn't always in your best interest.

Luke

Mr.RC-CAM

May 11, 2006, 03:30 PM

What do people want here?I agree with the other comments.

Since this is a DiY discussion, let's say the needs would range as follows:
(1) Source code, schematic, and BOM, for the brutally DiY'er.
(2) Programmed chip and PCB for the less adventurous.

I believe that there would be interest in an assembled GPS/Waypoint board. I think that the OSD that I'm working on would pair up nicely with such a gadget. But, I just don't expect the sales volumes would cover the engineering, production, and support costs (a dilemma for these sort of nitch markets and one that is killing me).

I'll have to admit that the Garman Geko is not all that bad (affordable, good user interface, low weight with covers removed, etc). Frankly, it is a tough contender. It does have a couple of quirks, but none that seem to stop the existing RCAP users.

Long story short: If the overall project worked well, had a convenient user interface, substantially reduced size/weight, and {overall} did not cost more than a Geko 201, then it would be very impressive. I'd be interested in building one, that is for sure. And I don't even need it! :)

d_wheel

May 11, 2006, 03:46 PM

If we pushed these data calculations into the current RCAP host, it would probably choke it.

Surely the pic in RCAP isn't that slow.. I can do the whole thing using a basic stamp, and that's using my sloppy makeshift coding. The GPS connected to my basic stamp transmits data at 1 second intervals. The processor has plenty of time to do everything, including crosstrack errors, and then wait for the next string. If a REAL programmer were to see the way I calculate this data they would probably roll in the floor laughing! I am a self taught programmer and sometimes use off the wall ways of doing things when it's not clear how to do it otherwise.

Later;

D.W.

typicalaimster

May 11, 2006, 04:05 PM

How about both? ;)
However, I understand you run a business and open-sourcing all your code isn't always in your best interest.

Well you can open-source the code, but offer products for sale. I would say offer a range of products much like the RCAP. They have kits the DIY'er can put together for a lower cost. Then you have the RTF unit for a slightly higher cost. Some peopel are lazy and want things now. Others are willing to take the time to put something together.

May 11, 2006, 05:24 PM

I'm leaning toward open source on this. Let everyone work on source code, then maybe I can come up with a simple chip/PCB that they could load the latest code into.

Here's where I started: http://fermi.jhuapl.edu/navigate/

If you go down near the bottom, there's a download of his source code. I only needed one function from his code. The comments in the code portion I ported indicate that it is "freely distributable". I'm not sure what that means for commercial use, but if I was to make my own commercial code, I probably would go back to the equations and develop my own, just to keep it clean.

The code is all done in C source double precision floating point, with a bunch of square root, tangent and arctangent functions. The easiest thing to do is use a development platform that has a C compiler available and use a processor with enough speed to crunch these out quickly. The ARM7 I'm using can do it in 642 usec.

For my development, I've been using a development board from Embedded Artists (http://www.embeddedartists.com/) that has a Philips LPC2138 ARM7 on board. It comes with a gnu c compiler installation that is really easy to get up and running with. The code would probably run just fine on one of the smaller parts like the 2103 which would get the chip cost down to about $3.

My current development has interrupt driven UART drivers that take in the GPS strings, parsers for the GPS sentences, and now the nav code. All I lack is some code to generate the RMB sentence, user interface for entering waypoints, code to cycle through the waypoints, and some waypoint arrival parameters. The ARM7 would have enough power left over to easily handle the rest of the RCAP functionality too, if we so desired.

MX

Mr.RC-CAM

May 11, 2006, 05:51 PM

I'm leaning toward open source on this. Let everyone work on source code, then maybe I can come up with a simple chip/PCB ... Are you saying that you need the community to create the working app? Or, will you create a standalone waypoint controller, with a simple user I/F, then let us at it?

Open source, after the original code is essentially complete, working, and debugged, is one thing. But, open source, at the get go, with just a smidgen of sample code, has not been very successful with these odd little projects.

Maybe we need to kidnap, chain, and force feed Jolt colas to a talented embedded programmer. In the spirit of catch and release, we would allow the fellow to leave after a few weeks (once the job is done). Now were did I put those leg restraints ...
:)

May 11, 2006, 06:11 PM

Are you saying that you need the community to create the working app? Or, will you create a standalone waypoint controller, with a simple user I/F, then let us at it?

Open source, after the original code is essentially complete, working, and debugged, is one thing. But, open source, at the get go, with just a smidgen of sample code, has not been very successful with these odd little projects.

I agree. I don't think code written by committee would work too well. It would get bogged down in discussions about what it should do, how we should do it, what we should do it with... I'm planning to continue with what I have, then make it available.

Maybe we need to kidnap, chain, and force feed Jolt colas to a talented embedded programmer. In the spirit of catch and release, we would allow the fellow to leave after a few weeks (once the job is done). Now were did I put those leg restraints ...
:)

If it wasn't for the day job, family obligations, etc. I'd have it ready for this weekend. :rolleyes: Just send cheeseburgers and diet (splenda) coke.

Mr.RC-CAM

May 11, 2006, 07:07 PM

Excellent. If it is not too much trouble, please provide a lot of source code comments so that the PIC and Atmel folks can port it without a lot of fuss. Who knows, maybe someone will jam it into the existing RCAP host.

LukeZ

May 11, 2006, 07:31 PM

Perfect! Cheeseburgers on their way! ;)

May 12, 2006, 03:03 AM

Got the code ported to and running on an 8051 chip - same family as used on ZLog and PRISM. In fact, I'm thinking I can just use the ZLog PCB. It's already got connections for serial in/out and power. I've got some chips with larger RAM coming that I will use. Needs more RAM to handle the GPS sentences. Calculation takes approx. 30 msec on this processor.

MX

Mr.RC-CAM

May 12, 2006, 11:28 AM

I'm thinking I can just use the ZLog PCB.
Hmm... Got room in the code for Barometric altitude too? :)

May 12, 2006, 12:43 PM

Hmm... Got room in the code for Barometric altitude too? :)

Maybe :)

May 17, 2006, 12:54 PM

Mr.RC-CAM

May 17, 2006, 01:23 PM

have the code running with a couple waypoints now. I've got it generating the RMC sentences with the range and bearing inserted.That is good to hear! BTW, the waypoints should be in the "RMB" sentence.

What are people's thoughts on the serial interfaces? My GPS is TTL output.The TTL output would probably be fine since it would eliminate the MAX232 from projects like the RCAP. However, PIC MCU's that are powered with 5V will not be reliable with 3.3V TTL serial, so it would be best if your board provided 5V TTL levels. For extra credit, real RS-232 level outputs would be nice to have too.

I'm curious, how much code space is devoted to the math portion of your code? I'm estimating about 2K for a PIC18F using the C floating point libraries in CCS. Your CPU is less RISC'y than mine, so I would expect it would be less. But, my numbers are just seat of the pants guesses at this point. :)

May 17, 2006, 01:54 PM

That is good to hear! BTW, the waypoints should be in the "RMB" sentence.

The TTL output would probably be fine since it would eliminate the MAX232 from projects like the RCAP. However, PIC MCU's that are powered with 5V will not be reliable with 3.3V TTL serial, so it would be best if your board provided 5V TTL levels. For extra credit, real RS-232 level outputs would be nice to have too.

I'm curious, how much code space is devoted to the math portion of your code? I'm estimating about 2K for a PIC18F using the C floating point libraries in CCS. Your CPU is less RISC'y than mine, so I would expect it would be less. But, my numbers are just seat of the pants guesses at this point. :)

Yes, I transfer the waypoint into the RMB sentence also.

I'm back to working on the ARM7 since I have better debug tools. I can fine tune the code and then think about porting to something smaller/cheaper.

The range/bearing calculation size is 0x03E0 (992 bytes). That does not include the C floating point library. Here's everything I pulled out of the
linker map that looks like floating point stuff:

sqrtf 0x00F8 248
sinf 0x01BC 444
fabs 0x002C 44
FPADD 0x0154 340
FPMUL 0x0168 360
FPDIV 0x0190 400
FCASTU 0x0054 84
atanf 0x012C 300
FPCONV 0x0190 400
fpatof 0x01EC 492
FPNEG 0x001C 28
FPCMP 0x002C 44
------
3184

So that's about 4000 bytes total to do a floating point nav calculation on the ARM7. Some of those functions are linked in to do some of the waypoint/GPS conversions I'm doing. Note that any additional calculations would just reuse the FP library code.

MX

May 17, 2006, 02:04 PM

Here's a sample of what was input to the waypoint engine and what comes out. I've hardcoded a waypoint of 40° 00' 00'' N, 122° 00' 00" W.

Input:

$GPGGA,055638.561,3930.8747,N,11959.6426,W,1,03,5. 6,21.1,M,-21.1,M,,0000*5A
$GPGSA,A,2,23,13,27,,,,,,,,,,5.7,5.6,1.0*35
$GPRMC,055638.561,A,3930.8748,N,11959.6427,W,1.25, 36.26,0.0406,,*2F

Output:

$GPGGA,055638.561,3930.8747,N,11959.6426,W,1,03,5. 6,21.1,M,-21.1,M,,0000*5A
$GPGSA,A,2,23,13,27,,,,,,,,,,5.7,5.6,1.0*35
$GPRMC,055638.561,A,3930.8748,N,11959.6427,W,1.25, 36.26,0.0406,,*2F
$GPRMB,A,0,L,000,001,4000.0000,N,12200.0000,W,180. 154,288.05,000.0,V*88

Mr.RC-CAM

May 17, 2006, 02:10 PM

Your floating point library sizes aren't too bad. At some point I'll try to code this using some custom crafted integer math using the example code links posted earlier. It would be nice to get the math to fit in a smaller footprint so that I can shoehorn it into my OSD.

It's good to see you're making progress. Did you get the cheeseburgers and diet sodas we ping'd to your IP address? :)

May 17, 2006, 02:12 PM

...It's good to see you're making progress. Did you get the cheeseburgers and diet sodas we ping'd to your IP address? :)

Nope, I guess nothing made it through the firewall :( :)

MX

Steve McBride

May 17, 2006, 04:39 PM

Update: have the code running with a couple waypoints now. I've got it generating the RMC sentences with the range and bearing inserted. I just need to add some code to upload the waypoints and store them in flash/eeprom, then I can start doing some real-world testing.

What are people's thoughts on the serial interfaces? My GPS is TTL output. Easiest is to make it TTL in and out, but some will probably want RS-232 levels.

MX

TTL out is fine. You should be able to handle TTL with a wireless modem and convert to RS232 levels on the ground (if modem use is desired). This would save a small portion of airborn weight (every gram can count).

typicalaimster

May 17, 2006, 07:14 PM

TTL out is fine. You should be able to handle TTL with a wireless modem and convert to RS232 levels on the ground (if modem use is desired). This would save a small portion of airborn weight (every gram can count).

There are dual GPS modules out there that output on both TTL and RS232. Just remember that RS232 is kinda sorta a standard.

May 17, 2006, 07:37 PM

TTL out is fine. You should be able to handle TTL with a wireless modem and convert to RS232 levels on the ground (if modem use is desired). This would save a small portion of airborn weight (every gram can count).

I was thinking of doing my first tests using the maxstream modems so I can monitor / log the waypoint outputs. That way I can also inject waypoints or commands into the waypoint engine on the fly:

Steve McBride

May 17, 2006, 09:05 PM

There are dual GPS modules out there that output on both TTL and RS232. Just remember that RS232 is kinda sorta a standard.

Yeah, this is true. If you need RS232 at the aircraft then it would be sorely missed (ie - RCAP2)

I was thinking of doing my first tests using the maxstream modems so I can monitor / log the waypoint outputs. That way I can also inject waypoints or commands into the waypoint engine on the fly:

That would be very cool ;)

I wish I could contribute to this effort. If you guys come down to wanting a bunch of circuits assembled, I would be happy to run them across my SMT assembly line as a hand to an 'open source' project.

Good luck with it!

Steve

May 17, 2006, 10:38 PM

Yeah, this is true. If you need RS232 at the aircraft then it would be sorely missed (ie - RCAP2)

Yes, but many of the OEM GPS modules are TTL and you can bypass the MAX232 on the RCAP2.

That would be very cool ;)

I wish I could contribute to this effort. If you guys come down to wanting a bunch of circuits assembled, I would be happy to run them across my SMT assembly line as a hand to an 'open source' project.

Good luck with it!

Steve

You have your own SMT assembly?! Might have to take you up on that when the time comes.

MX

Steve McBride

May 18, 2006, 12:47 AM

May 18, 2006, 12:58 AM

I have access to a very nice line at my day job (manufacturing engineer for an aerospace firm) and a smaller line at home for more personal jobs when the line at work is unavailable or not practical.

Steve

Must be nice! I'm sitting here right now hand soldering 0603 and TSSOP packages for a prototype Waypoint Engine :(

MX

LukeZ

May 18, 2006, 01:08 AM

MX,

Great work on the waypoint engine. This is exciting stuff.

I'd say do whatever you feel like on the RS232/TTL thingy - frankly, the code is what we need and that's the unique and original contribution. Hardware details can be addressed easily enough in the individual application, and anyways, if we're going to be porting this to other platforms and/or using it for multiple applications, then the hardware will be redesigned anyhow.

Thanks for working on this for us!

Luke

CrashingDutchman

May 18, 2006, 12:32 PM

May 18, 2006, 01:47 PM

Are you going to desing a whole new board?

If so, you might consider using this very light GPS: http://www.spectec.com.tw/en/sdg-810.htm (doesn't seem to work in firefox, but works in Internet Explorer).

It's a GPS engine developed for use in PDA's. It has a SD serial port profile and support 9600baud NMEA data. Check the specs...

Not sure if it is available already.

CD

Initially, I'm planning to use ZLog PCBs with only the necessary parts installed and a bigger processor, since I already have them on hand and they already have connections for serial I/O. We'll see how that works, then decide how to proceed from there.

That's an interesting looking GPS. I'm only planning to have an asynchronous serial input for the GPS with the baud rate configurable. I'm not sure what they mean by "SD-Serial interface at 9600 baud". SD/MMC interface uses SPI, which is a synchronous serial format. When you say "baud", it usually refers to asynchronous serial (with start bits, stop bits, etc.).

MX

typicalaimster

May 18, 2006, 02:49 PM

Thanks for working on this MX. Make sure you setup a paypal account that we can send Beer and Pizza money to ;)

May 18, 2006, 03:04 PM

...That's an interesting looking GPS. I'm only planning to have an asynchronous serial input for the GPS with the baud rate configurable. I'm not sure what they mean by "SD-Serial interface at 9600 baud". SD/MMC interface uses SPI, which is a synchronous serial format. When you say "baud", it usually refers to asynchronous serial (with start bits, stop bits, etc.)...

Got to thinking about that some more, and I suspect that the actual card interface is SPI, and on the Palm there would be a driver to setup a virtual comm port to make it look like 9600 baud serial to whatever Palm application wants to use it.

MX

May 18, 2006, 03:06 PM

Thanks for working on this MX. Make sure you setup a paypal account that we can send Beer and Pizza money to ;)

People are supposed to be FTP'ing me diet cokes and cheeseburgers, but they don't seem to be getting through my firewall. I'll have to see if I can allow access through the 0xFEED port or maybe the 0xBEEF port.

MX

Mr.RC-CAM

May 18, 2006, 03:24 PM

I'll have to see if I can allow access through the 0xFEED port or maybe the 0xBEEF port.That's the problem. It is best to open the firewall's 0xF00D port. Be sure the belly button mounted CAT5 jack is plugged-in when the uploads are occurring. Otherwise it will make a mess all over the hub.

Using the Zlog board for this is a great idea. The size is definately small. AND it no doubt will encourage you to include barometric altitude too, at least on your commercialized release. :)

May 18, 2006, 03:29 PM

That's the problem. It is best to open the firewall's 0xF00D port. Be sure the belly button mounted CAT5 jack is plugged-in when the uploads are occurring. Otherwise it will make a mess all over the hub. (I hate it when that happens :) )

Using the Zlog board for this is a great idea. The size is definately small. AND it no doubt will encourage you to include barometric altitude too, at least on your commercialized release. :)

Ahh yes, the 0xF00D port. And for the drinks, send to port 0xC01A.

Right now it doesn't look like both the waypoint engine and the altimeter code will fit. But I haven't done anything to optimize yet, so we'll see.

This still doesn't rule out the possibility that I might make a ZLog/Waypoint/PRISM/RCAP/kitchensink combo with the ARM, since it has plenty of flash and RAM. With RoHS requirements coming up, I may have to turn all my boards anyway.

MX

May 19, 2006, 02:50 AM

Ok, here's what I've got so far:

1) takes in GPS data at 4800 baud (or configured baud rate)
2) passes GPS data back out at 4800 baud (or configured baud rate)
3) parses $GPRMC sentences, extracting current lat/lon position and data valid (field 3 = 'A')
4) if data is valid, calculate range and bearing to waypoint and generate $GPRMB sentence. Some fields are dummies, but the range, bearing, wp lat/lon, wp numbers and arrival fields are good.
5) send $GPRMB out immediately following the $GPRMC sentence.
6) user can enter waypoints through serial port. for example, for a waypoint at 39°22.41' N, 122°47.68' W, user would enter: 3922.41,N,12247.68,W
7) user can list waypoints in memory through serial port.
8) waypoints are stored in on-chip eeprom. can handle up to 60 waypoints. hope that's enough.
9) serial command to set baud rate: 2400,4800,9600,19200,38400,115200.
10) serial command to set arrival distance - i.e. distance from waypoint that we say we have arrived.
11) configuration stored in the eeprom.

All seems to be working just by typing in GPS sentences. I'll get my EM-406 GPS hooked up soon to start pumping through real data.

What else am I missing?

MX

May 19, 2006, 04:12 AM

I hooked it up to my GPS. GPS is just sitting on the windowsill. Output data attached. Anyone want to plug the data into an RCAP2 and make sure it doesn't choke on it?

MX

Steve McBride

May 19, 2006, 06:52 AM

Fantastic work MX! About the only thing I can think about is looking at how various mapping software packages deal with creating and uploading waypoints and see if your's is compatable with them. That and the BP altitude sensor, but I think you've come a long way.

Your hard work is appreciated!

Steve

d_wheel

May 19, 2006, 08:07 AM

A nice feature would be to have the sequencer store the starting lat/lon as the last waypoint. If no other waypoints are stored, it should skip to the last one and "return to home".

Later;

D.W.

May 19, 2006, 08:16 AM

A nice feature would be to have the sequencer store the starting lat/lon as the last waypoint. If no other waypoints are stored, it should skip to the last one and "return to home".

Later;

D.W.

Already does that! :)

MX

May 19, 2006, 08:19 AM

icebear

May 19, 2006, 11:51 AM

Garmin Mapsource is easy to use and has an export function in .txt format.
Here's an example of the file output.

/Icebear

Grid Lat/Lon hddd.ddddd°
Datum WGS 84

Header Name Description Type Position Altitude Depth Proximity Temperature Display Mode Color Symbol Facility City State Country Date Modified Link Categories

Waypoint DA002 Solrosvagen User Waypoint N56.16326 E12.57244 Symbol & Name Unknown Waypoint 5/15/2006 6:46:16 PM
Waypoint DA003 Solrosvagen User Waypoint N56.16360 E12.57022 Symbol & Name Unknown Waypoint 5/15/2006 6:46:33 PM
Waypoint DA004 User Waypoint N56.16468 E12.57040 Symbol & Name Unknown Waypoint 5/15/2006 6:46:46 PM
Waypoint DA005 User Waypoint N56.16460 E12.57258 Symbol & Name Unknown Waypoint 5/15/2006 6:47:01 PM
Waypoint DA006 Solrosvagen User Waypoint N56.16322 E12.57270 Symbol & Name Unknown Waypoint 5/15/2006 6:47:10 PM
Waypoint DA007 User Waypoint N56.16317 E12.57383 Symbol & Name Unknown Waypoint 5/15/2006 6:47:23 PM
Waypoint DA008 User Waypoint N56.16463 E12.57411 Symbol & Name Unknown Waypoint 5/15/2006 6:47:35 PM
Waypoint DA009 User Waypoint N56.16477 E12.57220 Symbol & Name Unknown Waypoint 5/15/2006 6:47:47 PM
Waypoint DA010 User Waypoint N56.16345 E12.57191 Symbol & Name Unknown Waypoint 5/15/2006 6:48:00 PM
Waypoint DA011 User Waypoint N56.16386 E12.56991 Symbol & Name Unknown Waypoint 5/15/2006 6:48:08 PM
Waypoint DA012 User Waypoint N56.16493 E12.57005 Symbol & Name Unknown Waypoint 5/15/2006 6:48:34 PM
Waypoint DA013 User Waypoint N56.16476 E12.57207 Symbol & Name Unknown Waypoint 5/15/2006 6:48:55 PM
Waypoint DA014 User Waypoint N56.16344 E12.57208 Symbol & Name Unknown Waypoint 5/15/2006 6:49:03 PM

Header Name Length Course Waypoints Link

Route DA002 to DA014 1.6 km 313° true 13 waypoints

Header Waypoint Name Distance Leg Length Course

Route Waypoint DA002 0 m
Route Waypoint DA003 143 m 143 m 286° true
Route Waypoint DA004 263 m 120 m 5° true
Route Waypoint DA005 398 m 135 m 94° true
Route Waypoint DA006 553 m 154 m 177° true
Route Waypoint DA007 623 m 70 m 95° true
Route Waypoint DA008 787 m 164 m 6° true
Route Waypoint DA009 906 m 119 m 278° true
Route Waypoint DA010 1.1 km 149 m 187° true
Route Waypoint DA011 1.2 km 132 m 290° true
Route Waypoint DA012 1.3 km 119 m 4° true
Route Waypoint DA013 1.4 km 126 m 99° true
Route Waypoint DA014 1.6 km 146 m 180° true

icebear

May 19, 2006, 11:54 AM

And the corresponding waypoints / route...

/Icebear

May 19, 2006, 01:09 PM

Garmin Mapsource is easy to use and has an export function in .txt format.
Here's an example of the file output...

That's a pretty verbose format. Given the memory limits I have, it may be better to use a PC based utility to translate and download the waypoints for various formats.

MX

Edit: By the way, I'm using WGS-84 datum in the calculations. Is that what everything else uses?

Steve McBride

May 19, 2006, 02:30 PM

I hooked it up to my GPS. GPS is just sitting on the windowsill. Output data attached. Anyone want to plug the data into an RCAP2 and make sure it doesn't choke on it?

MX

Funny - I used this file with GPS Gate to feed Topofusion. For some reason it showed around a 10mph track speed?

Guess I need to play with GPS Gate and Topofusion more ;)

If I put this into a GPS on a RCAP2 in an airplane, would it fly to your house? :D ;)

May 19, 2006, 02:41 PM

Funny - I used this file with GPS Gate to feed Topofusion. For some reason it showed around a 10mph track speed?

Guess I need to play with GPS Gate and Topofusion more ;)

If I put this into a GPS on a RCAP2 in an airplane, would it fly to your house? :D ;)

Yes, at startup, it seemed to think I was moving, but it settles down to near zero speed. I think the EM-406 (Sirf III) I'm using tends to bounce around with the speed when it's sitting still, but once moving is very sensitive and accurate. Or maybe I'm measuring continental drift. :rolleyes:

If you use the current lat/lon coordinates, it will get you to my house (Hexpert Labs). But if you follow the GPRMB waypoint, it will take you to about 122 km northwest of here, which would put you somewhere around Chico, CA.

MX

typicalaimster

May 19, 2006, 03:18 PM

Good idea. What are the various software packages we might use to download waypoints? Anyone have some samples?

Here is the output from a gpx formatted file from TopoFusion. The only thing that changes between programs is the headers....

<?xml version="1.0" standalone="yes"?>
<gpx
xmlns="http://www.topografix.com/GPX/1/0"
version="1.0" creator="TopoFusion 2.85"
xmlns:TopoFusion="http://www.TopoFusion.com"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/0 http://www.topografix.com/GPX/1/0/gpx.xsd http://www.TopoFusion.com http://www.TopoFusion.com/topofusion.xsd">
<url>http://www.topofusion.com</url>
<urlname>TopoFusion Home Page</urlname>
<time>2006-05-11T19:13:56Z</time>
<bounds maxlat="39.066266" minlon="-77.381274" minlat="39.061102" maxlon="-77.374952"/>
<wpt lat="39.061915" lon="-77.378370">
<name>Start</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.062909" lon="-77.378225">
<name>WPT1</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.063890" lon="-77.379820">
<name>WPT2</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.064926" lon="-77.381274">
<name>WPT3</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.066266" lon="-77.379391">
<name>WPT4</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.064810" lon="-77.374952">
<name>WPT5</name>
<sym>Waypoint</sym>
</wpt>
<wpt lat="39.061102" lon="-77.375375">
<name>Finish</name>
<sym>Waypoint</sym>
</wpt>
<rte>
<url>http://www.topofusion.com</url>
<urlname>TopoFusion Home Page</urlname>
<rtept lat="39.061915" lon="-77.378370">
</rtept>
<rtept lat="39.062909" lon="-77.378225">
</rtept>
<rtept lat="39.064040" lon="-77.380064">
</rtept>
<rtept lat="39.064926" lon="-77.381274">
</rtept>
<rtept lat="39.066266" lon="-77.379391">
</rtept>
<rtept lat="39.064810" lon="-77.374952">
</rtept>
<rtept lat="39.061102" lon="-77.375375">
</rtept>
</rte>
<TopoFusion:color>ff0000</TopoFusion:color>
<TopoFusion:graph>0</TopoFusion:graph>
</gpx>

Steve McBride

May 19, 2006, 04:32 PM

Here is the output from a gpx formatted file from TopoFusion. The only thing that changes between programs is the headers....

</gpx>
[/CODE]

I like Topofusion too. They guys that have developed this application seem to be open to the idea of a custom software package for our needs. If there is enough interest in it to justify the development that is. They seemed to indicate that some of the ideas I had (rate of climb/descent gauges, artificial horizons, etc.) would be relatively easy to implement.

I guess there are a few different standards for this type of data, this one being 'gpx' format. Perhaps those of you with other software packages can list their method of handeling waypoints.

typicalaimster

May 19, 2006, 05:55 PM

I guess there are a few different standards for this type of data, this one being 'gpx' format. Perhaps those of you with other software packages can list their method of handeling waypoints.

I bounce between TopoFusion and Expert GPS. There is some things I like about route planning in Expert GPS. I really enjoy the 3d views you can get with the Topofusion software. I usually save as GPX since it works in Topofusion, Google Earth, and Expert GPS...

Can someone with Mapsource see if you can 'save as' GPX. I think it's a universal format but I'm not sure..

Steve McBride

May 19, 2006, 06:37 PM

It looks like you can export as GPX in Mapsource:

http://www.garmin.com/support/download_details.jsp?id=209#Instruct

At least that is what I gather where they mention having fixed a bug with exporting GPX.

Have you run MX's NMEA file through Topofusion? For some reason it does not gather the maps for that area.

Steve

EDIT - nevermind - Topofusion was slow I guess - working now.

May 21, 2006, 12:25 AM

Did a little walkaround test today in the front yard to see if it would correctly detect when it was within range of a waypoint and cycle to the next one in the list. I've got my waypoint engine programmed to determine whether I should turn right or left based on the difference between current heading and current track bearing. I have LEDs that indicate left and right turn so I can walk and follow its directions to see if I get there. Then it pulses another LED when I have arrived and moves to the next waypoint.

After I fixed a problem with my units, it worked. I had the arrival range set to 5 meters. For aircraft use, the range should probably be bigger or you'll end up flying tight circles around a spot but never actually getting there.

Tomorrow I'm going to try and do a walking test around a big parking lot that I happen to have a good straight down AP shot of. Seems like a while back someone mentioned some software that would load a photo and you could then give a couple of known lat/lon coordinates and it would scale accordingly so you can overlay your GPS data on it. Anyone know what software does that? I'd like to overlay tomorrow's data on my photo.

MX

Steve McBride

May 21, 2006, 10:14 AM

May 21, 2006, 10:21 AM

U-Blox 'U-Center' application will do this.

http://www.u-blox.com/products/u_center.html

It's free and I really like the dockable compas, altimeter and speed indicator.

Problem is that I've never got a map to calibrate correctly. I'll get the aerial photo and then use an applicaiton like Google Maps to determine the lat and long and then calibrate, but it's always off. I'm sure it's something that I am doing wrong though.

Steve

I plan to walk to the waypoints first and get good lat/lon readings with my Magellan, load those waypoints into the waypoint engine, then do it again with the waypoint engine leading the way. I chose good reference points from the aerial photo, so maybe I'll get a pretty good correlation in the u-blox software.

Thanks for the link,

MX

May 21, 2006, 10:22 AM

U-Blox 'U-Center' application will do this.

http://www.u-blox.com/products/u_center.html

It's free and I really like the dockable compas, altimeter and speed indicator...

Darn, u-blox requires a username and password to access. :(

Any other applications out there?

MX

Peter Seddon

May 21, 2006, 11:08 AM

I ahve used OziExpolorer to underlay maps onto to GPS track data. The map can be in many different formats and you can calibrate it using two or more points on the map.

Regards Peter

Steve McBride

May 21, 2006, 12:52 PM

you can register for free - they don't spam you.

I've posted it on my site for you to download - I think you'll like it:

http://eflightcentral.com/programs/uCenterSetup.zip

The difficult thing about calibrating your own maps with this is that you first determine the pixel coordinates of a feature on the image, and then tell it what the lat and long are of these pixels. Not really hard, but seems to be a bit more combersom that I would like.

Steve

May 21, 2006, 05:34 PM

typicalaimster

May 21, 2006, 08:43 PM

Don't feel bad I have some stuff coming out of Skunkworks off to Area 51.. The bad part is it's blowing about 20mph out right now.

I know ExpertGPS lets you import your own map. You then pick 3 points on the map to fix the image.

May 24, 2006, 01:54 AM

Ok, got out to test the waypoint sequencer (WPS) tonight. First I went to each of the waypoints with my handheld Magellan 330M and wrote down the waypoints. Then I loaded those into the WPS. With daughter's help, we took off walking. I was carrying the laptop, watching the data stream in, and she was looking at the WPS, calling out right or left as indicated by the LEDs. There was a problem with the startup and it skipped straight to waypoint 3 for some reason (maybe eeprom offset problem?), but once we got on track it guided us to each of the successive waypoints perfectly. I also had it light another LED when we had arrived at each waypoint and it was pretty much right on the waypoints when it lit (5 meter range setting). Attached image shows the waypoints. Yellow lines are the route just drawn on there to make it easier to see the paths we were following. The red track is us walking and being guided by the WPS. The track is a bit winding, since we had to avoid bushes, light posts, rocks, cars, buildings, etc. Especially between WP06 and WP07, where we had to detour around the building. Also, I had the LEDs light up for left or right when we were only 1 degree off, so we were constantly changing direction. Probably looked like we'd had a few too many. An airplane should look a lot smoother.

MX

May 24, 2006, 02:06 AM

...There was a problem with the startup and it skipped straight to waypoint 3 for some reason (maybe eeprom offset problem?), ...

Checked code, found problem with initialization of the starting waypoint index.

MX

Steve McBride

May 24, 2006, 08:55 AM

May 24, 2006, 10:33 AM

Well that certainly looks promising. I would say that the actual track was within the error of a typical GPS and certainly good enough to get you within 25-30 feet it appears.

Great work MX!

Steve

PS - Oh - how are you liking ExpertGPS? I have not used it enough to have an opinion yet. Was it easy to calibrate the map? What source did you use for the aerial photo?

Still learning how to use ExpertGPS. Liking it so far. I tried to load the same data in Topofusion and it just hung.

The aerial photo is one I took last fall. It's the final photo of my 2-year documentation of the church construction progress. Taken from a slow stick with Optio S4 and PRISM switch at about 1500 feet AGL.

The calibration was easy. Just click the calibrate icon and click on the map in 3 different places. For each place, enter lat/lon. Since I had walked it with the Magellan, I had plenty of good points for calibration. I don't think the calibration came out exact, because my aerial photo is not perfectly orthogonal. It's at a slight angle as evidenced by one side of the building being visible. Some of the waypoints that we walked to hit exactly, whereas in the map, it looks like we missed by a few meters.

MX

May 24, 2006, 08:43 PM

Where did everybody go? I was hoping for a little more feedback than just Steve (thanks Steve). Is there no longer interest?

I've got parts to make up some prototypes. Will people be interested in those at around cost as beta testers? New software can be loaded through the serial port (requires separate RS-232 - TTL converter).

MX

typicalaimster

May 24, 2006, 09:06 PM

I'd be more than happy to beta test the device. So far it looks good. Just PM me the info and I can send funds on Friday.

Steve McBride

May 24, 2006, 09:14 PM

I have that effect on threads.

I'd love to be a beta tester. Keep in mind that I can build any hardware you throw at me. It's the software stuff that I can't do, but I can follow directions LOL. Also know that I don't have an autopilot yet as I was wanting to wait on the new RCAP2.5 to be released. I understand if you would rather the betas go to people who can fly them with an autopilot first. I could do a bit of ground testing and telemetry testing until then.

What does the prototype consist of and what is the estimated cost?

Steve

PS - one thing I didn't ask, and it may be irrelevant, but will this waypoint sequencer have any problems with NMEA at 9600 baud instead of the standard 4800? Sentences still output at 1hz of course.