Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

I did look at the board, and it does look nice - the header you added. I don't have a BOB-4H so I really didn't do too much with it and as you said, things get bigger and won't fit into my plane. Thanks for the work though.

As to the regulator - there's your problem - the LM2940 was only meant to power the board and not the TX/Camera. Those are huge power drainers and will cause the linear regulator to get hot. In my case, I actually use 3 regulators to power everything.

With the DE regulator - I can't remember if it's rated at 1A or less but you'll want to make sure that the DE module can handle it. If it does, do a test to see if the voltage and current readings are stable.

Daniel

Share this post


Link to post
Share on other sites

The DE reg is rated at 1amp. It runs warm, but not hot. I'll do some tests once I get the current sensor. The cam draws 160mah and the transmitter draws 240mah.

Edited by docphi

Share this post


Link to post
Share on other sites
Its not computer gibberish.. its the computer log of it's card game with the other processors in the machine :P

HA HA HA HA :lol::lol::lol: too funny Mark!!!!!!

Share this post


Link to post
Share on other sites

That would explain:-

1. Why the task manager shows the CPU to be idling 90% of the time (playing games)

2. Why the CPU is sometimes so slow to respond

I think you need to send the computer to Gamblers' Anonymous.

Daniel

Share this post


Link to post
Share on other sites

Just a quick heads-up: I suspect that one of the code changes I made recently has affected the normal operation of the autopilot. I'm currently looking into this so if you're testing it and it does not seem to be working, it's probably something I need to fix.

Daniel

Share this post


Link to post
Share on other sites

BTW Daniel...

Like the new name... DRAGON OSD :lol: Hmmm your OSD... is like a crouching tiger, HIDDEN DRAGON!!! :lol::lol: Ok I'll stop being so corny now :P

Share this post


Link to post
Share on other sites

Arrrghhhhhh! I can't stand it .... if I had my way - it'd be NAVOSD or some such boring name. I just knew I'd get all the Jackie Chan, Bruce Lee and other cliches if I had called it the DragonOSD but there it is! :) Heheh .... oh well! Mark, you seeing this??? This is all your fault!

Kung Fu Phooey!

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Yeah I'm sure Mark is watching and giggling too! :D Keep up the fantastic work Daniel.... ok I'm off to finish my DVD flick the Three Musketeers! It's probably like any action flick.. They Came, They Saw and then they Kicked Some B*TT. :D

Edited by JMS

Share this post


Link to post
Share on other sites

That's the kind of movie I like to watch - no emotional garbage, just senseless violence and butt-kicking. Don't need no more stress than I already have, heheh.

Okay, auto-pilot issue solved but...

As it turned out, the code I had introduced to smoothen the "jerkiness" of the controls (actually time-quantization), was somehow preventing the autopilot corrections. It shouldn't but I can't quite figure out why it is doing that. For that reason, I am reversing that change for the moment. It will still fly just as well so nothing is lost there.

NAVOSD (DragonOSD) software version 3.9

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

I just went for another flight to test the autopilot and it's confirmed to be working again. During flight testing, I noticed the problem again with the EB-85A earlier revisions where sudden changes in altitude could render the GPS data useless (lagging) for a minute or so. Not cool at all. I think for my own use, I will set ROCSTEPGAIN to maybe 1 or something really small since I'm not really all that keen to have the plane descend - I am just interested in it coming back to me. I have been using 9 for my ROTSTEPGAIN and I think maybe I will reduce this to 7. Other than that the unit is working very well, so well that today I just turned the transmitter off and let the autopilot fly the plane back while I was talking to a friend. It did it's job and flew right over our heads at 160m or so.

Daniel

Share this post


Link to post
Share on other sites

On-board voltage is working. I was out in front of my house testing the autopilot by walking the plane around. It's eerie seeing the servos moving by themselves. Can't wait to try it in the air. I'm waiting on the current sensor to complete the proto unit.

post-6-1188232486_thumb.jpg

Share this post


Link to post
Share on other sites

Current sensor came today. Lousy photos, but, does it look right Daniel? I don't see any data on the OSD (with and without the motor on).

post-6-1188241965_thumb.jpg

Edited by docphi

Share this post


Link to post
Share on other sites

docphi,

You might have the same issue I had: you need to have your battery voltage connected to AN1 (not just AN0). Since I'm using a singe battery, I originally connected the battery voltage to AN0 only, but AN1 needs it too. The current sensor itself is connected to AN3. I hope this helps.

Share this post


Link to post
Share on other sites

just like in the schematic, the battery is connected to AN0, through a 22k. Then, the same battery also connects to AN1 through a 22k. 11k resistors to gnd on both inputs.

This is, of course only necessary if you're using one battery. If you've got separate electronics / motor baterries, you should connect the motor battery to AN1, and the other battery to AN0 (both still in series with the 22k resistors).

Edited by rimb05

Share this post


Link to post
Share on other sites

OK, you'll know that the the AN0 and AN1 pins are connected properly if you get a text pop-up on the left of the screen, that has the voltage and amps listed. Even if the current sensor is not connected, these text labels will pop up as soon as there's a voltage on AN1 (it will show 0 amps if the current sensor is not connected to AN3, though).

rimb05

Edited by rimb05

Share this post


Link to post
Share on other sites

Got the pop-up. However, the voltage is off. It's showing 14.9v and the pack is a 3S LiPo (measured at 11.7v). Board voltage is also off. I see two 0.1uf caps on the schematic, however, I seem to only trace one on the board in that bottom left. What am I missing?

Share this post


Link to post
Share on other sites

Check that your 22k and 11k resistors are correct values. Measure with an ohmmeter. It is possible that you've got the wrong values in place, or in fact, it looks like your 11k resistors are missing or not grounded/connected. I'm missing one cap for the board but it should work fine without it so you can ignore it for the moment. I'll probably find a way to include it in my next board revision.

BTW, nice photos doc - just two comments:-

1. You'll want to keep that GPS as far away from the BOB-4 as possible so maybe a longer connector.

2. I hope those JSTs are sufficient for the current that your motor draws. I had my deans soldered directly to the sensor tabs.

Lastly, some notes on autopilot setting:-

0. You need to have your plane trimmed out perfectly for best performance. Ie. when you take your hands off the sticks, the plane should not start turning one way or another. This is best done in calm conditions. If you have some bias, it may be hard to see what the impact of the change in the settings will be.

1. If your ROTSTEPGAIN is too high, the plane is gonna bank really hard - so be ready to straighten it out manually if you see that happen.

2. You may want to set ROCSTEPGAIN to 0 while setting ROTSTEPGAIN up. This way you can deal with one thing at a time.

3. Keep an eye on the GPS readings as the EB-85A has a habit of going bonkers, which will cause the autopilot to do bad things. This is especially so when changing altitudes fast. If this should happen, level out for a while and let the GPS catch up. Mark has new GPS modules which has the new fixed firmware so you may want to try that. I'll be getting one soon so I'll know how well that works.

4. Start low with ROTSTEPGAIN - around 4, and work your way up or down as necessary. If the gain is too low, it will look like the plane is not doing anything (provided it's trimmed out properly) and the transition from doing nothing to doing something is pretty quick. So, 6 may seem like nothing is happening but 8 or 9 could be too much.

5. If you're using this on the rudder, make sure the plane is turning the correct way (direction of arrows at the end of the compass recticle). If the plane is going the wrong way, then just reverse the servo setting in the menu for RDRSERVODIR.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Some good news and bad news. Bad news first - one of my BOB-4S's has failed. I've no idea when or why it failed as I've not used it for a while, being that I was testing the one in my plane. This is going to slow down my coding until I can get another one from Decade Engineering. That's the bad news.

The good news is that I have just about completed the code which would add 3-D flight path logging. I've tested part of this before I noticed the BOB-4 failed (since this was on a serial link). Basically what you do is you remove the GPS connector from the board and plug in a serial cable (suitably converted to TTL), and you can download a KML file which you can open with Google Earth. You will then be able to see a 3-D plot of your last flight on the map itself.

This was prompted by my latest flight - 2.2km ground distance and 980m altitude (this was with the 3dB whips on both ends, and the LNA on the receive side. JR radio, no signal loss at all and video was doing ok, some noise but no problems). I wanted to review the flight hence I went and worked on that code. It should be working but I will be slow now in testing it since I'll be waiting for the new BOB-4 (if I can get one from Decade). Dang.

Edit: Okay, I've got the thing sort of working. I can now look at the 3-D plot in Google Earth but I probably shouldn't release the hex file until I get to test it a bit more. That will have to wait a while till I get the BOB-4 up and running again.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Daniel,

Sorry to hear about the BOB-4. I'm glad it didn't happen to you while flying!

I've been trying to iron out some glitching in my plane, and have narrowed down the problem. I'm using a copilot in this plane, and while I haven't planned on using it while testing the OSD, it's there just in case something bad happens. The glitching happens when I put the copilot in series with the OSD (Receiver->OSD->Copilot->Servo). I checked and re-checked that the voltage levels were good at every point in this chain (I have a Futaba receiver, but I have a level shifter that outputs rail-to-rail 5v, so I've got ~5v TTL at every point). I was stumped as to why the elevator servo jumped around in a strange, rhythmic pattern.

Then, I finally figured it out. It has to do with the way the OSD outputs PWM. Apparently, it's not synced to the OSD inputs. Let me explain: The copilot, and many other devices don't like it when they receive all their inputs at the same time. They prefer to have a small delay between channels (most likely because the inputs trigger an interrupt, and if two channels come in at the same time, it can't figure out which one trigerred the interrupt). In my setup, the copilot gets it's elevator input from the OSD, but it gets it's aileron input directly from the receiver. The problem is, the OSD's elevator output is not synced to the receiver's outputs. I looked at this on a scope, and the two are completely asynchronous. It's as if the OSD's outputs are synced to an internal timer instead of the receiver inputs. This causes glitching in the copilot, because every now and then, the two inputs line up, and the copilot can't handle that.

My question is: how difficult would it be to have the OSD outputs synced to the OSD inputs? I assume this would be as easy as moving the code in your timer interrupt to the input interrupt function. I realize this is pretty low on the priority scale. Maybe I'll do this myself once you release the source code.

Share this post


Link to post
Share on other sites

hi rimb05, I know what you're saying. The only problem is that the way the hardware of the microcontroller s done, the PWM generation is sort of automatic. I think something may still be done about this but I'll have to look into it. How about putting the co-pilot BEFORE the OSD? Should work right?

Meanwhile, I've done some flight tests with the logging in place and these are some of the results - picture tells a thousand words I guess:-

GEtrack1a.jpg

GEtrack1b.jpg

GEtrack1c.jpg

Here's a slightly different type of view. With this view you can see that I had to fight some strong headwind on the way up and had some good tailwind once I turned. You tell that from the spacing of the intervals:-

GEtrack1d.jpg

*Note: This is at 15 second intervals, which will give a maximum recording time of around 23-minutes, which is just right for me. If your flights are shorter, you can use lower intervals and gain slightly higher resolution. For my purposes though, this is just fine. Besides, I don't have any EEPROM left to spare for any better recording. You can set the intervals from the configuration menu. Or you can turn it off by setting a LOGPERIOD of 0.

At the greatest distance, it's about 2.4km ground distance, and AGL (above ground level at launch point) altitude is about 650m I believe. Video held out good at that distance as did my radio link. There was a minor lockout at 1.8km out but I think that may be spurious as it didn't happen again for the rest of the flight. When it did happen, autopilot kicked in for a moment. This again is with the regular whips on both ends, with LNA on the receive side. On the last stretch, I hit autopilot and you can see a slightly curved line where the plane flew itself pretty much straight back to the field. I think I can tweak it a bit more so that it flies more directly to the point but this is good enough for me, besides I don't really want the plane to come directly over me. When the plane almost reached the field, I took over and flew a few circles before landing. This is also reflected on the track. I need to make some changes to the KML script so that it will indicate the starting point and the ending point but this would be the PC side application.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Wow! Those images are amazing. I can't wait to try it!

You're right, I could put the Copilot before the OSD, and that works fine, it's just one more layer of safety with the copilot after the OSD (in case the OSD fails).

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