Replies to This Discussion

Permalink Reply by spagoziak on December 7, 2011 at 7:53pm

Have you seen this page from the manual?

• ▶ Reply

Permalink Reply by Mike Mac on December 8, 2011 at 3:40am

Yes I followed those instructions and set the RC5_function to 1. Channel 5 does not work until you set that value. It woke in the manual mode but when I do the preflight check in the Stabilize mode only one aileron moves. I Is it suppose to fly using just one aileron?

• ▶ Reply

Permalink Reply by Mike Mac on December 8, 2011 at 7:27am

Apparently I am the first one to actually try to fly this option. This is on a new airplane and I just updated all the firmware (V2.26).

Maybe I will just go back to a Y cable for the first flight.

• ▶ Reply

DeveloperPermalink Reply by Doug Weibel on December 8, 2011 at 7:42am

I have flown with the two aileron option, as well as the flap option.

What version of the code are you using?

• ▶ Reply

Permalink Reply by Frank on December 8, 2011 at 9:16pm

wiki is wrong this is maye the 3rd time I say that.. you should set rc5 = 4 not 1 that is passtrough.

it has no hw failsafe, only sw. is apm reboots you lose tha 2nd aileron

• ▶ Reply

DeveloperPermalink Reply by Doug Weibel on December 9, 2011 at 7:37am

Frank,

Thanks for pointing that out.  Sorry I missed it earlier.  The wiki has been corrected.

As an aside, you are correct about the second aileron channel not being handled by the mux.  However, the dev team does not think that is a huge problem, as the stability of the code is constantly improving.  You will note that APM2 does not even have a hardware mux.  Users who still want that functionality can use an external mux, and that approach can include more than 4 channels.

• ▶ Reply

Permalink Reply by Mike Mac on December 9, 2011 at 9:48am

If the APM hangs will aileron 2 go to center, hold last position, go hard over, or is the position unknown (random). If aileron 2 was about center you could get it back and land with only one aileron. I am just trying at access the risks vs. the benefits.

• ▶ Reply

Permalink Reply by Frank on December 9, 2011 at 8:20am

Doug

Anyone who try new code need a failsafe in case of hang, at least I need that.

Also hw can freeze for external problems like bec going under  a certain voltage for a second.

The important si being aware of limitation, thing that is not pointed anywhere in the wiki.

apm2 is told me to have a better failsafe solution than mux, full ppm sum rerouted directly.

• ▶ Reply

DeveloperPermalink Reply by Doug Weibel on December 9, 2011 at 5:22pm

Well, we may be hijacking Mike's thread, but here goes...

APM2 will not necessarily have a better failsafe solution than the mux.  Full ppm rerouted directly doesn't really mean anything as servos work on pwm, not ppm.  ArduPlane manual mode is a direct routing of the RC input as decoded by the 2560 firmware from the ppm stream and converted to pwm for use by the servos.  There will be no difference in the routing of rc info in manual mode between APM1 and APM2 hardware at all.  The considerations with respect to this failsafe functionality are these:

1)  If the main firmware hangs, then nothing except a hardware mux will allow you to take control from the RC transmitter.  Any passthrough will not work if the code is hung.  In this respect APM1 will have an advantage.

2)  As you are well aware and concerned about - APM1's mux is only 4 channels

3)  The dev team intends to implement an interrupt watchdog to get the main firmware "unstuck" if it hangs and simplify the main loop structure so that the potential of hanging while in manual mode is minimized.  The idea is that if some functionality is causing the code to hang, the watchdog will cause a reboot and in-air restart.  The AP will boot into manual mode and/or the user will "hopefully" have an opportunity to switch in to manual mode where the potential for the code to hang again is minimized.

4) This watchdog code has not been implemented yet.  There are some conflicts with the boot loader which are being worked out.

5) Quite possibly the watchdog implementation will work for both APM1 and APM2

While a hardware mux is a nice safety feature, I do not feel it is mandatory.  A majority of the DIYDrones community is now working with quads and heli's.  The hardware mux is of no use to those users at all.  There is a strong tendency of users in this community to always fly with the latest bleeding edge code on the trunk, with no assurance that a particular build is flyable at all.  We are now maintaining a separate "stable" trunk, from which the  APMPlanner .hex files are built.  We are trying to be a lot more careful with what gets committed to that branch without flight testing so users can use code near the newest development code, but without as much risk.

For those, such as myself, who do actually fly the trunk development code, it is a personal decision if a hardware mux is necessary.  I test a lot of features and functionality where I am not using the RC transmitter, so I don't put a lot of reliance on the hardware mux.  I also use appropriate airframes for testing.  If my SkyWalker decides to spin in to the lake - well that is a risk I am OK with...

This is not at all to say that an individual should or should not use a hardware mux.  It is a simple matter to add one to your system.  If you are flying APM1 and want that functionality for all channels, add an external mux for channels 5-7.  If you are flying APM2 and want that functionality, add one or two.  If I had an expensive airframe that I would be flying with ArduPlane, I might use one myself.

Finally, as far as the wiki...  There are mistakes and omissions in the wiki.  We are continually (and perpetually) looking for people interested in working on the documentation.  I work on this project for fun.  It is not a job and I don't get anything out of it except enjoyment.  I don't enjoy working on documentation, so although I know there are deficiencies there that is not something I work much to correct.  If you are interested I would be very happy to make the proper introductions.

• ▶ Reply

Permalink Reply by Frank on December 9, 2011 at 10:39pm

Hi Doug, I would be happy to participate, I have ton of code for apm some very good some very bad :) same for wiki, I find errors all over and wish to correct them but I can't. PRobably is too late because I found majot of the errors when still in the learning process, actually I know more than the wiki say so I almost never read it anymore, except for new things.

When I Said "is the 3rd time I say that" it was because a simple search would find my replies and solve the problem, it was not a blame on the wiki.

ppm is a thing I would love to discuss but I have to study the apm2 hw, apm1 only solution is swap 2nd ail and throttle to minimize effects. apm2 I don't know but maybe it can work by cutting the ppmsum on rx so the ppm chip do everything and it apm hangs it just forward ppmsum from input to output. At least I was hoping it work this way. if is not working this way I can't imagine how the hw is routed, should take a look.

I have a quad too, for a quad I would love to have a simple gyro stab mode in a separate chip, atmega 328 has plenty of power to do that, one day or the other I will code the atmega ppm and route it to the apm i2c network so I can do all the things we discussed here for planes (ppmsum cutted by ppm chip, servo in and out exchanged by i2c)

he can also read gyros to stabilize an hanged quad. Think about it,just a couple of connections and some easy coding. Just to lazy and working on my ground interface.

I'm personally trying to keep my personal record on crash, its something I'm proud of :)

• ▶ Reply