PDA

View Full Version : new autonav / GPS / IMU / OSD !!!


Pages : 1 2 [3] 4 5

corvette321
04-29-2008, 11:29 AM
on the full IMU version, yes there will be a a post ADC filter, a kalman, then PID.

on the light version no.

unfortunately its software floating point on the pic 32, but with all the features we have accomplished so far on the dspic 33 at 40 mips, it is no problem to accomplish that and the addition of the kalman.

we will still be going through and streamlining code more for speed and shortest execution time and moving as much into hardware DMA as possible (pic 32 has DMA also..)

DMA is your friend!!!!

corvette321
04-29-2008, 09:48 PM
got the SCP1000 working...

can measure temp and pressure now..

pressure is pretty accurate output!!! fluctuates about 10-25 Pa. not too shabby

but need to feed this a corrected standard pressure at sea level to compensate for low presure or high pressure systems...

(the pressure here today was like 29.xx something "... which is a little low..)

so im wondering if i should take the initial GPS good altitude fix, and match it to that the startup pressure reading, then redo the altitude equations based off of that adjusted pressure at that altitude...??

but that would require a higher threshold for the GPS start....

so thats option #1.

option #2:

calculated altitude based on standard day conditions, then subtract to zero all sbsequent readings....hmm but its not a linear relationship... so that woudlnt work good.... wouldnt be accurate...

but if i get a bad initial GPS altitude number then all subsequent would be bad too.

hmmmm

decisions decisions!!!

:arggg::arggg:

corvette321
04-29-2008, 09:51 PM
option #3

have a box to input local known altitude.

this would be the most accurate method.

but too much of a hassle.

ill try the GPS initial altitude method and set high thresholds for VDOP and # of sats.

nope... that method sucks... the GPS alt can be pretty inaccurate at times.. unless u have like 10-12 sats...

ill try to do an AGL on startup for the SCP1000 and set initial altitude to zero at that given pressure.

i think itll work.

Neil_J
04-29-2008, 10:47 PM
option #3

have a box to input local known altitude. this would be the most accurate method.
but too much of a hassle. ill try the GPS initial altitude method and set high thresholds for VDOP and # of sats.

Why not just 'zero' it, i.e. use AGL (http://en.wikipedia.org/wiki/Above_ground_level)?.. trips will be pretty short I'd imagine, no need to worry about your relationship to sea level or any other references.

Also you may already know this but I'll point it out anyway.. Most GPS receivers output altitude in WGS-84 (http://en.wikipedia.org/wiki/WGS-84) which is pretty meaningless in aviation (If you're taking your altitude from the $GPGGA message, it's geoid altitude for sure). How high you are above an imaginary ellipsoid is irrelevant (the earth's surface being irregular and all). You would need to convert this via an algorithm to MSL, or just zero it out and call it AGL if you're lazy. (I would recommend being lazy in this case)

As far as GPS accuracy goes.. Altitude taken from GPS with WAAS should be accurate to a few meters. It's accurate to the point where you may want to have the GPS be a backup for the barometric altitude. If your pitot-static system gets clogged with something, the indicated altitude would most certainly be affected. WAAS-corrected GPS on the other hand is pretty reliable. The problem on the Etek of course is that it doesn't tell you when the corrections are being applied. Nicer receivers will give you this but they get expensive quick. A dirty hack for the Etek would be to make sure that at least one SBAS satellite (PRN# >= 120) is currently being tracked, and has been for at least a few minutes. Corrections usually kick in at that point unless there are obstacles blocking the antenna or a (very unlikely) satellite problem.

corvette321
04-29-2008, 11:12 PM
yah we alread have the MSL from the gps and AGL also (*as an option...) it zeros out nicely if thats what u want.

this is for the optional SCP1000 altimeter module using barometric pressure and temp. which is much more accurate once u get the initial pressure and altitude right.

yes outdoors of course a much better fix hahah :) the altitude with 10-12 sats is great but below that the alt is off.....

could also use SCP1000 as an airspeed indicator....

ahh the possibilities are endless.

:rolling:rolling:rolling

corvette321
04-30-2008, 12:07 AM
just in case anyone else is interested in altitude from pressure calculations....

kansas city flyer explains it all really well!!!


(as does the VTI AN33 app note....)

http://www.kansasflyer.org/index.asp?nav=Avi&sec=Alti&tab=Theory&pg=6


ill be using GPS data and see how it goes... set for a high threshold and ill test it outside.

that will set the "current day" pressure to what it is now, the pressure at the current altitude and adjust the equation to be accurate.

then well see how accurate this baby turns out to be!!

ill report back..

hope im not posting too much here, i know its hard to follow all these posts!!

:)

corvette321
04-30-2008, 06:42 PM
got my hands on another FV-M8 gps (etek eb 85a) now sold my san jose navigation (no more etek...)

im updating it to 5hz rate and hmm ill try 38400 baud rate.


oh and im gonna try DGPS also!!!!!!!!!!!!!!!!!!!!!!!!!

:)

corvette321
04-30-2008, 07:18 PM
got it working at 5 hz now!!!

really fast! very happy with the FV-m8....

will see how the alt works with WAAS....

hopefully itll get accurate!!!

the reason for this is to get a good iniital altitude via GPS and an initial pressure to feed into the pressure at sea level adjusted equation.

this gives us the current day pressure at sea level.

once we have that we should have very accurate altitude based on pressure from the SCP1000.

how accurate? im hoping sub foot once i add the averaging algorithm to the pressure output... right now its 19 bits about 10-25 Pa...... im gonna average that out....

this is insanely accurate!!!!

corvette321
05-01-2008, 12:28 AM
did some tests with WAAS enabled.... gonna go ahead and stick with this since its cheaper than RTCM DGPS and not necessarily available everywhere too, well coasts or u have your own transmitter....

however the RTCM update DGPS option is still an option on this controller. the port is there.

i have seen a DGPS RTCM receiver kit before but now it disappeared... where did it go hmmmm..

corvette321
05-01-2008, 04:24 PM
well today had a nice little 50 mile drive and took the techFX motion to look at the waas and pressure readings (with a 3 place rolling average filter)...

i need to make a bigger rolling average filter or better yet use a (throw away high and low and average middle 2 rolling filter...) that one would work nice....

hmm what else..

oh yah my idea with 2 GPS receivers was to use DGPS WITHOUT RTCM or WAAS... how and be more accurate than WAAS? was gonna send data over zigbee to a computer base station, and run this software. then send fixes back.

http://www.precision-gps.org/

but wow thats alot of work!! not enough processing power to do the math on the little baby dspic...

so it looks like WAAS is the solution for now and its working great today.

accurate hot day!! altitudes are right on whe outside... inside by the window, not so right on....so ill get the initial altitude value from there to feed the alt barometer equations and adjust for "current day" pressure readings....

however the DGPS port for RTCM messages will still be an option to whoever has a receiver that can output those messages... (and u can use your own base station solution too to get sub meter accuracy!!!)

so everythign is cool!!

:smokin::smokin::smokin:

r40734
05-01-2008, 06:15 PM
hope im not posting too much here, i know its hard to follow all these posts!!

:)

Nope, you're not posting too much. It keeps us informed to the fact that you are actively working on this product. Keep it coming :thumbup:.

corvette321
05-02-2008, 08:19 PM
got the 5.8 ghz wireless transmitter and reciever together today (the modules sold on www.dpcav.com (http://www.dpcav.com))

bought some cheap radioshack boxes and mounted them. it works pretty nicely!!

a little noise in the picture but itll work just the same...

havent distance tested the modules yet...

they draw around 300 mA of power......

im using pcb patch antennas!! shoulda sprang for the connectors and nice antennas.......

DigitalCop
05-03-2008, 03:52 AM
Though I am unable to digest all of the technical information that you are presenting... I am hoping for a Carvec-like system that is within the financial reach of the blue collar class heli pilot.

Of course, AP work is the big ticket, though stealthy strafing runs at my neighbor's cat would pay less but be just as enjoyable.

corvette321
05-03-2008, 11:23 AM
once we start developing on the pic 32 (after this 1st release) we will have some real world applications!!!

all the code we are writing right now is a basis for the pic 32 full IMU version which will be ported over to it...

and yes the 1st funtions will be applicable to AP !!!

(as i personally am getting into AP also!!).

:banana:banana:banana:Bang:Bang:Bang:Bang

corvette321
05-05-2008, 12:56 AM
weve dropped the hz down from 5 hz to 2 hz....

why?

to save processing power to do other things like run the gps logger and the math algorithms for the accessories.

we are definately gonna do the 3 axis tilt compensated compass... that is just an oustanding feature that nobody is offering...

it is a tradeoff for us between GPS update rate and options.... and WE WANT THE OPTIONS!!!!

we dont have the pic 32 compiler license yet so we cant compile code on that platform yet..... but hopefully soon!

sooo... we are parsing 4 sentences at 2 hz + all the other modules and floating point math we are doing, and precision too!! not the inaccurate formulas.

parsing GGA, VTG, RCM, GSA sentences.

the san jose nav FV-M8 module settings should be set at:

2 hz fix rate.

"1" for all those sentences, and "0" for all others. (note that this is not the hz rate!! as verified through a terminal program.....ie: if i had 5 here and a 5 hz fix rate that would output once per second... so it seems to be a divider.... therfore having a 5 hz fix rate and putting 1 in each sentence would output 5 timers per second as verified in a terminal widnow.... just a little good info about mini GPS v 1.4 utility)

anybody speak ESC? lol.... yay it plays songs on my motor.... (not a heli...)

i know alot of them are common yes, but if you dont have the manual and u have an "unbranded" one, then those beeps may need a translator.....

thank god for an ESC programmer, cause doing it with the throttle sucks.

heli platform will be next we promise!!!

:thumbup::thumbup::noteworthy:noteworthy

ssozonoff
05-05-2008, 06:16 PM
Slightly off topic but relevent in any case.

http://www.mikrokopter.de/ucwiki/en/MikroKopter/

These guys have an awsom IMU (With Alt. hold etc ..) which has proven itself 100s of times in a Quadrocopter.

The videos are to say the least most impressive.
http://www.mikrokopter.de/ucwiki/VideoAbspielen?id=75

And its also open source .. code, hardware, schematics ... all of it.

I would imagine that it should not be too difficult to adapt this thing for use in a Heli???

Maybe you guys can grab some ideas.

Serge

corvette321
05-05-2008, 08:33 PM
great link!!

always loved the idea of a quadrocopter :)

has anyone built one?

corvette321
05-05-2008, 11:23 PM
got to test out the baro altimeter, and the method of using the GPS initial altitude (after the 1st goof fix past HDOP, VDOP, PDOP, SATS threshold levels....) for computing the sea level pressure......

and if you are outside, the initial altitude is very correct from those equations!!!

but change # 669

it will be an option to use the standard 101315 Pa sea level pressure or use the initial GPS altitude after 1st threshold fix to calculate a corrected sea level pressure based on the pressure at the good fix.

so options options options!!!!

where were the days when u could plug it in and go?

well you can do this yes, but making informed decisions and advanced options for accuracy is something we all need in certain situations.

:cheers:cheers:cheers

there was a bug prohibiting updates after the initial fix, (a stack overflow... oops..) however will test it out again tomorrow and well see how she goes!!!!

:thumbup::thumbup:

been getting tons and tons of requests for this controller and the full IMU version!!

its coming soon we promise :)

as you may know, the baro alt is much more stable than the GPS alt..... it wont jump around like crazy.

and thus is the basis for an altitude hold (combined with other MEMs based sensors , accelo and gryos...)

so getting this right is key to the more advanced features of this controller and the full IMU version that is coming.

corvette321
05-05-2008, 11:25 PM
oh some people may say the san jose FM-v8 sucks for altitude ...

well GPS sucks for altitude yah, it jumps around and is inaccurate...

but from the tests we have conducted, using our software thresholds, settings VDOP thresshold to 1.0 and others good also, we can get an accurate initial altitude which is all we need to start up the baro alt.

and that is what i was really worried about anyways!!!

iflybyu77
05-06-2008, 02:20 PM
What a neat idea using the GPS receivers themselves to refine the position. That was a neat post itself.

Sounds like things are moving along. I watched the Mikrokopter development for a while and became frustrated by the language barrier and lack of true "this is what you need, and this is how you do it" information. You, on the other hand, you've given about 130% more than some can comprehend. :D At least on the development/coding side..

corvette321
05-06-2008, 03:31 PM
the manual will explain the theory and the application also :) so someone can pick it up not knowing anything and udnerstand the equations behind the options...

i think that is important.


got the baro alt filter working great today!!

approx 1 foot or better accuracy (well thats in this computer room, still gonna go test it outside...)

dont have a pitot tube for it right now...

basically we put a 1st order IIR low pass filter on the pressure readings... and sample as fast as possible...

so therefore depending on the coefficient we put on it, shows how fast a new value will scale (and the cutoff of the noise from our value....)

so it takes time for it to goto its new pressure value...

we didnt implement a higher order IIR filter for it to save processing power...

this one is good.

the grounds for an altitude hold - auto hover :)

will test it greater outside.

:banana:banana:banana:banana


it takes time, and most readings in the same direction for the output pressure readings to move...

there are better filters to use which can provide greater accuracy... may try one.

but the tradeoffs are sluggish performance, if we set our filter for less variance then we will get sluggish performance.... so we have to come to a compromise.

we may try some other filters also and try to get better performance.

havent quantified how accurate the filter is below 1 foot....... willt ry to see what the resolution is...

gotta slow down the display rate for that value :):Bang:Bang

corvette321
05-06-2008, 03:38 PM
oh yah forgot to say, we are getting about 3-4 Pa variance in our pressure output!!!

so yah !! its super precise with the filtered data.

just checkiing it with the equations gives us about 1/10 of a foot accuracy..

however watching the display we get a drift of about half a foot...

I can live with half a foot accuracy!!

will check the real accuracy with a ruler and outside...

corvette321
05-06-2008, 04:32 PM
just gave it a quick test outside, yes half a foot accuracy!!

it was hard to test at speed, becuase we dont have a pitot tube handy (seen them somewhere for 30 bucks..


anyone got a cheaper pitot tube supplier?? looking for a small 4-6 inch one.

10 dollars would be nice.

corvette321
05-06-2008, 04:35 PM
also adding the position fix threshold value to the startup.

this will allow us to wait for either a 1=SPS fix. (which is what we usually want as a minimum

or a 2= DGPS pos fix (WAAS included!!)

that is our high precision threshold..

so we can wait for the OSD to start based on that value.

corvette321
05-07-2008, 12:33 AM
okay testing is going wonderfully!!!

did a waypoint test today, and returning back to home was within 10 feet of start so thats cool, thats using the haversine formulas...

using barometer altimeter with AGL, got me within 1 foot oh home startup altitude so thats cool.... (thats without the pitot tube... need to get one...) i think eagletree sells a pitot tube cheap.


very happy with the results!! the DGPS is kicking in now and working great. not gonna even try out RTCM DGPS at this point in time.

gonna be looking for some heli beta testers really soon :)

these beta testers will get a big discount. prolly need just 2 or 3 on heli's.... then another 2 or 3 on planes...(i know the ground works great cause ive driven it all over the place!!)

but basically looking to verify operation and get feedback for firmware changes.

i would like these testers to try out the setup with the optional 2 axis compass (for heading info under 1-2 MPH... we think that option would be great for helis....(as also for ground based vehicles..)

if you have a heli with servo pan and tilt camera controls then that is a hugggge plus as we will include software for that feature.

still waiting on some parts to get the aerial platform up in the air...

then will have a cool video to show.

planning to setup cones for home and target locations to verify the accuracy of the unit on Video with OSD output!!

it should be really cool!!

:banana:banana:banana