Jump to content
Daniel Wee

My little NAV/OSD project - under construction

Recommended Posts

WOW Daniel!!!!

I'm impressed at how you laid out the graph both linear and 3 dimensional over the flight images! Very Cool!!!

Share this post


Link to post
Share on other sites

Thanks - the work is done partly by the controller itself in generating the coordinates. There is a PC side software which downloads this and automatically creates the files for you (once I get done with it). Pretty much plug and play at this point.

Daniel

Share this post


Link to post
Share on other sites

Intelligent Flight is proud to announce that Daniel has joined "the team" and has been working with us for almost a month now.

Not much on his OSD will be changing, we will be calling it DragonOSD because we really liked the name as suggested previously in this thread. "Dragon" to me signifies something of great power and grace yet has the ability of flight and sometimes a little magic - this is what we feel his OSD is to the FPV community.

Some of the things we want to do with the OSD:

* Make the source code availiable.

* Setting up a website for colloboration and SVN/version control, eventually allow users to maintain their own source tree under SVN.

* Produce high quality boards so people don't need to etch their own. We will not be making the board designs availiable for download - they will be all SMT and have very fine traces, its not something you could etch at home.

* Leave everything under Daniels capable control as far as the software and hardware side of things go.

What we are bringing to the OSD:

* Our experience with electronics and design.

* A huge amount of RF testing equipment through Thomas to totally destroy any possible interference sources onboard.

* Some funding to get new features happening.

Daniel also has a number of other projects which he would like to develop with us, and we have some ideas which we would like him to look at. Mutually, we feel that our partnership will yield exciting and innovative results - and we can't wait to start bring out the Dragon and other products for you guys to experience and enjoy!

Share this post


Link to post
Share on other sites

That's great news! Can't wait! My etching skills are worthless. :D

How about a plug-in board for the current sensor? Just piggy-back it to the OSD.

Btw - My current sensor is working. Test flight in the next couple of days. :)

Edited by docphi

Share this post


Link to post
Share on other sites

Well I finished my movie of the three Musketeers, the stars were Mark Harris, Thomas S and Daniel Wee :lol: Good Show, good team! So does JMS get to chuck some more new names for new future products? :lol:

BTW, I might as well put my nicely etched DRAGON OSD boards aside since you guys are now offering SMT boards. :lol: You guys are certainly coming up with some smart ideas! I've got a good feeling about this dream team and you guys are not making ripples in the FPV world, you are the ripple! Keep up the great work guys!

Share this post


Link to post
Share on other sites

Just some updates - the software is, I think, stable now at version 4.0. Although I can make some improvements based on some recent discoveries, those changes are unlikely to make any difference so I'll leave them out and opt for simplicity for the moment. At this point, I'm quite happy with the software and unless I get terribly inspired, it's unlikely for me to add anymore features before the source code is released.

Meanwhile, I have redesigned the circuit to run on 3.3V and managed to get rid of about 10 components or so. At the same time, I've switched to a dsPIC30F4011 in the 44TQFP packaging. I could make the board smaller but right now the problem is the size of the BOB-4S so I will try to keep the board matched to the BOB-4S's size. Additionally, the new MCU has an extra UART port which gives me the option of passing GPS data through, say to a modem which can be used to control an antenna tracker in the future. The board will be using SMT parts, mostly 0603 sized components and once I test it and find it to be working, that is likely the board that will go on sale. The source code should be out shortly but I want to make sure everything is working smoothly in order to keep things from getting consfused and messy. This will be a 2-layer board, no jumpers, and includes some of the components from the current sensor board. This allows us to use the current sensor module that IF sells with very little modification. There will also be one less connection to the BOB-4.

So there you have it, the update on the board.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Cool! :D

Daniel, how will the BOB-4 attach to the OSD board? Will we need to solder the connections? Or do you have something else in mind?

Share this post


Link to post
Share on other sites

Hi docphi,

Unfortunately it will still be soldered unless I can find some really neat way to do it. The trouble is the sockets take up so much space, and the BOB-4H is actually bigger although it offers better option for interfacing through the socket.

Daniel

Share this post


Link to post
Share on other sites

Great OSD Daniel. Im glad you took the right approach and used very capable hardware so that your board could do a lot of different things, and also handle the updates, improvements, etc. that always come about over time. I bought a BOB 4 about 9 months ago with the idea of what you are doing, but never had time for the project. Im glad to see I might be able to use my BOB 4 after all :)

So many guys have put a lot of time into designing and programming OSD's just to make them almost useless by trying to save 20 bucks in hardware. Their product turns out very limited in capability, and never has the potential to be any better.

Im glad you hooked up with Intelligent Flight. I cannot solder SMT, nor do I care to spend all day trying to etch a board that I can buy for ??? dollars. I dont care if its a bit expensive, I will gladly pay a fair price for a quality product, I will buy several of them when they come out.

JettPilot

Share this post


Link to post
Share on other sites

Jet,

The problem with using the bob4 is that it's almost impossible to commercialise a design so that it will have a competitive price. If we were to sell the Dragon all inclusive (ie: closed source) You'd be looking $400-500, this isn't very practical hence the open source route.

We should be sending boards to the fabrication house this week along with some new toys from Thomas so we should have some rough pricing late this week, early next week. These are prototype boards, so if they work we will sell some as strictly prototype/not commercial quality/could be buggy :)

Share this post


Link to post
Share on other sites
Hi docphi,

Unfortunately it will still be soldered unless I can find some really neat way to do it. The trouble is the sockets take up so much space, and the BOB-4H is actually bigger although it offers better option for interfacing through the socket.

Daniel

How about this idea? The BOB-4S has holes in the contacts. I've soldered male headers through those holes and mounted it to the OSD with a corresponding female component.

Share this post


Link to post
Share on other sites

Hi docphi,

That's a nice idea but for two things:-

1. Those holes are pretty small and you'll end up soldering to it anyway.

2. The connections are all along the board and not in one tight group. That will impact board layout.

Hopefully Decade will come up with something smaller, cheaper, and easier to interface to.

On another note: Today I flew out to 2.6km ground distance - altitude between 500-600m mostly. There were no lockouts, nor video dropouts at all, and this is using my JR9X2v2 (9303) on 72MHz, with standard whips on the video TX and RX. I keep pushing this and it seems to be keeping up. As such the 8dB patch has been sitting in the car unused, until I get a diversity to use it with. The entire flight took about 20 minutes, and 1800mAh on my 3S Li-Po. Battery was barely warm upon landing.

Now that I'm flying longer and longer distances, navigation is becoming more and more important. Most of the time, I navigate by compass and visual recognition of landmarks. Even so, I've found that it is actually quite hard to exactly determine where you are over when flying this way. I suppose having a pan-tilt camera setup may make things a bit easier but the main problem is the perception of distance and the difficulty of recognizing landmarks, unless they're very obvious. Buildings that I thought I knew very well, and large, aren't that easy to spot from way up. In fact, even in Google Earth, it's not that easy to recognize a building from the top profile. Coming home is never a problem, of course, since I already have the arrows and markers, and in the worst case, I just hit auto-pilot and let the plane fly itself.

This has prompted me to think about implementing some more navigational aids. I'm not sure what form this will take at the moment - be it a separate page with navigational references or the ability to track selected waypoints. This is something I'll be thinking about as we go along.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

Navigation features would be great. I find navigation the absaloute hardest part of FPV without question. Half the fun of flying FPV is gonig to new places you have never flown before. If you think its hard now, go somewhere far away, set up, and then go flying. You can become lost very quickly :wacko:

I dont mind having to put some things together. Having soldering skills is pretty much a requirement for FPV flying. If people cant solder, chances are they will never get an FPV plane and ground setup flying. Maybe some of the cheap ones will work out of the box, but those are not the people that would be interested in a high end OSD anyways. If you guys sell a board, and I buy my own BOB 4 and have to put the system together, that is fine. I just draw the line at etching boards and soldering SMT components that I cant even eee B)

I have posted these picture in several threads, but I will post it here as it is very important making an OSD that is easy to fly with, and gives you the best information that humans can recoginze quickly. This layout and presentation of flight information is used in every aircraft from small experimentals to 747's. It has been well thought out and researched for decades, by NASA, Boeing, and many other aerospace manfacturers as the best way for humans to be presented with flight information. I would make some pages of your OSD conform to this standard as closely as possible. I am not suggesting a horizon, the live video gives an excellent horizon, I am suggesting this for GPS speed (instead of airspeed), GPS track (instead of magenetic heading), and some navigation to waypoint indication at the bottom or top ( opposite side of screen from heading ).

post-6-1188838226_thumb.jpg

Share this post


Link to post
Share on other sites

Hi JetPilot,

My current display is already using GPS speed (ground speed) and GPS heading so you can actually navigate with those (which is what I am doing).

As for the waypoint indication - that's what I am thinking about. Three issues come up here:-

1. How does the user set his own waypoints? PC upload?

2. How will the waypoint be displayed?

3. How does the user select a waypoint or is it automatically selected based on location?

Those are some of the questions I am thinking about in trying visualize the implementation.

Daniel

Share this post


Link to post
Share on other sites

Daniel,

Will the newer processor give us more I/O pins? If so, I think a second switch on the transmitter to scroll between waypoints would work great. For example:

AUTOPILOT OFF

HOME

WAYPOINT1

WAYPOINT2

...

SET WAYPOINT

Then, a constant indication of the waypoint setting somewhere on the screen, so the pilot knows what mode the autopilot is in. "set waypoint" would always store the current location into, say waypoint 16.

For uploading waypoints from the PC, a, SD card interface would be nice, but that takes up 4 I/O pins... I think a simple serial port interface would work just fine. Open Hyperterminal, and upload to OSD a small text file with 16 waypoints, one per line, etc.

Share this post


Link to post
Share on other sites

Another feature that would be cool would be the ability to fly a route and have the OSD remember it. You could then recall it and the plane would fly the pattern.

Share this post


Link to post
Share on other sites

Good point. That would be useful as well. "Learn Route" could be an option on the menu. I'm envisioning using a momentary switch on the transmitter to toggle between the menu options.

Share this post


Link to post
Share on other sites

Well there are a few constraints here:-

1. Memory, I am currently using all the EEPROM for the flight path logging. I could spare some for waypoints but that will shorten the flight log capacity.

2. I'm not terribly keen on the autopilot flying to waypoints honestly, because it was designed mainly as a contingency - a fly home in case of emergency. While this works, there are some inherent difficulties with non-stable platforms and to be honest, I'm not ready to trust this as a UAV type of thing. I know there are people who are doing this but having looked at the performance and issues, I have my concerns.

3. I would be more keen on making this a guidance display. Ie. I still fly the plane, but have indicators - like VOR - that will tell me where things are and where I am in relation to those points. For example, I can switch to a map-like screen which shows me in the centre, and graphically indicate the relative position of various named waypoints. That way, I can with one look get an idea of my position. Maybe I can even show my current tracks (ie. where I have flown).

4. I could have a small display of a selected waypoint on the screen with relative bearing and distance but I'm also concerned that the screen is starting to clutter up.

5. Although the new chip has more pins, the particular type of pin I need is still in short supply. There are however other means of setting the waypoint without needing another channel - which isn't such a good idea really - more wires, more likelihood of interference, more weight. We can do it with what we have currently.

6. Lastly, I am also trying to keep the number of settings and switches down as these complicate the tasks for the pilot during flight - and increases the chance of error. In flight, things should be as intuitive as possible and impose the minimum processing demand on the pilot.

Daniel

Share this post


Link to post
Share on other sites
5. Although the new chip has more pins, the particular type of pin I need is still in short supply. There are however other means of setting the waypoint without needing another channel - which isn't such a good idea really - more wires, more likelihood of interference, more weight. We can do it with what we have currently.

6. Lastly, I am also trying to keep the number of settings and switches down as these complicate the tasks for the pilot during flight - and increases the chance of error. In flight, things should be as intuitive as possible and impose the minimum processing demand on the pilot.

Daniel

IMHO it is more demanding to have one switch or slider that has multiple functions than multiple switches that each have there dedicated function.

As I mentioned before, for my project I would like to multiplex multiple switches on one channel. Perhaps we could make something that could be used on both projects? I will for sure make a POC for this, but it can take weeks.

Frederic

Share this post


Link to post
Share on other sites

Sounds good to me Daniel, I'm just thinking out loud ;)

Your idea of having a pop-up map with waypoints as markers is great. This makes a lot of sense if you get lost.

You've got to admit, it's very tempting to make this into an UAV controller, since it has almost everything you need. I suppose it's best to keep things simple, less screen clutter, etc.

Share this post


Link to post
Share on other sites

Hi Frederic,

Actually I already have that in my OSD. I have a slider that is assigned multiple functions. Currently I have 4 functions but I will add one or two more for the navigational feature.

Daniel

Share this post


Link to post
Share on other sites

Woo hoo! One more step closer to releasing the source code. Besides the BOB-4 setback (board RMA'ed now), the other thing holding back the source code release was the writing of the Windows app that will download and output the KML file for Google Earth. That just got done, not tested thoroughly yet mind you, but it looks like it works so the next time I test this thing, we should be good to go.

Between now and the release of version 4.0 the following needs to be done:-

1. Solving one quirk on the log date.

2. Add flight start time to the log.

3. Possibly add the waypoint map (although I'm kinda reluctant to give up log time).

4. Possibly add a waypoint uploading function to my downloader.

5. More testing of the code.

We're pretty close now. Hopefully 4 is the magic number.

Also, the SMT board layout is done. I just need to double check it (rather hard due to double sided nature) and send it out for prototyping. Also need to procure a bunch of SMT parts to test it. The SMT board is now exactly the BOB-4S size whereas before the OSD was a bit bigger. I originally designed it a bit bigger because I wanted to solder screening to the edge of the board to cover the BOB-4. Of course, with the new board, I've to test the hardware all over again but the code should be pretty stable. I'll need to make some small changes because the old board only reads up to 15V for the voltage sensors. The new board should read up to 24V. I'm also thinking about what other hardware features to include. Suprisingly, there isn't that much of a space saving with SMT because most of the space is being taken up by the CR2032 cell, the regulator and the connectors.

Daniel

Edited by Daniel Wee

Share this post


Link to post
Share on other sites

The flight log is cool, but I could live with less log space. Maybe setting the sampling rate of the log much further apart would allow you to do both the waypoint map, and the flight log. I never need to know exactly where my plane was at all times, a general idea of how far I got, and general track, and general altitude even if the recorded points are spaced far apart tells me all I need to know.

Waypoint mapping would be a really awesome feature, although the emergency return home is by far the most important. I simple arrow like Frederic used along his heading " tape " works very well to get really good information on the home position, along with a distance to home. I have to give Frederic an A for that easy to use navigation to home display.

The multiple waypoints are something I would not use much, and the danger is confusing one of the other waypoints with " HOME " and navigating far away by mistake. I have mixed feelings on this. A cool feature that could go wrong. Most importantly the airplane would have to go " Home " in case of a loss of video, or a loss of Radio Control. What if the plane went to another waypoint, or you were unable to see the video and accidently commanded something other than the home waypoint. Rmemeber, the auto home feature is very useful for equipment fialures, loss of signal etc. , it is most important that the airplane come home AUTOMATICALLY in case of loss of Radio Control or loss of video.

JettPilot

Share this post


Link to post
Share on other sites

Hi JetPilot,

Actually I had something similar, if not better, than FredericG's home indicator - inspired by his. If you look at the videos, you will see that on either side of the scrolling recticle (which covers the forward 180 degrees - FredericG's covers 360 degrees) there is an arrow which indicates which way home is. The arrow will change if home moves to the rearward 180 degrees. Furthermore, when home is in the forward 180 degrees, you can see a "H" indicator below the recticle to indicate the location of home. When home is dead ahead, the heading indicator will be highlighted as well. It works very well for me in actual flight.

I totally agree with you about confusing the waypoints. It is the reason why I've not gone ahead to implement it. In fact I already have the code to support multiple waypoints built-in but I'm not doing that for reasons mentioned. The current log allows me to change the period to a greater one for longer flight recording, yes. I just kinda feel comfortable with the 15-seconds now. Basically, each waypoint will take up another 14-bytes - inclusive of user customizable name. My current internal structure actually maintains a 5-character name for each waypoint so on the map this should show up with a name you recognize, like "VLAKE" rather than "WPT12" or something. Each log point takes up 10-bytes. How many way points do you think would be needed? 5?

I'll look into this map thing a bit more. Hopefully it won't take up too much code space. It will also mean that I need to write the Windows side app to upload the waypoints.

Daniel

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