UDB3 test - 5 flights

[Peter S]

Hi all,

Today I flew UDB3 for 5 flights. The first two flights were not
successful as some of the servo reversing are not correct. So the
plane would dive after turning on Automatic mode. So the third
flight, servos are working correctly. I flew the T3-2 flight plan
(the one given in waypoints.h) and I noticed that the plane would fly
like an aerobatic plan that means it would loop and roll around and
somehow I think altitude hold may not work correctly.

From the reading in HK GCS, the plane should fly 25m above but in
fact, it flew about 3m above the airfield. So I'm not sure if it's my
setup (hopefully this is the case). Then I tried to change the
waypoint to be rectangle and tried again on the fourth flight however
there were some height problem so I took the plane down. The fifth
flight was halted due to airframe problem, the plane could not gain
altitude.

In summary,

My setup, UDB3 + EM406GPS + XBee 2.4 Pro with MatrixNav 3.2.1

1st/2nd flight - wrong servo reversing setup
3rd flight - T3-2 waypoints but it flew strangely, it would fly up
really high and loop around, and the plane would drop the height to
almost hit the runway.
4th flight - simple rectangle waypoints - but notice altitude hold
problem.
5th flight - the plane could not gain altitude and it's getting dark..

The plane (AXN Cloudfly) is still intact, it did not crash at all. I
can send you all my options.h, waypoints.h, and all the flight plans
(I already use fplan.py to generate both CSV and KMZ files).. Please
help.

Best regards,

Peter

[William Premerlani]

Hi Peter,

If you have not already read it, I suggest you read these tips on setting up altitude hold.

If you would send us your options.h file, your waypoints.h file, and your log.txt file, I would be happy to take a look at your data. Best thing to do is send them as attachments.

Best regards,

Bill Premerlani

[Peter S]

Hi Bill,

I already sent you the files. I don't have altitude hold problem in
red board. This is the first time I flew UDB3 before going to UDB4.
I have 4 new UDB4 waiting to be tested. Please advice.

Best regards,

Peter

On Dec 19, 4:52 am, William Premerlani <wpremerl...@gmail.com> wrote:
> Hi Peter,
>
> If you have not already read it, I suggest you read these tips on setting

> up altitude hold<http://gentlenav.googlecode.com/files/AltitudeHoldSetup.pdf>

[Peter Hollands]

Hi Peter S, if you could reply by email to this thread on uavdevboard and attach you files, then more of us could help.

I do not see the files in this thread. It is super that you have telemetry.  That makes diagnosis much easier.

Best wishes Pete

[Peter Hollands]

Peter S, I see now that you started another discussion thread with photos and log files. Best wishes Pete

[Peter S]

Hello Pete,

Based on Bill's advice, actually I swapped the Aileron and Elevator
channel, so the plane flew quite like it's in an aerobatic show. So
now stabilization works fine. I will test the plane again this week
and will update. In the meantime, I just finish UDB4 soldering. So
it's next. Thank you for Bill's and your help.

Best regards,

Peter

On Dec 20, 2:59 am, Peter Hollands <peter.holla...@gmail.com> wrote:
> Peter S, I see now that you started another discussion thread with photos
> and log files. Best wishes Pete

> On Dec 19, 2011 7:46 PM, "Peter Hollands" <peter.holla...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Hi Peter S, if you could reply by email to this thread on uavdevboard and
> > attach you files, then more of us could help.
>
> > I do not see the files in this thread. It is super that you have
> > telemetry.  That makes diagnosis much easier.
>
> > Best wishes Pete

[nickarsow]

Hi Peter,
As you're flying CloudsFly, could you please post your config.h file here?
Best regards
Nick

[William Premerlani]

Hi Nick,

The config.h file does not depend on board orientation. Board orientation is handled separately in the boardRotations_defines.h file. We have "factored" the problem into configuration times orientation.

The config.h file describes the board. We have a different config.h file for each type of board. (There will be one for your board.)

The user specifies board type and orientation in the options.h file.

In Peter's case, he is using backwards orientation.

Best regards,

Bill

[nickarsow]

Hi Bill,
Thanks for the explanation. I did mean something different....as our group like to fly the same plane, I asked the config file to see what the other Peter's settings are .... like gains...etc.
Best regards
Nick

[William Premerlani]

Hi Nick,

I understand. Then you want to see Peter's options.h file.

Best regards,

Bill

[Peter S]

Hi Nick, Bill,

I use the typical (default) gains in options.h file. However, today I
lost UDB3 along with the Cloudfly. I guess it's because Corona
receiver. I read from telemetry information that it changed to manual
mode by itself. All the inputs are in the middle (Aileron, Elevator,
Throttle, Rudder, Mode). So it went on free flight mode (without my
control). I'll build another Cloudfly airframe and put in UDB4 for
testing.

Merry Christmas to you all.

Best regards,

Peter

[J. Roby]

Bill, I'm very impressed with the UDB project it’s enabled me to realize what I could only dreamed of. Thank you for your hard work. I've been flying the UDB3 software v.2.5 for 2011 and logged over 50 hours of flight. I upgraded to v3.5_1 because my RX does not have the failsafe. Under v2.5 in (stabilize mode) would see the hard banking and motor cut off during loss of TX-RX link from multipath interference. For the upgrade I used the constants from the older waypoint.h and options.h such as gains and damping constants, but with new feature FAIL_SAFE_Hold enabled.   Differences: On power up (with TXMR throttle at minimum) the ESC started beeping wanting to go into program mode, it timed out after a few minutes, so no problem.  This indicated the throttle signal may not be at minimum from UDB to the ESC, restarted under different modes: Manual, Stabilized same results.   Preflight: tested all control surfaces in manual and stabilized, worked as expected. The RTL mode worked correctly, the engine enabled as programmed (remove F_land in waypoint.h).   When flying the plane in stabilized mode it appeared very jerky and unstable for the wind conditions. After ten minutes of flying level, I trimmed up the elevator, flight became unstable, pitched up and rolled. I switched to RTL mode the plane went into a full power nose dive. Looking for clues: possible mechanical failure, all servos appear to be fine, all electronic connection look ok. I'm reverting back to v2.5 Is it possible the software orientation switched so level flight in now straight down?   Jeff   --- On Sat, 12/24/11, Peter S <note...@gmail.com> wrote:

[metrot...@yahoo.com]

Bill,Pete

> > > Nick- Hide quoted text -
>
> - Show quoted text -

[William Premerlani]

Hi Jeff,

You did not say how the story ended. I am hoping that you were able to land your plane safely. If not, you have my sympathies.

To answer your question about orientation, it is not possible for the software to switch orientation in flight.

It sounds like there might be several things going on, I am going to try to help you explore just two of them.

First, could you tell us a bit more about your Rx failsafe? What does your Rx do if the signal is lost? Keep in mind that the new feature FAILSAFE_HOLD will keep the flight mode as RTL until you reset the failsafe by changing the flight mode. So, if your Rx was having trouble, once the control went into RTL mode, it would stay there until you selected a different flight mode. It does not sound from your description that this is what happened, but keep it in mind.

Did you change anything else in your system besides the version of MatrixPilot?

For next steps, I agree with you, it would be useful to switch back to v2.5. If that works ok, then it would be useful if you sent me the options.h file (as an attachment), that you used with v3.5.

Best regards,

Bill Premerlani

[J. Roby]

--- On Wed, 12/28/11, William Premerlani <wprem...@gmail.com> wrote: Hi Bill, The plane ran out of lives, the V.2.5 RTL function has saved it several times. That's why I have a backup plane.   The UDB3 survived but not sure the Gyros and Accelerometer can be trusted, do you think the self test program could pick up damage like larger offset and excessive drift? The shock rating for the gyro is 10000g, accelerometer data sheet doen't say. It impacted nose first on sand, the batteries took most of the impact.   As far as the crash flight : Beginning flight tested mode selection: stabilized, waypoint and RTL appeared to work. before the crash: TX-RX link was solid, no packet losses,stabilized mode, just FPV'n around. Problems started when I trimmed the elevator, then out of control, in the past, using V2.5 if in trouble I would switch to RTL to recover, so I switched to RTL but this time it rolled and dived. If I can recover the video file I'll send it to you. It all happened in ten seconds or less. I made no changes, except the V2.5 to V3.21 upgrade. The RX is a Corona 8 channel PPM and does not have a failsafe. Setting up for V2.5 (same setting for 3.21) I used an O-scope I measured the response of the RX PPM channel outputs when the TX is off (each channel goes to 3000), set the auto detect RTL to the (Mode select) Channel 6 and high and low thresholds around 3000. When the link is lost all RX outputs go to this minimum pulse width of 3000. I set the Mode switch (pot) on the TX as follows: RTL (for min RX PWM width) ,manual ,stabilized,waypoint (max width). Under V2.5 the TX-RX link is loss the plane should slip into the auto RTL until the link has reestablished, not sure I've seen this.   How do you detect the TX-RX link loss in V3.21?   About v2.5 RTL under Loss of signal:  From past flights, v2.5, I noticed (recorded video) that when the TX-RX link drops from multipath, the plane motor cuts off and turns (rolls) hard in one direction. I've tested this on the ground by cutting off the TX and could not duplicate this (it actual would turn to RTL because the motor go to the preset value, if the throttle is not minimum, the ailerons stay level). What is going on in flight, not 100% sure, Mode goes to minium, switch into RTL mode but the Throttle is minium so the motor goes off, becuase it thinks the TX has minium throttle. For the aileron servos (on Y cable) both go to minimum position because they are mechanical reversed, one aileron goes up and the other goes down, hence the roll I see on video. Should not use a aileron Y cable, but use two channels, one for each servo, have not implement this. (one change at a time,several flights to check it) or non mechanical reversed servos.   To get advanced warning of doom, I installed a wire from the Packet Loss LED on the RX board to a Low Pass Filter (10K-10uf) to integrate up the Sync Losses (LED blinks when a packet is lost) creating a voltage related to packet losses (see rcexplorer.se see DIY projects, lost packet indicator) and report this level via the OSD. (could be done using a PWM input without the analog RC integrator). This gives me a 2 second warning that the link is going bad and can turn around to restore it.   I hope I answered your questions. Again, Thank for your hard work and the excellent team creating this incredible device. Best regards, Jeff

[Robert Dickenson]

G'day Jeff,

I notice you have set RTL_PITCH_DOWN to a non-zero value. You may like to note that the default code contains 0.0, as per the comment. As this snippet from your options.h appears to fit the problem description, I just thought I'd mention it..

Kind regards, Robert.


////////////////////////////////////////////////////////////////////////////////
// Return To Launch Pitch Down in degrees, a real number.
// this is the real angle in degrees that the nose of the plane will pitch downward during a return to launch.
// it is used to increase speed (and wind penetration) during a return to launch.
// set it to zero if you do not want to use this feature.
// This only takes effect when entering RTL mode, which only happens when the plane loses the transmitter signal.
#define RTL_PITCH_DOWN                        2.0  //JLR was 0.0

[J. Roby]

Hi Robert, Yes, 2 degrees pitch down to counter any wind effects. Best Regards,  Jeff --- On Thu, 12/29/11, Robert Dickenson <robert.d...@gmail.com> wrote:

[William Premerlani]

Hi Jeff,

See my comments below. Also, from your options.h file, and your comments, I note the following:

1. With your setup, when you turn off your Tx, MatrixPilot will go into stabilized mode, not fail-safe mode.

2. It appears that you command fail-safe mode by setting your mode pot to its lowest setting.

3. With your setup, (FAIL_SAFE_HOLD 1) if you go from manual mode to fail-safe mode and back again by moving the mode pot, the control will be stuck in fail-safe mode until you go to stabilized mode or waypoint mode.

4. You have selected NONE for altitude hold in stabilized mode.

Let me know if you agree and if this was your intent.

Best regards,

Bill

On Thu, Dec 29, 2011 at 12:51 AM, J. Roby <metrot...@yahoo.com> wrote:

--- On Wed, 12/28/11, William Premerlani <wprem...@gmail.com> wrote: Hi Bill, The plane ran out of lives, the V.2.5 RTL function has saved it several times. That's why I have a backup plane.   The UDB3 survived but not sure the Gyros and Accelerometer can be trusted, do you think the self test program could pick up damage like larger offset and excessive drift? The shock rating for the gyro is 10000g, accelerometer data sheet doen't say. It impacted nose first on sand, the batteries took most of the impact.

Try running the roll-pitch-yaw demo. If it runs ok, gyros and accelerometers are ok.

 

As far as the crash flight : Beginning flight tested mode selection: stabilized, waypoint and RTL appeared to work. before the crash: TX-RX link was solid, no packet losses,stabilized mode, just FPV'n around. Problems started when I trimmed the elevator, then out of control, in the past, using V2.5 if in trouble I would switch to RTL to recover, so I switched to RTL

I note that you have selected NONE for altitude hold in stabilized mode. This turns off both speed control and altitude control. So, if you do too much elevator up trim, you could stall the plane.

How did you switch to RTL mode? Did you turn the control mode pot to zero? Is there any chance you turned it in the wrong direction and turned it to waypoint mode? Also, are you really using a pot? How can you be sure which of the 4 modes you have selected?

 

but this time it rolled and dived. If I can recover the video file I'll send it to you. It all happened in ten seconds or less. I made no changes, except the V2.5 to V3.21 upgrade.

I have not had time to look at the differences between V2.5 and V3.2....did you have to add anything to the options.h file?

 

The RX is a Corona 8 channel PPM and does not have a failsafe. Setting up for V2.5 (same setting for 3.21) I used an O-scope I measured the response of the RX PPM channel outputs when the TX is off (each channel goes to 3000), set the auto detect RTL to the (Mode select) Channel 6 and high and low

When you say each channel goes to 3000, I assume you mean 3000 in "MP units", which are 1/2 microsecond. So, 3000 is 1.5 milliseconds, which is mid range. In otherwords, neutral rudder, neutral elevator, neutral ailerons, half throttle, and midway on the mode control.

I note that you selected the mode control as the failsafe channel. (That is what I do, too.) I see that you set failsafe limits at 2300 and 4500. So, when you turn off your Tx, the Rx will put out 3000 on the mode control channel, which will put the controls in stabilized mode. Is that what you want?

Otherwise, I note the following ranges of values on the mode control channel, (lets call it M).

M<2300  fail-safe, RTL

2300<M<2600 manual mode

2600<M<3400 stabilized mode

3400<M          waypoint mode

 

thresholds around 3000. When the link is lost all RX outputs go to this minimum pulse width of 3000. I set the Mode switch (pot) on the TX as follows: RTL (for min RX PWM width) ,manual ,stabilized,waypoint (max width). Under V2.5 the TX-RX link is loss the plane should slip into the auto RTL until the link has reestablished, not sure I've seen this.   How do you detect the TX-RX link loss in V3.21?

Its the same for all versions of MatrixPilot. TX-RX link loss is declared from the pulses coming in on the fail safe channel. If the pulses stop coming in, or if the pulse width falls outside of the range specified in your options.h file (2300 to 4500 in your case), a failsafe condition is declared.

 

About v2.5 RTL under Loss of signal:  From past flights, v2.5, I noticed (recorded video) that when the TX-RX link drops from multipath, the plane motor cuts off and turns (rolls) hard in one direction. I've tested this on the ground by cutting off the TX and could not duplicate this (it actual would turn to RTL because the motor go to the preset value, if the throttle is not minimum, the ailerons stay level). What is going on in flight, not 100% sure, Mode goes to minium, switch into RTL mode but the Throttle is minium so the

there was a bug in v2.5 that Ben fixed in newer versions, that caused this glitch.

 

motor goes off, becuase it thinks the TX has minium throttle. For the aileron servos (on Y cable) both go to minimum position because they are mechanical reversed, one aileron goes up and the other goes down, hence the roll I see on video. Should not use a aileron Y cable, but use two channels, one for each servo, have not implement this. (one change at a time,several flights to check it) or non mechanical reversed servos.   To get advanced warning of doom, I installed a wire from the Packet Loss LED on the RX board to a Low Pass Filter (10K-10uf) to integrate up the Sync Losses (LED blinks when a packet is lost) creating a voltage related to packet losses (see rcexplorer.se see DIY projects, lost packet indicator) and report this level via the OSD. (could be done using a PWM input without the analog RC integrator). This gives me a 2 second warning that the link is going bad and can turn around to restore it.   I hope I answered your questions.

yes, you did.

 

Again, Thank for your hard work and the excellent team creating this incredible device.

and, thank you very much, indeed.