735 replies to this topic

[Kilrah]

I have sodium persulphate, works well too...

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.

[Daniel Wee]

Okay, I've got it so that it shows both ground distance (only when closer than about 300m) as well as absolute (line of sight) distance. The reason for this is because as you go further out, the two distances start to converge so there's no need to have two numbers on the screen, it will turn the ground distance off. I picked the absolute distance as the default because the radio range is dependent primarily on the this, the line of sight distance, and not on the ground distance. My primary concern is to not fly out of radio range.

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.

Daniel

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.

[wallaguest1]

yes a back home function when failsafe become on is a good feauture to add,

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

Rcapv3 http://www.rcgroups....ad.php?t=652952
and
Wps-2 from MX http://www.rcgroups....ad.php?t=682910

[docphi]

Looking at the final board now, I think this thing may be marketable.

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

Edited by docphi, 27 June 2007 - 06:03 PM.

[Daniel Wee]

Thanks doc! I've sent you a PM.

Daniel

[FredericG]

A friend brought this thread to my attention. Congratulations, it looks very good.

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?

Thanks
Frederic

Edited by FredericG, 28 June 2007 - 07:03 AM.

[Daniel Wee]

First, some updates: The servo passthrough code is working but I've not had time to measure the latency. I'll do that tomorrow. My guess is that this should not be a problem. Also, I've got the 74MHz crystals and they do solve the problem. However, there is a side effect in that the screen is stretched horizontally just a hair (about 1.3% longer) but this is easily dealt with, plus vertical lines look better now. I must warn that removing the crystal isn't a job for the faint-hearted (and with bad eyesight like me)! This means I can now push on to testing in flight!! Yayyy!

Hi FredericG,

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.

Daniel

Edited by Daniel Wee, 11 September 2008 - 04:05 PM.

[FredericG]

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!

Ah, good...

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.

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.

Frederic

[wallaguest1]

you can add some memory reserved to save gps data so we can draw in google earth the router automatically,

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,

[Daniel Wee]

I have enough memory to record 1 position (with heading and speed and time) once every 20 seconds for 20 minutes (roughly), or every 10 seconds for 10 minutes.

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.

Daniel

[wallaguest1]

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

Edited by wallaguest1, 28 June 2007 - 06:58 PM.

[Daniel Wee]

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

[Daniel Wee]

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, 29 June 2007 - 08:07 PM.

[wallaguest1]

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,

[Daniel Wee]

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

[Daniel Wee]

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

[JMS]

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

[Daniel Wee]

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, 01 July 2007 - 05:49 AM.

[Daniel Wee]

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

[wallaguest1]

nice video, a littlebit pixeled,

wich font got your osd? i don't find any one that match your font in windows,