My little NAV/OSD project - under construction
Posted 27 June 2007 - 08:45 AM
Software question: C. Ground distance will do it most of the time, but when one is planning a high altitude flight it could be cool to change to 3D distance, as the difference will be significant and that's what counts for the radio link performances.
Posted 27 June 2007 - 12:15 PM
On the other front, I managed to concoct some etchant out of some common chemicals - the concentration was very low though, and took ages to etch the board. However, it is done now so I have a new board - with the same dimensions as the prototype board pictured earlier. As I mentioned before, the limitation is not so much the routing but the parts themselves taking up space. The PCB is not as congested, spacing is better, and I have a ground plane on the component side to help cut down interference. The regulator now gets bolted down to the ground plane which will double as a heatsink. Tomorrow I will sand down the edges to the correct size which will be a bit smaller than the prototype and will match the BOB-4S better. There are no components below the board now (there were a few before) and very few jumpers (2). The interconnect between the two boards is much neater now as well, with less wires too. In re-boarding the controller, I made some minor changes, switching to the use of Shottky diodes all round for better performance. The only drawback is that this new board has no provision for in-situ programming. Instead, it has connectors for the rudder and elevator channels (both in and out) and for the control channel - a total of 5 PWM ports. I've added a lot more de-coupling and made other minor design improvements (hopefully).
Meanwhile, I have a lung full of fibre-glass dust!!! I hate cutting FG - should have gotten phenolic paper boards instead. I'll do that next time. I'm also thinking of whether to invest in another BOB-4S or to rip out the one from the prototype and use it instead? I wish it wasn't so darn expensive. I also need to test the servo pass-through and scope it to measure the latency. The EEPROM code is done and I have space to record down the GPS position and info for 20-minutes at about 20 second intervals. I'm not sure if such crude resolution will have any use but it can then be dumped out and converted into GoogleMaps format I suppose. I'm still debating the usefulness of this feature.
A thought: Actually this has been a very quick development - from scratch, to conceptualization, hardware design, tthrough 3 prototype boards so far, coding, testing to now - all in the space of about 2-weeks (not counting the 1-week that I was away and the days that I didn't do anything). Looking at the final board now, I think this thing may be marketable - the software needs some extra features but I've already added code to set internal preferences through either a PC/serial port, or a dedicated device/LCD and buttons. Once I get hold of that crystal for the BOB-4S, I should be able to test all the other fun stuff such as rudder-home etc.
Edited by Daniel Wee, 27 June 2007 - 12:25 PM.
Posted 27 June 2007 - 03:08 PM
maybe you can try to do what MX is doing on his board; add FMA Copilot by software in order to remove the weight of one part of the copilot hardware,
an alt holding fuction is available too or not yet? mmyabe if you read the wps2 theard of MX you can get some ideas, or the RCAP v3 from Eladiomf, at
Wps-2 from MX http://www.rcgroups....ad.php?t=682910
Posted 27 June 2007 - 04:44 PM
Definitely marketable. It looks great! Let me know if you need a Bob-4. I've got two that don't seem to be working. It would be a matter of re-routing some damaged traces/contacts. Can't promise if they would come back to life, but, you're welcome to them...
Looking at the final board now, I think this thing may be marketable.
Edited by docphi, 27 June 2007 - 06:03 PM.
Posted 28 June 2007 - 07:01 AM
A few months ago I started a project similar to yours. I also considered the BOB4 but I did not want to make HW and opted for the BlackBoxCamera platform. Development stalled the last months, for various reasons but I plan to pick it up. (http://www.rcgroups....ber.php?u=14137)
I should be able to test all the other fun stuff such as rudder-home etc.
I have a basic rudder-home mechanism in my project but it currently is a bit too simple; mainly due to GPS latency I sometimes get nasty oscillations. I now use a linear relation of required correction and rudder-deflection, clipped at -45 and +45 degrees. . I have all sorts of algorithms is mind to improve it. What algorithm do you use or plan using?
Edited by FredericG, 28 June 2007 - 07:03 AM.
Posted 28 June 2007 - 09:42 AM
You sir, were one of the reasons I got inspired to roll my own OSD. I saw what you were doing and thought it looked nice. That got me pointed to the BOB-4 and now I am here. See how we all help each other in ways we never imagined!
My thinking about the rudder home will be a heavily damped response to the heading. Generally, what I am expecting is a very slow turn, which will reduce more as the angular error to home gets smaller. I expect the plane to overshoot a bit but the correction will be very gentle. The resulting effect that I am predicting is something like an slow S-shaped path towards home. This is akin to what is known as "tacking" - a kind of zig-zag path. There will be lots of averaging done to damp (basically low pass filtering) the data to prevent fast oscillations.
I should say that I don't intend to use other assists such as the FMA devices. I will track the rate of turn to see how effective the system is responding. So, if wind is causing a lower than expected (or even negative) rate of turn, it can either apply stronger rudder or other strategies (maybe turn the other way) to get on the home path. My controller has control of both rudder and elevator so it will try to maintain altitude as it comes home. Since I don't have attitude information, I have to extrapolate whatever I can out of the rate of turn (and altitude) data.
How well is your rudder home algorithm working? Have you tried it without the FMA in operation? Does it work well? I'm open to suggestions but I'll have more concrete ideas myself once I get the thing tested a bit more. I also have a pressure sensor sitting here that I might want to add in but I'll see how well the GPS altitude performs first.
Edited by Daniel Wee, 11 September 2008 - 04:05 PM.
Posted 28 June 2007 - 12:31 PM
You sir, was one of the reasons I got inspired to roll my own OSD. I saw what you were doing and thought it looked nice. That got me pointed to the BOB-4 and now I am here. See how we all help each other in ways we never imagined!
Without co-pilot it does not work; I don't think it is possible with only GPS as feedback. The simple approach I use now, works very well, most of the times, but not always. The root cause is the lag in the GPS data. This can of course be solved my taking a slow turn. The problem is that the wind can prevent the plane to turn, so you need rather important rudder deviation. But the problem is than that the plane turns too fast in the case the wind is assisting the turn. Sometimes this results in oscillations that can no longer be called zigzagging to the target.
How well is your rudder home algorithm working? Have you tried it without the FMA in operation? Does it work well? I'm open to suggestions but I'll have more concrete ideas myself once I get the thing tested a bit more.
Posted 28 June 2007 - 04:43 PM
i still think your project should be fussioned with wps-2, wich is the most complet autopilot, with alt hold, gain to servos and much more things,
Posted 28 June 2007 - 05:01 PM
As for fusing - I'm trying to keep this controller as simple and stand-alone as possible at the moment. Let me give it a shot first, at pulling off the navigation without extarnal aids (and more money spent). I have some ideas I'd like to try for navigating the plane. Incorporating FMA Co-pilot would be trivial though, if I should need it later.
Posted 28 June 2007 - 06:40 PM
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...
Edited by wallaguest1, 28 June 2007 - 06:58 PM.
Posted 28 June 2007 - 10:16 PM
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).
Posted 29 June 2007 - 08:06 PM
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.
Edited by Daniel Wee, 29 June 2007 - 08:07 PM.
Posted 29 June 2007 - 08:44 PM
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,
Posted 30 June 2007 - 04:40 AM
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.
Posted 30 June 2007 - 08:58 PM
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.
Posted 30 June 2007 - 10:11 PM
Posted 01 July 2007 - 05:46 AM
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)
Edited by Daniel Wee, 01 July 2007 - 05:49 AM.
Posted 01 July 2007 - 08:20 AM
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.
Posted 01 July 2007 - 04:15 PM
wich font got your osd? i don't find any one that match your font in windows,