How do you initiate autonomous flight

[Tom Harper]

There are some aerial photography subjects that are marginal or out of range of the RC transmitter. What are the criteria/signals that can be used to switch to and from ground control when the model will be out of transmitter range for most of the flight?

[kd7ost]

I think it's worthy of a discussion.

I use a PCM radio and failsafe. When I turn off the transmitter, a spare channel is set to enable the device(s). In the remote environments like you and I fly in this is very secure. Someone would have to have the same radio, in range with the same channel to affect a problem. It would have to look exactly like your transmitter. The PCM doesn't process signals that don't fit the code.

I under stand the DSR type standard FM aftermarket receivers do the same thing. But this stuff is so critical to me that I don't bother with trying to match up different brands.

Dan

[Tom Harper]

Dan,

So you just take the absence of a PWM output as the switching signal or is it part of the failsafe feaure?

The assumed range of most transmitters is 3 miles. Have you done any actual range testing?

[Peter Seddon]

Can you use the receiver signal strength output which I believe can be hacked out of most receivers?

regards Peter

[icebear]

Tom,

I have tested some of the non-PCM receivers on the market in the same way as Dan describes.

So far the FMA FS-8 Rx has an excellent failsafe feature that lets you either set a pre-set failsafe position or use "last good frame" hold. I set all my channels to last good frame except the ENABLE channel which then activates the autopilot in case of a lost signal (deliberate or otherwise).

The only funny thing about the FMA Rx is that it has low level logic output which is not mentioned anywhere - I had to find out the hard way (my autopilot needs a booster to work with the FS-8)

I have also tested the Schulze receivers which have the same features plus more (!).

/Icebear

[MX]

I wonder if the new CC Berg-7P will work that way. It can be setup with failsafe positions.

MX

[macboffin]

Best way, use a gps and rudder steer, initiate via fail-safe on signal loss or by turning Tx off, when the gps unit will take the plane to pre-set way points terminating back at the field, when you turn on the Tx again to regain control.
Best to have a height-hold unit also; back over your head at five thousand feet isnt much use, nor is flying into the distant hill! Check out www.u-nav.com.

[Tom Harper]

Thanks for the information.

Since my system is DIY I'll need to incorporate one of these schemes. I assume the transmitter signatures are derived from the differences in pulse position of the Xmted channels and/or in the pulse transmission rate. That would be easy to monitor with a cheap micro.

At present I am using a servo module for transmitted on/off. I think it could be rigged to respond to Xmtr Off. I'll play with it and post the results here.

Thanks for the ideas.

[kd7ost]

Dan,

So you just take the absence of a PWM output as the switching signal or is it part of the failsafe feaure?

The assumed range of most transmitters is 3 miles. Have you done any actual range testing?


I have Tom and agree with some of the others comments.

In the failsafe receiver, (excuse me if you already know this) they re-create the pulses through a processor. The processor is automatically set up when new, (default settings) that if the input signal isn't right, it will continue to replicate pulses to each channel the exact same pulse width as last received before the failure. They are looking for a code to be correct though. It's not just if the signal is lost like a dead transmitter or being out of range. It's also if someone comes on at the same frequency and the receiver front end is getting too much stuff. It will lock the servos to the last good reading.

Each channel can be set up through the programming menu to act differently though. The act of going into failsafe can make servos move to specified positions. That's what I generally do. I set it so my throttle goes to 75 percent. Rudder, elevator, ailerons all neutral. I set the nose camera to look straight ahead too. In the course of normal flying if I see the camera suddenly move to forward view, I know I’m going into failsafe. GPS or guidance device being kept off by a servo pulse of .5 ms comes on when the pulse is at 1 ms. I set it to move to full extreme at 1.5 ms duration. You can enable that channel overhead for testing and loiter overhead. You can turn off the transmitter and let it function too.

As Bjorn stated certain systems don't put out a 5 vdc TTL pulse to servos. Most do but the Futaba PCM as well as the FMA unit put out 3.3 vdc pulses. No problem to a servo so you'd never see it. Unless you're using it to activate a TTL PIC chip driven device. As you know Tom, 3.3 vdc is ambiguous to a TTL chip and only special PIC chips will recognize it as a logic high. There are a few ways to resolve that but here's a thread I posted on it some time back posted down below.

I’ve never seen even 2 miles from my system at the low altitudes we fly. The radio wave propagation along the ground interferes with range. But I also fly with my receive antenna located horizontal and when flying away or towards myself am off the null. If it were oriented vertically, like maybe up a plastic antenna holder, I suspect increase would be observed. I bet if you went high overhead with two aligned horizontal antennas, you could go 15 miles or better. I might try that some day from a weather balloon just to see what kind of range would be normal.

Dan

[kd7ost]

Here are the two replies worthy of reading. There are other new recievers out there so this isn't by any means the last word.

Dan

There are two qualities in some Futaba PCM receivers that can cause interfacing problems with certain electronic devices. Most notably interfacing with 5 volt TTL circuits including PIC chips or interfacing with the Co-pilot CPD4 roll and pitch stabilizing unit. The two qualities are described as follows.

Both these issues are caused by the same thing. The way Futaba processes their servo signals. The processor used is a 3.3 volt unit. This means the pulses being generated are only 3.3 volts as a logic high. TTL circuitry needs to have 5 volts +/- a small percentage. 3.3 volts is too low to be considered a logic high and can cause ambiguous operations.

The other thing Futaba does when sending the servo pulses is they send them all in parallel. In other words, all the pulses going to all the channels are being clocked out at the same time. This doesn't matter in normal operations because they're all going to different places.

This can be a problem when sending those pulses to a device where a processor reads them. Like the co-pilot. The co-pilot needs to read those pulses coming in individually. It takes in first one, (either pitch or roll it doesn't matter) then the other in order to make sense of them. Other receivers send pulse out one after another and in sequence. First to channel 1, then 2, then 3 and so fourth until it starts over again. This is what the co-pilot is looking for. First one pulse then the other.

So how do we work with these? There are a couple of ways. First, changing the voltage level of the pulse from 3.3 volts to full battery level. Typically 4.8 to 6 volts. All you need to do is install a servo buffer in line between the receiver and the TTL device or PIC chip. This device takes the incoming pulse and re-creates it to help the pulse stay intact on long runs or RF noisy environments. As a side effect, it will re-create the pulse at the same level as the battery pack it's plugged into.

Coincidentally, this is also the recommended way to resolve the issue to the co-pilot. All you need to do is to add one, perhaps two, servo drivers on one of the two signals coming in. Only one though. (It doesn't matter which one) The servo buffer causes a slight delay as the pulse gets shifted though. That means on the output, that pulse will no longer be lined up with the pulse that isn't being sent through a servo buffer.

You can also shift the levels out of a 3.3 volt receiver by installing a device like a Jomar optically isolated Glitch buster. The pulses coming into the glitch buster will be 3.3 volts but they will be re-created on the output at the full battery voltage level.

Please add any other unique situations and work around solutions you may be aware of.

Dan

And this one...............

mr.rc-cam wrote:
As far as the common solutions, I think you have covered them well. I am not a Futaba user but I am aware of their parallel ordered PCM servo channels. However, I thought that only pairs of channels were in parallel and not all eight. Can you confirm what the real deal is? Smile


Confirmed. You sir are correct. I never heard of that but that's what's happening on my system alright. I have an 8 channel Futaba T8UAP PCM transmitter and a FP-R148DP 8 channel receiver. What I see is channel 1 and 2 are sent at the same time as each other. Then goes 7 and 8 together, then 3 and 4 together and finally 5 and 6 together before cycling back to 1 and 2 again..

When putting the system into failsafe, I observed no changes in this sequence.

It's still a problem for the co-pilot though as channel 1 and 2 are Aileron and Elevator respectively. This is where you have to delay one of those pulses for the co-pilot by routing it through something like the servo buffer. The propagation delay as a pulse routes through the buffer causes it to lag behind the other pulse that hasn't been sent through a buffer. FMA says you need to use 2 servo buffers at times. This is likely because even though there are 6 schmitt trigger inverters in that chip, some manufacturers may only route it through 2 while some might use 4 and some 6. The more inverters you run it through in a single chip, the more delay you can induce.

Thank you for the valuable insight mr.rc-cam

Dan

[Tom Harper]

Dan,

Thanks - that answers a lot of issues.

I can use preset pulse widths. Rudder and throttle are active controls. Elevator and Aileron can be 1.5 ms PWMs to the Co Pilot. It looks like I need to offset them by ten microseconds or so. That won't be a problem.

Thanks again.

Tom

[kd7ost]

Happy to do what I can Tom. It isn't much more than plugging in info from my previous and sometimes frustrating integration process. Guys like you do the real magic. ;)

I should update my description above. Since the time I authored that I've learned that not all servo buffers will shift the 3.3 VDC servo pulse amplitude to full applied VCC. There are two major IC choices I'm currently aware of that are used in servo buffers. I also see another as of yet unused option.

Servo buffers are made from CD4049, MC14049, 74HC4049 and the like inverting Hex Buffers.

But also they can be made from CD4069, MC14069, 74HC4069, and the like hex inverting buffers.

The 4069’s do just as good a job as the 4049 in acting as a servo amp/buffer/ noise trap etc. However the 4069 will give out a pulse amplitude the same as what it gets in. If it gets a 3.3 vdc pulse in, it won’t level shift it to the full applied supply voltage. It goes right back out as a 3.3 volt pulse. It does the job it was designed for but we’re looking for a by product of level shifting that pulse in these applications.

The 4049 will provide logic level shifting using only one supply voltage. You can power it with 5 volts if you want. Feed in a 3.3 volt pulse and get out a 5 vdc pulse.

Only the 4049 will do that. Obviously since it’s an inverting gate, you have to run the pulse through 2 or 4 or all 6 to prevent inverting the pulse. When I make them at home I use the 4049 type and go through every gate just to keep from having to tie the unused ones up or down.

There are also higher cost solutions such as the opto-isolated servo drivers which have the receiver inputs on one side with a standard 4.8 volt pack, and the isolated servo outputs with a higher voltage on the output side. The level shifting happens at the output side of the optical device. I’m familiar with and use the “Jomar Glitch buster” in my big plane. It serves a few good purposes with all that wiring I have in that plane.

That as of yet unused option I mentioned above is this.

There is a non inverting compliment to the 4049. The 4050 works the same way except that it doesn’t invert the pulse through any given gate. As a hex unit it seems to me that if a person needed to level shift up to 6 pulses this would be a good choice to put on the output of up to 6 of the receiver servo channels. It also will do the logic level conversion with a single supply voltage.

I’m using a buffer made from the 4049 in my small Dragonfly plane right now but it was actually used to offset that Futaba characteristic of sending pulses in pairs. My co-pilot is getting the Aileron pulse sent through the buffer just to use the propagation delay so the aileron pulse arrives offset from the Elevator pulse.

Dan

[ebayrcer]

I wonder if the new CC Berg-7P will work that way. It can be setup with failsafe positions.

MXMX, DiveBombDave and I each use the CC Berg-7P. You wonder if it will work in what way? I can send you a link for the product's manual, but I'm pretty sure (from your realization that it can be setup with failsafe positions) that's not what you're after.

Btw, thanks again for a great product in the Prism; it simply rocks!


- ebayrcer -

[walkermsg]

Would it be possible for a battery operated plane to acheive the ranges mentioned here or would I have to get into gasoline powered planes ? I am a Ham radio operator, is this necessary for the video signals from a camera ? Also where can I find a camera that will deliver more than 300 feet which is the max for mine ?
Thanks for any info, I am just getting back into model planes after retiring.
Thanks, Lee

[Tom Harper]

Walker,

Electrics are getting good! It's only a matter of how many $$$ you have available for batteries.

I am interested in seeing the responses to your question on video. I'd like to try it.

Tom

[MX]

MX, DiveBombDave and I each use the CC Berg-7P. You wonder if it will work in what way? I can send you a link for the product's manual, but I'm pretty sure (from your realization that it can be setup with failsafe positions) that's not what you're after.

Btw, thanks again for a great product in the Prism; it simply rocks!


- ebayrcer -

All I'm thinking is that I set one of the switch channels to failsafe to a given position, so that when the radio is turned off or out of range, the channel goes to that position, indicating to the autopilot that it should take over.

For example, channel 5 is my gear switch, so I set the fail safe with channel 5 in the ON position. Then I fly with the gear switch in the OFF position. Now if the receiver loses signal, the Berg 7P will failsafe channel 5 to the ON position and enable the autopilot. I can also use the switch to enable/disable autopilot as desired.

I haven't tried this yet since I don't have a crystal for my 7P yet.

Thanks,

MX

[Magician]

I'd be careful with using the failsafe as the default switch for engaging the autopilot when you lose signal due to range. What you may end up seeing in practice is that as the airplane gets to the limits of range and it loses link, the radio goes to failsafe, the autopilot engages and the airplane turns for home. Immediately after initiating the turn the radio link comes back, the radio re-initializes to the transmitter settings (autopilot off) and you have to then take manual control which may lead to an unusual attitude which could cause the loss of the RF link since you are at the limits of range and the autopilot re-engages. This can be a very vicious cycle that you did not intend. The act of turning off the radio eliminates this possibility.

My question is, if you have an autopilot and want to fly way out, why not just let the autopilot get you there in the first place? It seems to be a very expensive option just for a return home system.

Just passing on my experience. :D

[Tom Harper]

Magician,

I do not have fail safe so I am looking for a positive way to switch the autopilot on and off. I am using the module from a servo for switching within transmitter range. The problem with using that circuit out of range is that it's output is latched. A noise pulse of the right width could turn off the auto pilot.

I assume that a pulse width detector followed by an integrator would make the most sense.

[clolson]

Just saw a demo of the new Spektrum 2.4Ghz full range radio system at my R/C club meeting the other night. With this system you bind a receiver to a particular transmitter (actually a 1 of 20 possible aircraft setups for a particular transmitter.) After that, the receiver will refuse to talk to any other transmitter and will only talk to it's bound transmitter once that transmitter is set for the proper aircraft.

If you program your failsafe to trigger the autopilot, this would seem to be a reasonably "secure" way to enter autopilot mode without the chance of a stray signal or some random person on the same frequency inadvertantly popping you out of autopilot mode. Only your particular transmitter could ever bring your aircraft back out of autopilot mode.

The receiver sends out standard servo pulses to drive standard servos, so it would be compatible with the standalone manual override board mentioned in another thread here.

Can anyone think of any big downside to this system that I might be missing? If I'm using a Xbow MNAV, I won't be able to log transmitter inputs since there's no PPM signal to tap into, but I might be able to live with that given all the other benefits this new system seems to offer.

Curt.

[d_wheel]

Just saw a demo of the new Spektrum 2.4Ghz full range radio system at my R/C club meeting the other night. With this system you bind a receiver to a particular transmitter (actually a 1 of 20 possible aircraft setups for a particular transmitter.) After that, the receiver will refuse to talk to any other transmitter and will only talk to it's bound transmitter once that transmitter is set for the proper aircraft.

If you program your failsafe to trigger the autopilot, this would seem to be a reasonably "secure" way to enter autopilot mode without the chance of a stray signal or some random person on the same frequency inadvertantly popping you out of autopilot mode. Only your particular transmitter could ever bring your aircraft back out of autopilot mode.

The receiver sends out standard servo pulses to drive standard servos, so it would be compatible with the standalone manual override board mentioned in another thread here.

Can anyone think of any big downside to this system that I might be missing? If I'm using a Xbow MNAV, I won't be able to log transmitter inputs since there's no PPM signal to tap into, but I might be able to live with that given all the other benefits this new system seems to offer.

Curt.

The "failsafe" is a limiting factor for me. The only channel that can be set to go to a specified position is the throttle. It goes to idle when in failsafe mode. All other channels stay at their last position. To trigger an autopilot, you need to be able to set one channel to turn it on, and with some systems you must set all control surfaces to go to center.

Later;

D.W.

[kd7ost]

Here's another idea.

For an after market failsafe you could use something like an intelligent missing pulse detector. "You" can do it with code and a small PIC probably. ;)

Have it look for pulses that are .5 to 1.5 ms in duration only. Outside of that is a spike or inerference. Also have it check that they only occur at about a 20 ms frame rate. That will vary a little between transmitters and how many channels you're sending but should be adjusted fairly easy in the code. Have it send an output designed to enable or disable your failsafe if the pulse requirements fall outside or come back into that criteria.

Dan

[clolson]

The "failsafe" is a limiting factor for me. The only channel that can be set to go to a specified position is the throttle. It goes to idle when in failsafe mode. All other channels stay at their last position. To trigger an autopilot, you need to be able to set one channel to turn it on, and with some systems you must set all control surfaces to go to center.


We were told at this little demo that with the Spektrum 2.4Ghz system, you can set the fail safe servo positions independently. So if that is true, with this particular system anyway, you shouldn't have the problem you describe. And the system should be secure in the sense that the autopilot can't be inadvertantly or intentionaly turned off by some outside source of interference because it will only recognize legitimate transmissions from the transmitter it is bound to.

Haven't said all this, I'm just going on the comments of the person demonstrating the system, I don't have any directly personal experience.

I was mainly wondering if anyone else thought this might be an interesting solution to how to keep your autopilot securely enabled when flying out of transmitter range, and if there might be any "features" of this system I am misunderstanding, or issues I might be overlooking that would cause problems using this system in conjunction with an autopilot?

i.e. before I plunk down $350 for a new radio, tell me what I'm missing, or where my logic is failing, please!

Regards,

Curt.

[Mr.RC-CAM]

DiY PIC Base R/C Failsafe: http://www.rc-cam.com/rcfs2.htm

Tiny DiY R/C Switch (includes lost signal alert): http://www.rc-cam.com/bitsw.htm

[kd7ost]

DiY PIC Base R/C Failsafe: http://www.rc-cam.com/rcfs2.htm

Tiny DiY R/C Switch (includes lost signal alert): http://www.rc-cam.com/bitsw.htm

Thats the ticket. ;)

Dan

[Tom Harper]

Looks like a great solution. It also makes the point that this function is worthy of a dedicated processor.

Arrrgh...I just finished a DigiKey order before I read this post.

[Unterhausen]

the BR6000 receiver for robots sets all channels to the bind positions when the radio is turned off. The AR7000 sets only the throttle to the bind position. The problem I see is if you want to run a wifi downlink, it will be difficult to get decent range with the DX7

[d_wheel]

We were told at this little demo that with the Spektrum 2.4Ghz system, you can set the fail safe servo positions independently.

Curt.

You were misinformed.

Later;

D.W.

[d_wheel]

the BR6000 receiver for robots sets all channels to the bind positions when the radio is turned off. The AR7000 sets only the throttle to the bind position. The problem I see is if you want to run a wifi downlink, it will be difficult to get decent range with the DX7

The original message did not mention a down link. If one is being used, it will have to be on something besides 2.4ghz.

Later;

D.W.

[Magician]

You were misinformed.
Later;
D.W.

I find it hard to believe that a new state of the art radio with so many unique features wouldn't allow you to set failsafe positions for surfaces and switches. So, I read the manual from the Horizon site (http://www.horizonhobby.com/ProdInfo/Files/SPM2710_DX7_Manual.pdf).

Sure enough, it says on page 18 "Note: Fail-safe positions are stored via the stick and switch positions on the transmitter during binding." Then on page 19 it says "Establish the desired fail-safe stick positions: normally low throttle and flight controls neutral".

So it appears that you can set the switches and flight controls for fail safe via the binding process. I can see how someone may misinterpret this since it says that most people set it for throttle low and neutral sticks plus this is what they showed on their video introduction. Plus their definition of the SmartSafe Fail safe contridicts the set up procedures.

Any one have a DX7 that they can test so we can put this to rest?

[d_wheel]

Any one have a DX7 that they can test so we can put this to rest?

Yes. I have one. The throttle goes to idle and all control surfaces go to the last position that was received from the transmitter.

There has been a lot of discussion on it already. Check here:

http://www.rcgroups.com/forums/showthread.php?p=6679481&highlight=dx7+failsafe#post6679481
http://www.rcgroups.com/forums/showthread.php?p=6676072&highlight=dx7+failsafe#post6676072
http://www.rcuniverse.com/forum/m_5133633/anchors_5133633/mpage_1/key_dx7%252Cfailsafe/anchor/tm.htm#5133633

I agree that this is not the way it SHOULD be, but I seem to be in the minority. Most of the discussion on this subject says it it the best way to do it.

Later;

D.W.