Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

because it things that there is a discontinuity (in fact there is a numerical discontinuity) and I've not found a representation that does not have a discontinuity as yet.

Look at quaternion coordinates. They do not have the problem. But they require an extra set of transformations.

Edited by cyber-flyer

Share this post


Link to post
Share on other sites

Actually I found that even within the quarternion representation, there exists a discontinuity as you go from -180 to +180. One of the dimensions go from +1 to -1 and that will throw off the filter. Fortunately, there is a much simpler solution to this problem and I'm hoping that it will work. I've actually already written the code but a couple of wires broke off the IMU due to all the twisting while testing and I've not gotten round to actually re-soldering them just yet.

Daniel

Share this post


Link to post
Share on other sites

Well, get with it already then!! ;) Just kidding Daniel. :) You're doing some great work and we all can't wait to see the end result. Take your time though. Better to get it right the first time, than to have to do it again. B)

Share this post


Link to post
Share on other sites
p.p.s. For best altitude, you probably want a . Other than that, some tests have shown GPS altitude to be better than most people assume. If anyone is interested, I have a link to the test somewhere. Single ported barometric altitude sensors are subject to indeterminacy arising from variable air speed. As for the ultrasonic stuff, I may yet use it but for a slightly different reason but that's not going to materialize in this version of DragonOSD I'm afraid. We're just so tight on memory right now.

How accurate is the reading you recieve?? Is it GPS standard +- 5 meters?

Share this post


Link to post
Share on other sites

Over a period where good GPS reception is available, the GPS is within 4% of the barometric altitude, and in some cases more accurate than the barometric altitude. This may also be related to the poor implementation of barometric altitude sensors that are common, relying on single ported sensors when a proper implementation would actually call for a dual sensor arrangement. Those of you who want to know more, check out the research paper by J.D. Andrew Graham entitled "Raw GPS for Vertical Navigation". Here is a quote from that paper:-

These data show that the raw GPS vertical NSE remained within +-20 feet while the barometric altimeter error vertical NSE ranged from +65 to -50 feet. In addition to the larger values of the NSE, the barometric altimete demonstrated significantly higher levels of noise than GPS.

I submit to you that a lot of what's floating around as "common wisdom" regarding barometric sensors are somewhat anecdotal and uninformed by actual research.

Daniel

p.s. FWIW, the IMU board actually (optionally) carries an SCP-1000 barometric pressure sensor.

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

I have never done anything like this before and will propably ask a lot of stupid questions... Here comes another one...

I saw a test setup comparing two GPS:es... It looked like there were two boards connected with a sync signal...... Would it be possible to use two separate boards connected to the same bob so one can handle the sensors and let an addon board read out the data on the uart to handle addidtional tasks?

For example the AutoPilot with an array of waypoints could be extended into having tasks at each waypoint, like take a photo, as servo1) (drop candy, as servo2) for each waypoint, and maybe ILS if close to home???(I know outputs are an issiue here for tasks if implemented on the current board but still...)

I looked at the list price for a pic controller and found it to be a lot cheaper than i thought... is there a limitation why you dont use two if the memmory is an issue for functionallity?

I looked at the code and it seems not to be to hard to understand. (Except the asembler part... :D )And with some help, books and many many hours of frustration i could get such a project a try.... (Sorry inspired like crazy ;-) )

Maybe these things are just a bunch of ideas to put in the big bin but still i had to share them. Sinse i am VERY new to all this i know that some of my ideas maybe should be an entire new project, correct me if im wrong here... ;)

I just post here by the moto: Great functionallity starts out as a crazy idea!

Keep up the good work! And thank you for all your great work so far!

Cheers

Bx3mE / Daniel Olsson

Edited because of "Late night brain farting".......

PS. Ill try to get my Dragon project running as soon as possible (waiting for reply from MH)DS.

PS2. While waiting im planning on building my own board. Sinse the eagle drawings in post 7 are removed could you please post an update of what u got?? DS2.

Edited by Bx3mE

Share this post


Link to post
Share on other sites

The two boards were IFOSD's, stacked one on top of another feeding from one into the other. YOu could do that with dragonosd's but not using the one bob4.

We plan to eventually put a scripting language into the DragonOSD Pro version which we're working on, this would allow you to script waypoints and make things happen when you get there. If your dropping candy, please do so near my house :)

If you want to work on code, getting a MikroElectronica dsPICprog is the best thing you can do for yourself. It connects to the IDE we use and allows you to watch the MCU running through code/pause it and such. Fantastic for debugging code!

The old board schematics are not compatable with the V1/V1.1 boards, you wouldn't be able to use the IMU or expansion ports, or the newer source code on there.

Share this post


Link to post
Share on other sites
If your dropping candy, please do so near my house :)

Haha if i can find a battery that can transport my plane to you from sweden i could always set the dragons waypoint to your house and attach a snickers... ;)

PS. I saw a article from a university in the us who made a sucessfull long distance flight using standard rc equippment carrying the plane 4 360km. @ 180km/h...

thats 2 hrs of automated flight with a respectable speed.... i want to beat this using my homebrew plane.. ;) Maybe the Dragon is not the best autopilot for this but it should be possible in good weather...

Will the schematics for the latest edition of the dragon board become public any time soon??

Share this post


Link to post
Share on other sites

I think you can take the kalman filter away, maybe you dont need it because HUD dont need to be extremely precise. Just keep the gyro drift compensation with accelerometers.

Alex

Share this post


Link to post
Share on other sites
Just keep the gyro drift compensation with accelerometers.

Hmm, that's what the filter is there for ;)

Share this post


Link to post
Share on other sites
Hmm, that's what the filter is there for ;)

Nope, kalman filter is a prediction like filter. You can just calculate de difference between the raw(gyro) angle and the gravity(accelerometer) angle. That difference is the error signal that you can use to correct the angle calculation. With a gain parameter decide how much of the error signal you use to correct the gyro angle. Then sum it to the raw(gyro) angle. The final result will be dominated on short times by the gyro, but on long times by the accelerometer.

Share this post


Link to post
Share on other sites

Well, we could use a simpler scheme to correct for the drift but since we also use the IMU for stabilization of the plane, you will want the best estimator, and since the Kalman is a well suited optimal estimator - it is ideal for this sort of thing.

Daniel

Share this post


Link to post
Share on other sites
You can just calculate de difference between the raw(gyro) angle and the gravity(accelerometer) angle.

The problem, already lenghtily discussed on other threads here, is that the plane is also subject to dynamic acceleration, not only to gravity. The accelerometers can't be used as an "reference", as at some points they can be more "wrong" in terms of attitude indication than the gyros.

A more sophisticated blending has to be used, where both types of sensors "correct" each other.

Share this post


Link to post
Share on other sites
The problem, already lenghtily discussed on other threads here, is that the plane is also subject to dynamic acceleration, not only to gravity. The accelerometers can't be used as an "reference", as at some points they can be more "wrong" in terms of attitude indication than the gyros.

A more sophisticated blending has to be used, where both types of sensors "correct" each other.

If you read carefully that is what i m saying, to bad my english is not good. Anyways i m working on my own AHI and i will show the actual project soon. Just wanted to be usefull proposing a way to avoid using kalman filters, googling you will see other approaches.

Edited by Alex Villa

Share this post


Link to post
Share on other sites

In my case, I already have the Kalman filter working successfully, and working quite well too so no need for me to use less effective methods I think.

Daniel

Share this post


Link to post
Share on other sites

Alex, I second your opinion - no real need for Kalman filter for this project, much simpler filter will work.

To correctly implement Kalman filter one needs to know system dynamics equations and proper values for system noise and observation noise. None of them are well defined except may be the observation noise values. People often end up using truncated version of the Kalman filter where ad-hoc values were plugged in for Q/R matrices and with some very simplified assumptions of the dynamics. It still works but no longer can be called the "optimal" and the result may be no better than with much simpler filter. Daniel, I don't know what version of Kalman filter you are using, but if it works - great!

Edited by cyber-flyer

Share this post


Link to post
Share on other sites
In my case, I already have the Kalman filter working successfully, and working quite well too so no need for me to use less effective methods I think.

Daniel

Thats very nice then. Thought you had some problems with it, but if it is solved is much better, of course.

Edited by Alex Villa

Share this post


Link to post
Share on other sites

In fact the systems equations aren't that complex. What is needed is to characterize the noise of the system and the covariance values. This can actually be empirically determined. In saying this, I'm also making some assumptions regarding the cross-axis influence and ignoring some other influences as negligible or linear. This allows us to keep the equations complexity manageable.

As to whether this will outperform a simpler system, well that depends a lot on what that other system is. In fact by the time you tune up a PID loop to get it right, you might as well just use a Kalman EKF or better yet an SRUKF. The problem is that many people find the math a bit daunting even though the actual principle of the system is not that difficult to understand. But if math isn't a problem, the filter shouldn't be all that hard to implement. For lower powered controllers, there are a few tricks you can use to reduce the computing workload, although with the SRUKF - there's going to be quite a bit of floating point calculations so a fast MCU would be needed.

The real advantage of using an alternative system, I think, is that it is more readily understood whereas the Kalman filter is initially very non-intuitive. I can't really see how those systems will in fact perform better than Kalman filter, especially when you are thinking of mass producing the units which may not allow for very precise characterization of the sensors.

In the end, the proof is in the pudding. One reason I decided to pursue the EKF route (will try SRUKF later) is because so much has been said about it, and yet so little done. Everyone seems to know what it is but very few have actually put their apparent ideas to practice. The same can actually be said about alternative systems. It seems that almost every other person has a great idea of how to make a working system but I've not really seen any working models to go with those ideas. As such, one of my goals is to put an end to all the speculation and produce an actually working system. This now works although I would like to see faster convergence. Once I get the smaller prototype boards made, I'll be able to know how well it actually works on a plane.

I would like to encourage those out there with ideas to actually put them to the hardware. That's what we really need right now - real world test results.

Daniel

Share this post


Link to post
Share on other sites
In fact by the time you tune up a PID loop to get it right, you might as well just use a Kalman EKF or better yet an SRUKF

You need to tune PID loop in any case as Kalman filter will only "read" the system but not control it.

Everyone seems to know what it is but very few have actually put their apparent ideas to practice

May be there is a reason for that, besides the fact that people are lazy ;) I mean complexity of the approach may prevent detection of otherwise apparent problems. But if you have one working - that's very cool!

That's what we really need right now - real world test results
That's would be good, I don't know anybody who's done comparison of different methods, especialy in actual flight. How would you propose to compare different approaches? Calculating attitude errors during flight will require second, benchmark IMU on board.

Share this post


Link to post
Share on other sites

One way would simply be to strap the unit to a test rig with known inclinations and test it that way. Another approach would simply be to see how well it works for the desired purpose - be it stabilization or artificial horizon. If it works, it works.

Daniel

Share this post


Link to post
Share on other sites

Hi my name is Dan sorry for my English , I will like to arrange my navosd I seek the shematic diagram + pin out for Dragonosd with the PIC 30f4012 .

please I would need your assistance

thank you

Dan

Share this post


Link to post
Share on other sites

Daniel, the IMU discussion deserves its own thread. Let's start it.

One way would simply be to strap the unit to a test rig with known inclinations and test it that way

That will be just a test of accelerometers. The actual flight will test if blending of gyros and accelerometers is done properly. If one doesn't have a calibrated IMU, the next best thing will be to put a model into a steep banking turn lasting at least 10 seconds, than quickly recover to a horizontal position and compare IMU output with visible horizon. This condition is impossible to reproduce on the ground, unless one have an access to a big centrifuge.

Edited by cyber-flyer

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...