Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

why gps coordinates are in decimal mode? not better to write them as usually ?

103ยบ35"12' or no?

what means HDOP?

what you think about move up GPS ccordinates in order to keep clean the bottom of the image, that usually is more important to see than sky.

maybe something like that don't know...

noryesog9.jpg

Edited by wallaguest1

Share this post


Link to post
Share on other sites

Good suggestions wallaguest.

The reason I have the GPS coordinates in decimal is because that is the internal format I use for calculations, it's much easier that way. Secondly, it takes up less space and is easier to print. For me the GPS coordinates aren't that important, they only become important when you lose the plane and want to track it down. In any case, the GPS info disappears once you go above a certain altitude, thus keeping the screen clear.

I like your idea about putting the info at the top - I'll look into that soon to see how it looks. Keep those suggestions coming.

HDOP refers to the Horizontal Dilution of Precision. It's one of the several measures of the reliability of the data. The lower the number, the more reliable the position fix is. (Although in my setup 0.0 is an indication of invalidity, I'll do something about this later).

Daniel

Share this post


Link to post
Share on other sites

Just some updates:-

I've moved the GPS data to the top as per wallaguest's suggestion and it does look better, I think. Anyway, I have the option of moving it around if I need to - for the moment I'm keeping it at the top to see how the well it works.

Meanwhile, I am working on the autopilot - we're almost there. I also need to start fitting the thing into the plane for actual testing. This bit is important to test the autopilot performance since theoretical testing can only do so much. I will need real world data for this part so the whole setup should be in the air sometime in the next few days I imagine (that is if I don't get bogged down by real life work!). I'm also thinking through the data presentation during the autopilot phase (optional). What I would like, at this moment, would be to see the unit say something along the lines of "Climbing to cruise altitude." Maybe more brief, but giving me an idea of what the computer on board is thinking, even if its just for diagnostic reasons. It's kinda cool though, very sci-fi like :-)

I've not implemented position saving in EEPROM as yet but I might do that later. It's not a major priority for me at this point. When I do that, I will also have to think of some kind of bootloader. All these are lower priority goals at the moment. I still don't know how to go about sharing this project - or selling the control board. In fact, I don't even know if I'll end up doing that. Suggestions welcome here.

I've also not implemented the pressure sensor although that is pretty simple to do. I don't want to complicate matters for the moment. The other thing I have in mind is maybe to draw out an RSSI line from the receiver, perhaps through an opto-isolator, so I can monitor the radio control link. I suppose this is superflous once I get the autopilot working though.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

i saw a video of ThomasScherrer that got RSSI signal level in the OSD and is not usfull because it changes depending of the plane position, and im not sure but i think rssi levle should be adjusted depending on wich receiver are you using, not all got same level, in fact probably no one got the same one...

i also like to see Letters at the bottom of the screen like

"Fail Safe: Returning home" when failsafe switch on,

or anything you want, configured by usser,

that info of HDOP is so nice to know how many meters around gps coordinates could be you losted plane,

are you planing to add an alt hold fuction in order that plane don't lost altitude when UAV mode is enabled and so on? or just to work when fails safe is on,

Share this post


Link to post
Share on other sites

Yes, I intend to have status indication, including "Failsafe" somewhere - haven't quite decided on the best place as yet. This will also indicate what the auto-pilot is attempting to do.

I am already working on the altitude hold as part of the autopilot scheme. Once the autopilot is engaged, either through failsafe or user selection, the plane will attempt to do a few things - one of which is to climb or descend to cruise altitude - something like 300-500m altitude. At the same time, it will try to get the rate of turn and rate of climb down to a predefined range so that things are more manageable. And then it will proportionally adjust rudder to turn the plane back home (or a number of waypoints as user desires). I am trying to accomplish all these without the use of the FMA co-pilot stabilization. Hopefully it works well enough to get the plane home. Once it gets within a certain distance to home, it will go into a holding pattern while optionally descending slowly. Remember, my controller does not have throttle control but if it maintains the holding pattern and the throttle gives, it can still have a chance of landing nearby. The other possibility is if the engine is dead, the controller will see that it cannot maintain altitude without losing speed and it will try to glide back as quickly as possible.

I'm still working on all this.

Daniel

Share this post


Link to post
Share on other sites

First FLIGHT!!!!

I got the whole setup into the air this morning and all the basics are working correctly for the most part. Now I will be collecting data for the autopilot. Hopefully I can post some videos soon. By the way, the servo channel controlled display is working so I can turn stuff on and off if I want to. More later.

Daniel

Share this post


Link to post
Share on other sites

Neil Armstrong: "That's one small step for man, one giant leap for mankind."

:lol::lol::lol::lol:

Share this post


Link to post
Share on other sites

Okay, I know some of you have been waiting to see this - the video of the OSD unit in flight. I've turned on the GPS info (long, lat, sats, hdop) for diagnostic purposes but those are usually turned off automatically once you climb above a certain threshold. There's still some fine tuning to do but we're very nearly there with the OSD.

I've been working on the autopilot algorithm and I think it will be another few days before I get that part right. The hardware and basic support code is all working though.

So, here it is (54MB DiVx):-

OSD Test 9 (Flight)

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Just wanted to add a few comments about the autopilot progress. I had initially intended a rudder-home feature but today's testing revealed that using the rudder to turn the plane resulted in large loss of altitude, as compared to using the ailerons. Because of this, I will be changing the direction of the code to use the ailerons instead of the rudder. The trouble with this approach is that I will need two channels for ailerons in some cases, where they are driven in opposite directions. I think I can probably manage this since I have a spare PWM output which I can use for this purpose. In my present plane though, the rons are controlled by just one servo so that simplifies matters considerably for me.

I've just reworked some of the code based on recorded climb and turn rate data from today's flights. I will be confirming the changes tomorrow and if all goes well, I will be switching to use the PCB controller with the connections for the servo channels and we will be starting to test actual autopilot control from there on. At this point, I need to implement a watchdog on the controller since my major control channels are being relayed by it, and a software crash can be disastrous.

Daniel

Share this post


Link to post
Share on other sites

I'm using a combination of fonts really - font 0 for most of the large numbers and fonts 1 and 4 for the smaller ones. These are the fonts already on the BOB-4.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

maybe you would like to agroup items by categories,

or even remove the bottom compass and leave just the angle to twist to home,

that's the result of playing a little with image editor, im not sure if you like it,

gif size is 1,2 mb

arttx7.gif

Share this post


Link to post
Share on other sites

This layout doesn't quite work for me. Usually the top left and right corners are where the eyes go first and so the most important information would go there. I have on the top right the speed and altitude (plus a small climb/descent indicator). That would be the most critical data for me at this point. The top left - elapsed time and battery voltage would also be important, but I only look there occasionally. The top middle - also a very natural place to look, is actually kept clear for aesthetic reasons but occasionally, information may pop up there from time to time. The bottom centre is the most natural place for the compass because that is where I would be looking when navigating. If anything, I would want to ground the heading with the altitude. The present altitude position is not bad though - when I think "altitude" I look up naturally. The bottom right, is the distance from home (both ground and LOS - line of sight). When going beyond about 300m (can't remember threshold now) the ground distance disappears. So, for me this current layout is quite effectve - of course it varies from person to person but I suspect it should be quite natural for most people. I'm still thinking of a more natural layout - particularly giving attention to some of the research about how the eye travels across a page of information. There is also the possibility of using smaller fonts for less critical information - such as the HDOP. I did not do that, however, because that information is only temporal and disappears as soon as it is not needed. I find GPS location info to be virtually useless in flight so what I did was only to enable it once the plane gets below a certain (progressively calculated) altitude - such as in the event of a landing or a crash. Other than that it serves little purpose for me.

The one problem I have though, is that on my goggles, the corners are a bit blurry due to the interocular distance not matching those of my eyes I think. Still it is not too bad and manageable for the moment. Today I flew FPV for a bit and found the layout okay except that I did have to make an extra effort to look at the altitude, which is the most frequently used bit of information as far as my flying is concerned. This is especially so when landing, I am looking at the ground and don't want to have to look up for the altitude (although the accuracy of the GPS makes the value of the altitude reading at that point questionable). Having flown FPV a bit, I must say that I think the artificial horizon, while a nice feature, is not necessary at all except for instrument or night flying.

On another note - I found the TX/RX combination to be not as clean as my previous TX/RX. I am now testing the Lawmate modules. I got mine from FutureHobbies and they are very nice and compact. The only thing is that it appears that the radiation pattern of the standard 3dBi which is rather flat. I've no idea what the pattern for my previous antenna is but I get less blackouts. It also appears that the signal is a bit noisier that my previous set. I'll probably need to do a bit more testing to confirm all this.

Lastly, I've enabled the watchdog function so if the software should hang for some reason, it will automatically reset the CPU in about 5-seconds or so. I've tested this in the air and it works well. What I've also done is in the event of a midair reset such as this, the controller will NOT set a new "home" but will rather use the previously saved (in EEPROM) home position so that you can continue to fly and navigate as per normal. I'm still adding little safety features like this.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

When I use a watchdog I usually make it switch to a minimalist program containing only the vital functions after a watchdog-triggered reset.

In that case that would be only to relay the servo inputs to the outputs directly (an out1=in1, out2=in2 loop) and nothing else.

The reason is that if the controller was to hang it would certainly be due to a bug in the software, and simply resetting the processor won't prevent it from happening again 2 seconds later. If you end having your PIC resetting all the time it won't be of much help.

Share this post


Link to post
Share on other sites

That's true but then I was thinking - what if I am someone far out and lost?

At this moment though, I'm fairly confident in the code integrity - has not hanged even once throughout the development. My only concerns would be stuff like stack overflow or divide-by-zero exceptions. Those should not be too common place. But you're right, I think what I will do is that I will allow the user to switch manually to a minimalist feature set in case things go wrong.

Right now, incidentally, the passthrough code is interrupt driven so even if all the other stuff is locked up in a loop, it will still work as long as the interrupts are being triggered. That's an additional level of protection in this code against general errors.

Daniel

Share this post


Link to post
Share on other sites
That's true but then I was thinking - what if I am someone far out and lost?

Well, then remember te OSD is only to be used as an aid, and rely on the primary means - visual navigation!

I think what I will do is that I will allow the user to switch manually to a minimalist feature set in case things go wrong.

I'd make it the other way, allow re-enabling full function from the minimalist version that will run after a watchdog reset... If you have a reset, you try and reactivate full function once. If it hangs again, then leave it in the minimalist mode.

Share this post


Link to post
Share on other sites

I'll think about it. Right now the detection for a watchdog reset isn't working as I am expecting it to for some reason. In the meantime I have clocked a few more flights with FPV - I changed to a different channel and it seems a bit better but still the video is not as clean as my old cheap TX/RX pair although the definition is better. I'm still using the 3dBi whip on both ends. My older TX/RX had a slightly longer whip but I've not checked the inside of it to see exactly what the radiating element length is.

On the autopilot front - the basic computation seems to be working and the code is coming up with correct recommendations for which way to fly home. I will be translating this into servo action soon and we'll see how this works out.

Daniel

Share this post


Link to post
Share on other sites

Another minor breakthrough - I've been struggling with the seemingly poor performance of the new TX/RX set I got from FutureHobbies. These are the usual Lawmate modules. I had expected them to outperform my old made in China set and they do have better definition but the signal was always noisy. Just not good enough for me.

Well, last night I took apart the antenna from the China TX and found that it was quite sophisticated - centre-loaded dipole of sorts. Anyway, I went to get some SMA connectors (those things are expensive!) with the intention of putting that antenna onto the new modules. However, as it was hard to get cheap SMA connectors, I ended up buying a bunch of whip antennas with SMA connectors, thinking that I can just dremel the end off and use that.

Anyway, getting hope, I figured I might as well just test the various antennas before I cannibalize them for parts. Lo and behold! I discovered that the original whip I was using on the Lawmate receiver wasn't working at all!! I might as well not have the antenna on - it made no difference whatsoever. On the other hand, the good antennas were working well. So, for the moment, I'm happy again and will not chop those antennas up and continue to use them as it is.

So, let this be a warning - the antenna is just a simple part but it can be a failure point. So if you're experiencing poor signal performance - check the antenna.

Daniel

Share this post


Link to post
Share on other sites

Good news and some bad news.

The good news is that with the new antenna, reception is MUCH better. Man, I should have thought to check this earlier but I'm very happy with the resolution now. It's as good as it gets I suppose. Nice noise free images (except when directly overhead).

Now, the bad news - there appears to be some conditions under which the GPS data seems to lag quite a bit. I'm not quite sure why this is the case. I'm running a 115kbaud link to the GPS module, and I have only GGA and RMC turned on. I remember Thomas mentioning this problem sometime earlier but don't recall what the solution was. I don't know if this is inherent to the GPS module (internal buffer) or due to my own serial receive buffer. Unfortunately, this is one of those problems that really affect the quality of the navigational information. I'm wondering if this is a deliberate "feature" to prevent such modules from being used in fast moving platforms - say a projectile. I've heard that there were such limitations but I don't know if this might be it. Basically the whole data thing just becomes unreliable. It was fine yesterday though - I'll try it again tomorrow.

I'm going to comb through the code again to streamline it more and iron out any bugs I can find but if anyone knows why this lag happens, I'd be happy to hear it.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Okay - investigations into the so-called "lag" in the GPS behaviour has yielded some results. While reviewing yesterday's video recording with the diagnostic information on screen, I found that the GPS module was actually losing lock in mid-flight. The strange thing was that when this was happening - the module was seeing at least 8 satellites in view!

What I was observing was that the data was becoming increasingly inaccurate but the SV was still at 8 and HDOP was 1.0. The number of satellites visible was fluctuating considerably within the span of a few tens of seconds. Eventually the SV will start falling and the HDOP will increase, reflecting now the bad lock until SV is 1, and then suddenly it will re-lock with 5 to 7 satellites and the data becomes good again. I'm not sure why this is happening but this isn't due to my software. The problem seems to be either the GPS module firmware or someone the reception is being interfered with. Given that Thomas faced something similar makes me suspect the module more than interference.

I've been running this at 1-update per fix, so that's about 5Hz. I don't know if running it at a lower rate will resolve this problem. That might be worth a try.

Daniel

Share this post


Link to post
Share on other sites

We have noticed too that the eb85 will sometimes go nuts following "unusual" movements (fast changes in direction, vertical dives).

Share this post


Link to post
Share on other sites

Any idea what might be the cause of this odd behaviour? It's seems to be a let down on what is otherwise an excellent GPS module. Do you happen to know if any of the other modules exhibit this kind of behaviour?

Daniel

Share this post


Link to post
Share on other sites

More updates - unrelated to GPS erratic readings issue.

Turns out the compiler was generating some wrong configuration codes and that was causing me some headaches. I thought my crystal oscillator was going bonkers but now I got it working again so that's one down.

I've also implemented the pressure sensor on my testbed. Unfortunately, as it turned out, 10-bits ADC just isn't up to the task. For what we want, a 16-bit ADC is required. Even a 12-bit ADC won't do the job adequately. I have a 16-bit ADC here but don't have enough pins to interface at the moment so that's going to take a backseat. I was kinda hoping that with the barometric altimeter, I can at least ignore the spurious GPS altitude readings but it looks like this is not to be. I'll be thinking about this got a while though.

Tomorrow, more tests to see if the GPS issue is related to update rate or my code, or something else.

Daniel

Share this post


Link to post
Share on other sites

Okay, this morning's test was good - flew about half a km out and 200m up, everything seemed to be working perfectly. I'll keep monitoring this situation since I did make some code changes yesterday - just minor clean up.

Daniel

Share this post


Link to post
Share on other sites

YES the EB85 sometimes give a wrong postion 500-800m off

this can be triggered with : too fast climb/desent rates, loops or rools !

when it is in "wrong" mode it needs a stable constant height for a while

to restore,

even after landing and at total stop:

I have seen the distance to home count down from 800m to 20m in 2mins !

also when changing height and direction too fast the SPEED readout

can goto ZERO for several sec !

the EM406 GPS have newer failed on those mentioned cases,

but it lack on the fast position update.

and is several sec behind actual position, so when navigation fast

it is causing problems to navigate without over steering.

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...