Test Log on UDBx, HW, SW Scenaios. Limitations and Issues

[Daniel]

Greetings.
The other day, I was at the flying field at our Club and was intending to do a maiden and flights on a prototype fyingwing (front rudder and rear fins) when I encountered periodic glitching of the controls and OSD lock loss during ground testing. So this made me abort the maiden flights (CG, trims, mix, power, basic stability, landing & stall recovery, and maneuvers capability, S and W modes) planned for the day and go back to more backyard testing and fine tuning, and here the results. Note that permutations scope was limited by  available.time.

TEST LOG # 003  General Scope 1.       2 boards with HW Components: SparkFun (SF) UDB3,  DiyDrone (DD) Mediatek GPS, SF/DD XBee Pro, SF 3-axial Magnetometer (3.3v), DD PPM board and SF Cur/Voltage 90A sensor 2.       SW :  MxPilot1189PUDB3v11 –rev 1189 and Mavlink 0.9 Py generated, stabilization, controls and magnetometer fix patches applied, and all peripheral and sensor components with untouched factory firmware		Date : 5/11/12, 11am – 06pm Objectives: 1.       Test for compile, functions,  robustness and consistency-reliability 2.       Resolve board re-cycling, and GPS intermittent on off lock (suspect – due to memory issue?) experienced at the flying field 3.       Check Serial XBee connection (Mavlink and UDB Extra modes) 4.       Test magnetometer workings 5.       Fine-tune control switches orientation, dampening and boost control parameters 6.       From UDB3 switch to setup UDB4 and test features under diff. scenarios
#	Settings, scope and scenario details	Result	Comment
1	1.       UDB3 brd. 3, then brd. 1 2.       SW: Serial output set to Mavlink (0.9 python generated),  OSD on (custom layout), Mag_yaw_drift  on (1), 2 analog channels on in addition to 5 ins and 4 outs	1.       Compiles successfully (program memory at 94%, data at 79%) 2.       GPS failed to lock on satellites 3.       Board resets or recycles every min. or so, refreshing the OSD, causing the servo controls to glitch consistent across 2 boards and GPSs. 4.       No ops to test magnetomet0er, switches and modes or fine tune by eye ball control parms (dampening and boost)	Initially suspected HW related issues, tried board 1 and different MTK GPS unit,  also recompiled the SW with same setting but w vanilla CC i.e., w/out patches and updates, 6 repeated tests, all same results
2	HW brd. 1 magnetometer disconnected and SW firmware setup changed to Mag yaw disabled (0); and rest of SW components and settings same as above (notably serial output set with Mavlink)	1.       Compiles with 86% on program memory and 74% on data 2.       GPS locks (took 12 or so min cold start, 1  min warm start thru button resets,   3.       OSD works well , except LOS speed issue, 80km/hr. offset while stationary 4.       Switches adj.: 1 back, 2 forward, 3 forward 5.       Controls parms adjusted lowered as excessive for FlyWing type control proportions and angles 6.       Can’t get the XBee Serial link to handshake.	Note that with rev1479, magnetometer disabled and serial output set to udb extra, compile was successful at 92% on program and 55% on data.
3	HW Brd. 3 Ssc 1, firmware loaded with magnetometer reconnected and SW Mag yaw enabled, serial output set to serial udb extra, all other settings remain unchanged. Intent:  try QGCS instead of HKGCS.   Ssc 2, serial output set to serial_ udb, everything else is same.   Ssc 3, serial output set to serial_none, everything else is same..	Ssc 1. Compile failed with "could not allocate program memory”     Ssc 2. Compile failed with "could not allocate program memory” Ssc 3. Compile ok,  servos started to cycle and glitch, no GPS lock even after 15 min. of wait per reset, with 3 resets, serial link doesn’t handshake.	Ssc 3 has same indications as #1, i.e., with combo of Mavlink and all (Mag Yaw, OSD, PPM and 2 analogs) on. Also tried Ssc1 using rev1479 just to discount SW differences and compile error was same.
4	UDB4 Ground testing scope:  OSD, magnetometer,  (Mavlink & UDB Extra) XBee serial link and functions, 2 cur./voltage sensors (possible?),  PPM board (with and without for any latency issue)		Ran out time

I have some analysis and wish lists coming from the results of the limited test which I'd rather hold off for now (pending a maiden) and just stir some exchange of thoughts at this point. 

For starters, some quick observations IMHO:  that combo of the magnetometer feature and SERIAL_UDB_EXTRA is one of the program memory killer for the UDB3 board and Mavlink may compile but will cause recycling pattern and glitching of controls.

Test log on UDB4 to follow. Hope this helps.

Kindest regards.
Daniel

[Daniel]

Greetings.

Further to the test logs below, I felt that it's time for the rubber to hit road and prep 3 characteristically different airplanes for flight testing:

   1. a Raven (40" WS mid wing 3D airplane made by Scorpio, Italy) with UDB3 vanilla, except now (just got one) with an Open Log;

   2. an EagleWing (HK, high wing push prop airplane) with UDB3, PPM encoder,  native OSD wired to a 910 Mhz  high res. vid. cam. TX
       system (HK) with a passive low pass filter attached to a cloverleaf antenna, and open log;

   3. a Wing prototype (GuardianOne. 74" flying wing with rudders) with UDB4, native OSD wired to 910 Mhz. high res. vid. cam with passive
      low pass filter attached to a cloverleaf antenna, 900 Mhz XBee pro (on board) and magnetometer.

With a weather break late last week (wind gusts of 15 to 20 km), I was able to do  initial trimming and S & W modes test flights, and I must say,
this system performed well beyond my expectations. 

Again, my profound thanks and gratitude to you all for all the genius and efforts that has gone into this excellent system.

Test results in a nut shell (MxPilot rev. 1510):

   Manual mode triming flights:
       Raven as usual, behaved predictably and superbly stable with little trims required throughout the regiment of basic flight and aerobatic patterns
       EagleWing pitched down almost uncontrollably under throttle and requires sensitive throttle management from takoff (upside can ROG) & throughout
             the regiment of basic flight patterns, ironically too stable and lots of effort and prep. (pitch down) to do basic inverted, roll and loop patterns
       GuardianOne, ran out of time for initial trim flight.

   Stabilized mode flights:
       Raven was so unshakably stable and leveled nailed at an altitude that I did transmitter hands-offs at the long legs of a rectangular pattern of my test
              plan and it flew like it was on rails... even did a hover and it stuck like glued to a point in the sky while slowly toque rolling..  simply amazing!
       EagleWing behaving like a wild buck and is a handful to fly in manual mode, was suddenly tamed and very predictable... like a Dr. Jekyll and Mr. Hyde
             dual personality plane...
       GuardianOne, ran out of time... and getting too windy and dark.

  WayPoint mode flights:
       Raven flew a basic rectangular counter clock wise way point pattern very consistently and accurately... even as the wind picked up some gusts..simply amazing!
            Also tried auto take off, which was fairly good, however, to my liking was too quick and throttled-up too fast:
       EagleWing's flight was stopped as it was getting way too dark.
 
  Quick questions:
     Is there a way to how to smooth out throttling up during auto takeoffs? 
     Given some memory limitations of UDB3, is there a way to enable the magnetometer (mag_yaw..) while serial output is set on UDB_EXTRA...?

More test results to come with details, video and flight log file attachments... 

All the best.
Daniel

[datapolo]

Hi Daniel,
interesting results. I had intended to buy an Eaglewing some time ago but was put off by the very poor reviews on RCG which put its problems down to the poor selection of the wing cross section. I wonder if that accounts for your issues although I note that Nick Arsov has the Eaglewing as his favourite plane! I have just bought a Sirius which is supposed to be the replacement for the Eaglewing and will hopefully be testing that this week.

Cheers,
Mike

[William Premerlani]

Hi Daniel,

Thank you so much for sharing your observations, it is very motivating to the developers.

Regarding running out of program memory, there is some good news. You can get a reduction of about 20% in program memory size by using the compiler optimization. This was discussed in a previous thread.

In the meantime, I checked stack usage with the optimization, and found that it went down as well. So, all around, the optimization is a good deal.

Attached is a view of the window in which you set optimization by clicking on a point on the optimization curve. I suggest the -s option:

Best regards,

Bill

[Daniel]

Hi Bill.
Thanks very much for the recommendations and taking the time.  Sorry also for the late reply however I've trying the optimization on a couple of scenarios and program revisions. Here  are some additional observations.

UDB3,  "s", "2" and down to "1" optimization results:

 -  Common settings:
          HW -- UDB3, Openlog (w/ 8GB Fat32 micro SD type 10), Video TX/ Video (native OSD) breakout board. PPM encoder, M'Tek GPS
          SW -- MPLAB IDE Ver. 8.76.00, MatrixPilot release/revisions: 3.2.1, 1479, 1510,  1535 and 1538 option.h parameters incl.  OSD on, 
                                  SERIAL  ~_UDB or ~_UDB_EXTRA
               
 -  program memory size is significantly reduced as indicated, however
 -  compile comes up with several warnings consistent with revisions 1479, 1510,  1535 and 1538:

~~
Make: The target "E:\APDev\MxPilot1479UDB3_Ravn_v12\MatrixPilot\build\udb\radioIn_udb.o" is out of date.
Executing: "C:\Program Files (x86)\Microchip\mplabc30\v3.30\bin\pic30-gcc.exe" -mcpu=30F4011 -x c -c   "..\libUDB\radioIn_udb.c" -o"build/udb\radioIn_udb.o" -I"." -g -Wall -O1 -legacy-libc
..\libUDB\radioIn_udb.c: In function '_IC7Interrupt':
..\libUDB\radioIn_udb.c:119: warning: 'time' may be used uninitialized in this function
..\libUDB\radioIn_udb.c: In function '_IC8Interrupt':
..\libUDB\radioIn_udb.c:162: warning: 'time' may be used uninitialized in this function
..\libUDB\radioIn_udb.c: In function '_IC2Interrupt':
..\libUDB\radioIn_udb.c:205: warning: 'time' may be used uninitialized in this function
..\libUDB\radioIn_udb.c: In function '_IC1Interrupt':
..\libUDB\radioIn_udb.c:248: warning: 'time' may be used uninitialized in this function
Make: The target "E:\APDev\MxPilot1479UDB3_Ravn_v12\MatrixPilot\build\udb\serialIO_udb.o" is out of date.
Executing: "C:\Program Files (x86)\Microchip\mplabc30\v3.30\bin\pic30-gcc.exe" -mcpu=30F4011 -x c -c   "..\libUDB\serialIO_udb.c" -o"build/udb\serialIO_udb.o" -I"." -g -Wall -O1 -legacy-libc
Make: The target "E:\APDev\MxPilot1479UDB3_Ravn_v12\MatrixPilot\build\udb\servoOut.o" is out of date.
~~
And release 3.2.1
Make: The target "E:\APDev\MxPilot3210UDB3_Eglw_v11\MatrixPilot\build\udb\radioIn_udb.o" is out of date.
Executing: "C:\Program Files (x86)\Microchip\mplabc30\v3.30\bin\pic30-gcc.exe" -mcpu=30F4011 -x c -c   "..\libUDB\radioIn_udb.c" -o"build/udb\radioIn_udb.o" -I"." -g -Wall -Os -legacy-libc
..\libUDB\radioIn_udb.c: In function '_IC1Interrupt':
..\libUDB\radioIn_udb.c:342: warning: 'time' may be used uninitialized in this function
Make: The target "E:\APDev\MxPilot3210UDB3_Eglw_v11\MatrixPilot\build\udb\serialIO_udb.o" is out of date.

  -  during ground testing, the board doesn't lock on any satellite even under prolonged wait, 
     also common,  the board  re-cycles itself  every 1-2 min. interval causing the servos to glitch

  -  turning off the optimization ("0" optimization) lends release 3.2.1 and revision 1479 to work just fine during ground testing with
             exception of  revisions 1510,  1535 and 1538 (won't lock on any satellites).

Also manage to do more flight tests with attached log files using revisions 1538 and 1510, and SERIAL_UDB and SERIAL_UDB_EXTRA.
The flight itself is beautifully great under S and W modes.  However when I ran the open log txt through flight analyzer I consistently get the
attached errors.

So Bill, a couple of followup questions:

  -  What am I missing with getting my open log to work with flight analyzer (...followed the steps in the readme file)?
  -  Up to which latest revisions are recommended  with UDB3 under above common settings?
  -  What revisions are recommended to work well with UDB4 under above common settings, except, without OpenLog
      and instead, with XBee (on board and laptop) and with QgroundControl?

[Daniel]

Ooops.. sorry wrong 2nd log..txt file.. pls. consider instead:

[William Premerlani]

Hi Daniel,

I am not worried about the warnings, but I am concerned about about your report that the board rebooted with the compiler optimization options turned on.  So, until one of the developers can look into it, its best not to use the optimization.

Regarding the log files and the flight analyzer, I refer you to Peter.

Best regards,

Bill

[Daniel]

Just a quick thank you Bill and am looking forward t Peter's inputs or leads.
All the best.
Daniel

[Daniel]

Greetings.

Had a chance to do a couple of test flights like this one uploaded video, with my Raven 3D airplane, a windy, gusty day last week. 

Happy to say that the  settings held its ground (attached option file), even manged to do a bit of hover in spite of the very gusty winds.  Good stress and accuracy test with very good results.

Next planned test flights will involve a bit of basic aerobatics and hovers between waypoints and might even try some auto take off and landings.. By this time, I'm looking forward to getting my open log working with Kempo's config.txt file (many thanks, Kempo for sharing :o). 

Just a quick one, for my planned auto land, I have in my waypoint (attached):
~~                                       { { -28, 105, 37 } , F_NORMAL , CAM_VIEW_LAUNCH } , //Waypoint 1
                                        { { 45, 131, 27 } , F_NORMAL , CAM_VIEW_LAUNCH } , //Waypoint 2
                                        { { 84, 98, 20 } , F_NORMAL , CAM_VIEW_LAUNCH } , //Waypoint 3
                                        { { 68, 68, 12 } , F_NORMAL , CAM_VIEW_LAUNCH } , //Waypoint 4
                                        { { 39, 39, 5 } , F_NORMAL + F_LAND , CAM_VIEW_LAUNCH } , //Waypoint 5
                                        { { 15, 17, 1 } , F_NORMAL + F_LAND , CAM_VIEW_LAUNCH } , //Waypoint 6
                                        { { 0, 0, 0 } , F_NORMAL + F_LAND , CAM_VIEW_LAUNCH } , //Waypoint 7
                                        }
;
Will this waypoint scriipt translate into a soft landing (soft enough for my landing wheels)?  Also, is it possible to do rolls, loops and knife edge in waypoints (or even flightplan-logo)?
As always any suggestion is more than welcome and will be most appreciated.
All the best.
Daniel

[Daniel]

Greetings.
Managed to do more test flights.  Happy to say the results have been very good. 
This a test flight of an EagleWing  with a UDB3,  MxPilot rev. 1570, and w/ an
attempt to run a simple Logo flightplan.

Note however, that:
1.  the speed seem to have jumped from a realistic 50km/hr to 200-600km/hr range,
2.  switching to WP mode (Logo) tend to veer the plane away to some other direction
3.  the arrow to goal seem to be pointing at the wrong direction (NW off the fix point
     of origin)..

Begs the question of any miscalculation on the speed indicator (native OSD setup
air and ground speed).. Any thoughts?

Will do try to do more test flights with the latest revisions..

All the best.
Daniel

[Peter Hollands]

Hi Daniel,

I am not a user of the OSD, but Comparing   with Ric's video .....

Your artificial Horizon is not as accurate, and your speeds are non-sensical. They are just not true.

What GPS are you using ? Do you see those speeds in the telemetry ? (Do you have SERIAL_UDB_EXTRA from that flight ?).


Best wishes, Pete

--

[Daniel]

Hi Pete.
Sorry for the very late reply, and thanks for the feedback, ..been very busy with other projects.

Got some time yesterday to fly 2 planes, w/c however, sadly resulted in one disastrous crash (warning: the video contains graphic
scene of the crash at the last part ;o)  and some weirdest waypoint behaviors. 

The 2 airplanes', Eaglewing FPV and Raven 3D configuration basically included:

1.  EagleWing FPV (from HK) HW/SW:

    -  Radio TX/RX:  DX8 /AR8000 RX w/ satellite and TX w/ antenna amplified, all servos are super fast, high torque mini mg digital servos.
    -  UDB3 (SF) with MTEK GPS (DIYDrones), OSD breakout board (SF), PPM encoder (DIYDrones) and Openlog (SF)
    -  Basic SW setup: Options - MatrixPilot rev. 1479, OSD on, wind_gain_adjustment on, all stabilization options on, all navigation on,
               output format serial_udb_extra, altitude stabilized pitch only and altitude waypoint full (see attachment for further details)
               and waypoint fixed location on - dead center of the flying field .
    -  OSD/FPV: 900 Mhz 800 mw TX/RX (HK) with 520 TVL cam (HK) hooked up to the OSD breakout board (DIYDrones)

2.  Raven 3D:

    -  Radio TX/RX:  "Yellow RX 9c" (HK clone) w/ satellite and TX w/ antenna amplified, all servos are fast, high torque, mg digital servos.
    -  UDB3 (SF) with MTEK GPS (DIYDrones) and Openlog (SF)
    -  Basic SW setup: Options - MatrixPilot rev. 1479, wind_gain_adjustment on, all stabilization options on, all navigation on,
               output format serial_udb_extra, altitude stabilized pitch only and altitude waypoint full (see attachment for further details)
               and waypoint fixed location on - (absolute coords) dead center of the flying field ..
    -  OSD/FPV: none

Pre flight and Post flight for both plane (routine for me) checked:

   -  mechanical:  linkages, hinges, servos, controls, prop tightness, structural and wing stability and alignments
   -  electronic: connections and wiring, and battery voltage
   -  ground testing:  orientation of control surface travels, under manual and stabilized modes

Some observations:

1.  EagleWing
   -  Complile: 93% program memory used, wind gain on (this time) to compensate for wind gusts of 20+ km/hr
   -  Ground start:  satellite GPS hookup within 15 seconds,  the aileron servos glitches slightly about every 5 secs
          orientation of control surface travel during stab mode checked ok
   -  During flight:
        -  manual mode: EagleWing needs some serious re-design and thrust line is well above the center mass/gravity
              and tends to buck-pitch down every time throttle up (even with a 17% throttle elev. mix on the radio).
        -  under stabilized mode, still tends to pitch down (characteristic of an EagleWing) when throttling up
        -  under waypoint mode, was off track from the plan most of the time, even did an unplanned roll (midway of the
              video),  except in for one leg, tends to fly either way off the planned waypoints (pls. see attachments)
    -  Post crash:
        - did a thorough look at all electronic connections and mechanical configs and verified okay
        -  Flight analyzer when run with the open log file displayed a notice on board recycles (per above pic)

2.  Raven
   -  Previous fight was flawless (wind gain was off, otherwise setup all same..) and right on the nose of the planned waypoint
   -  Complile: 82% program memory used, wind gain on (this time) to compensate for wind gusts of 20+ km/hr
   -  Ground start:  satellite GPS hookup within 10 seconds, and orientation of all control surface travels during stab
            mode checked ok
   -  During flight:
        -  under stabilized mode behaves as expected
        -  under waypoint mode, except in for a couple of legs, tends to fly either way off the planned waypoints (pls.
           see attachments), also did some flip over during waypoint..

I'm at a loss on what may have caused the the EagleWing to  uncontrollably dive (even my thumb was hard pressed
on the right stick trying to pull up..) and crash as I was on an approach to land.

And would certainly appreciate any feed back and thoughts on lessons learned, so same can be prevented from
further occurring.

Kindest regards.
Daniel

[Daniel]

Ooops almost forgot, the kmz files:

[Daniel]

Greetings.

In hindsight, I should have done a bit more due diligence a few days ago, when the same EagleWing (identical setup) went into
a dive almost at the same spot, just short of a few meters, and crashed into the boundary trees (tall thorn bushes actually..). 

Fortunately, the trees cushioned the impact and spare the plane from any serious damage.  Not yesterday, sadly, ...only 2 lives!

However, just now, looking at the log's (attached) flight track and elevation profile (this tool BTW is great! You guys have done
a wonderful job!) of the path, I should have recognized that there is some critical flaw in the way I may have pushed the UDB3
over its limit (enabling OSD, serial_udb_extra, PPM encoder, etc.,  vis-a-vis its SW and HW limits, just my SWAG at it).

Apparently too far, that the waypoints, IMU and gps data are being interpreted into twilight zone... Like how does one explain
the log showing flight over 1.5 km away (way over line of sight) or the plane flying 140 plus meters UNDER GROUND!

I've kicked the UDB3 can somewhat and will share in the next post my 10 cents and some empirical observations, that
hopefully can be of value.

All the best.
Daniel

[Peter Hollands]

Hi Daniel,

If you could send me the raw LOG.TXT file, the options.h and the waypoints.h, to my email address, I'll spend some time analysing them for you, and see if I can notice anything of interest which may have caused the crash.

Best wishes, Pete

--