Thread Tools
Old Mar 22, 2010, 03:11 AM
kempo is offline
Find More Posts by kempo
Registered User
kempo's Avatar

Rth


John, Daniel how does RTH function works? It activates only on RC signal loss or it can be activated by an open channel from RC? Until the plane reaches home position it keeps altitude or the plane go down/up to a preset altitude? When the plane reach home position it start making circles above? Thank you for the answer.
Sign up now
to remove ads between posts
Old Mar 22, 2010, 03:20 AM
renatoa is online now
Find More Posts by renatoa
Registered User
Also, how it sense RC signal loss?
How is altitude controlled, does it control both throttle and elevator?
Old Mar 22, 2010, 03:34 AM
David22 is offline
Find More Posts by David22
Suspended Account
Did I miss a video of what it looks like as you fly?
Old Mar 22, 2010, 03:55 AM
kempo is offline
Find More Posts by kempo
Registered User
kempo's Avatar
Quote:
Originally Posted by David22 View Post
Did I miss a video of what it looks like as you fly?
I don't understand your question......I fly 1/2 fpv (without takeoff and landing ) .
Old Mar 22, 2010, 04:01 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
The RTH works the same as for the original DragonOSD. The receiver should be programmed to activate the autopilot in failsafe mode. One of the channels of the receiver will be assigned this control task (as well as activating the in-flight menu). That control channel serves several purposes - activates menu, turns off all screen display, activates autopilot, or normal display mode - depending on the value of the channel. So you typically set the failsafe value for that channel so that it activates the autopilot. It does not directly detect loss of signal since different radios have different loss of signal conditions.

Because of this, you can either manually activate autopilot or have it activated via a failsafe condition. In my usage, I normally assign the autopilot to one position on a three-way switch on the radio. With that switch I can either activate menu, failsafe, or normal mode.

The DragonOSD has two assignable control channels. This means that you can select which two servo channels you want it to control. For example, you can have it control the rudder and the elevator, in which case you will have altitude control and steering. Or you can have it control two ailerons, in which case you don't have elevator control for altitude management. You could one channel to throttle as well but I have not implemented throttle management algorithm for now. So, basically, you can pick any two channels to be controlled.

Apart from this assignability, the autopilot operation would be identical to that of the original DragonOSD.

As for a video - take a look at Jettpilot's Zephyr thread - there's a video in there which shows the OSD in operation:-
FPV Plane FPV (3 min 48 sec)


Daniel
Last edited by Daniel Wee; Mar 22, 2010 at 04:50 AM.
Old Mar 22, 2010, 04:25 AM
Unpoor is offline
Find More Posts by Unpoor
Registered User

PPM in?


Since I didnt see any channel in just PPM in and channel out, wich rx is it compatible with?
Old Mar 22, 2010, 04:44 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
The PPM-in will only be needed if you want to use the RTH and control features. If you just want a simple OSD that doesn't have these advanced features, the PPM in won't be needed. The OSD can be configured via a serial port as well.

DragonLink and Thomas's LRS system both feature PPM outputs so those are compatible. However, if you are using a standard receiver, many can be modifed to give you a PPM output. The following link lists some such receivers and modifications:-

http://paparazzi.enac.fr/wiki/Other_....2FC_Receivers

Alternatively, you can get a PPM stream via other means - the following link has some leads to these options:-

http://forum.tsebi.com/viewtopic.php?f=7&t=37

Daniel
Old Mar 22, 2010, 09:43 AM
renatoa is online now
Find More Posts by renatoa
Registered User
I don't get the point why you need the *whole* PPM stream from the receiver, and not simply tap into one of the channels available ?
Old Mar 22, 2010, 10:09 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
Using the PPM stream accomplishes at least two important things:-

1. Reduction of cables. Typically you need one control channel, one rudder or aileron channel, and one elevator channel. This is a minimum of 3 servo cables between the receiver and the OSD. While it may not seem like much, if the two are separated quite a bit, there can be a lot of cables in between, which will contribute to noise pick up, noise radiation, extra weight, and so on. With the PPM stream input, all you need is just one servo cable to replace three or four cables between the receiver and the OSD. This also allows for a smaller OSD board (one of the aims of this OSD is keep it small and light) and simpler installation.

2. Channel assignment flexibility. With just the PPM stream, you don't have to worry about hooking up the wrong channel. All that can be configured in the menu so if you decide to re-assign the control channel on your radio, or the elevator channel, for example, you do not need to re-wire anything in your plane. Just a simple menu change will suffice.

Apart from that, having the PPM signal also allows for more features to be added in the future, without the need for more cabling. It does create a bit of an inconvenience for users of more traditional receivers but at the same time there are benefits that come with it. I do realize that this is the first time such a thing has been tried with an OSD but I have a hunch that this could be the way to go with future OSDs, reflecting the trend that MikroKopter has taken. If nothing else, at least we're innovating and not just producing more of the same.

Some of the goals of the DragonOSD+ were:-
1. affordable so that even if it were destroyed, the pain to the wallet would be less
2. matches the text/graphics quality with full screen (edge-to-edge) display capability
3. black bordered text/graphics for high visibility
4. full graphics engine capable of rendering lines, circles, graphics, etc.
5. multi-font support
6. small and light so that it can fit into small planes
7. energy efficient with wide power supply range without getting hot, heavily filtered
8. fewer cables to hook up for RTH capability
9. user upgradable firmware, without need for special programmer
10. universal peripheral/sensor bus that can take many devices easily
11. huge logging capability (this OSD will log multiple flights and you can download to Google Earth files)
12. audio alert capability
13. expandability and device flexibility (will accept different types of GPSes, for eg.)

The idea is to have the above full-featured OSD at a price of much lower featured OSDs. And to have the quality such that even without the RTH features, it would still outperform and outprice other non-RTH capable OSDs. Truth is it was hard trying to get all of that into one small package and in the process, one of the decisions that had to be taken concerned the PPM-stream input.

Daniel

p.s. From a software point of view, some of the goals were:-
1. "uncluttered look" philosophy
2. user can select multiple styles (eg. you can select from 3 or 4 compass styles, etc.)
3. screen display configurability
4. can be configured in-flight
5. can also be configured via serial terminal
6. sensors/devices auto-detection
Last edited by Daniel Wee; Mar 22, 2010 at 10:51 AM.
Old Mar 22, 2010, 10:21 AM
MelihK is offline
Find More Posts by MelihK
MelihK's Avatar
Hi Daniel,

do you know the easy way for taking PPM stream from receivers?
I'm making a new Quadrocopter and PPM stream will easy way for me. But only analog receivers including ppm stream output from rf-receiver and i cant find a way for making this with my 2.4 or synth receivers

thanks
Melih
Site Sponsor
Old Mar 22, 2010, 10:21 AM
jimbob00 is offline
Find More Posts by jimbob00
Registered User
Going on with the IMU/RTH things, how hard would it be to just take the input from a sensor like this one (which is not an IMU, but the IMU seems difficult to implement for now, while this one seems quite easy):

http://paparazzi.enac.fr/wiki/Infrared_Sensors
http://paparazzi.enac.fr/wiki/Infrar...l_Sensor_Board

and integrate the control with the DOSD's autopilot?
It means also that it should to provide stabilization when not in autopilot mode to make complete sense (i don't know if the DOSD has enough power to do that at all time ?)
Old Mar 22, 2010, 10:37 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
Those aren't IMU as they're IR based. IMU's are "I"nertial and I'm working on a true IMU based stabilization. If someone else beats me to it, I can easily add that as a device to the I2C bus. That's the plan anyway. I'm not a huge fan of IR based stabilization since it doesn't work in clouds and I like flying in clouds. I should also clarify that IMU's usually refer to the sensor block. What I am working on is not just the sensor block but also the sensor fusion unit, more akin to the INS (inertial navigation system). That is where the real work is done.

The OSD has plenty of computing resources to spare and I do intend to add stabilization in time to come.

Daniel
Old Mar 22, 2010, 10:42 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
Melih,

There are quite a number of options for 2.4GHz receivers. You can find some of the links here:-

http://forum.tsebi.com/viewtopic.php?f=7&t=37

There are some easy ways to multiplex the output of the receiver into a PPM stream with very little latency. If you really want an easy way (that is if your receiver cannot be modified), try this:-

http://www.mftech.de/catalog/product...products_id=44

Daniel
Last edited by Daniel Wee; Mar 22, 2010 at 10:49 AM.
Old Mar 22, 2010, 11:01 AM
magnetman is offline
Find More Posts by magnetman
Fly the Discombooberator!
magnetman's Avatar
Quote:
Originally Posted by Daniel Wee View Post
The RTH works the same as for the original DragonOSD. The receiver should be programmed to activate the autopilot in failsafe mode. One of the channels of the receiver will be assigned this control task (as well as activating the in-flight menu). That control channel serves several purposes - activates menu, turns off all screen display, activates autopilot, or normal display mode - depending on the value of the channel. So you typically set the failsafe value for that channel so that it activates the autopilot. It does not directly detect loss of signal since different radios have different loss of signal conditions.

Because of this, you can either manually activate autopilot or have it activated via a failsafe condition. In my usage, I normally assign the autopilot to one position on a three-way switch on the radio. With that switch I can either activate menu, failsafe, or normal mode.

The DragonOSD has two assignable control channels. This means that you can select which two servo channels you want it to control. For example, you can have it control the rudder and the elevator, in which case you will have altitude control and steering. Or you can have it control two ailerons, in which case you don't have elevator control for altitude management. You could one channel to throttle as well but I have not implemented throttle management algorithm for now. So, basically, you can pick any two channels to be controlled.

Apart from this assignability, the autopilot operation would be identical to that of the original DragonOSD.

As for a video - take a look at Jettpilot's Zephyr thread - there's a video in there which shows the OSD in operation:-
http://www.youtube.com/watch?v=WfolA...layer_embedded

Daniel
Daniel,

I know that this is an old old chestnut, did you ever develop any further the inertia nav (IMU) side of things??

Regards
Richard
Old Mar 22, 2010, 11:12 AM
Daniel Wee is offline
Find More Posts by Daniel Wee
Registered User
Yes, I actually have pages upon pages of research on it and several prototypes. The problem is trying to make a cheap one that still works well. It's a lot of work but there is light on the horizon, in more ways than one. I will make those announcements shortly.

Daniel


Thread Tools

Similar Threads
Category Thread Thread Starter Forum Replies Last Post
Discussion Dragon OSD Level Flight FPV Talk 22 Dec 31, 2013 09:08 PM
For Sale New Intelligent Flight Dragon OSD bfischer Aircraft - General - Miscellaneous (FS/W) 7 Jul 19, 2010 12:56 PM
Discussion FS Ready to fly Intelligent Flight Dragon OSD bfischer FPV Talk 0 Mar 03, 2010 06:57 AM
Discussion RV OSD or Dragon OSD djdaveq FPV Talk 1 Feb 06, 2009 01:18 AM
Discussion RV OSD and Dragon OSD - so near to being Really good! magnetman FPV Talk 8 Nov 11, 2008 06:13 AM