UDB4 large controls...

[MIG-29]

Hi,

I use a UDB4 and program it with a PickIt 3.

I use Windows 7 64 bit laptop and MPLAB 8.84 and C compiler version
3.31

Everything works OK with the programming and after initialization
MANUAL mode is OK. However, when I switch to STABILIZATION I get VERY
large controls bot for aileron and elevator directions (I have the
UDB4 installed on a flying wing).

I have the GPS connector in front and to the left- I chose the
appropriate orientation of the board in the options.h

The gains are identical with the gains I previously used with UDB3.

Anyone has any ideas of why this happens with UDB4?

Thanks!

[MIG-29]

To be more precise: I checked STABILIZATION on the ground and for
couple of roll or pitch degrees the elevons go to almost full
deflection.

I have 2 UDB4 boards and both of them behave in the same way which
makes me believe that it is a software/programming problem. Has
anybody encountered this problem before?

Thanks!

[MIG-29]

New update from the shop:

I installed MPLAB 8.83 and the recommended C compiler version (3.31)
on a Windows XP 32 bit machine. I used this machine for UDB 3 before
and it worked every time.

I programmed the UDB4 with Pickit 3.

It worked ok including normal elevon deflection for STABILIZATION
mode.

Reprogrammed the board using identical setup and STABILIZATION does
not work- large and incorrect elevons deflections.

Do I have a defective board?

I have 2 boards and both of them behave the same way!

Thanks!

> > Thanks!- Hide quoted text -
>
> - Show quoted text -

[Peter Hollands]

Hi Florin,

I don't quite understand what you changed betweeen the working UDB4 and the non-working UDB4.

You said:-

It worked ok including normal elevon deflection for STABILIZATION
mode.

Reprogrammed the board using identical setup and STABILIZATION does
not work- large and incorrect elevons deflections.

What did you change between the first paragraph and the second paragraph above ?
(You can see you completel post below).

Best wishes, Pete

--
--

[MIG-29]

Hello Peter,

I did not change anything; the same computer, the same programmer and
the same UDB4 board. I just reprogrammed the board and STABILIZATION
mode didn't work anymore.

The deflections of elevons were in the wrong directions and the amount
of deflection of elevons was very large. Actually just tilting the
wing by few degrees would drive the elevons to maximum deflection.
This is very strange since I bought 2 boards and both of them
exhibited this behaviour.

Thanks.

On Jun 23, 11:50 pm, Peter Hollands <peter.holla...@gmail.com> wrote:
> Hi Florin,
>
> I don't quite understand what you changed betweeen the working UDB4 and the
> non-working UDB4.
>
> You said:-
> It worked ok including normal elevon deflection for STABILIZATION
> mode.
>
> Reprogrammed the board using identical setup and STABILIZATION does
> not work- large and incorrect elevons deflections.
>
> What did you change between the first paragraph and the second paragraph
> above ?
> (You can see you completel post below).
>
> Best wishes, Pete
>

[Robert Dickenson]

Hi Florin,

I too am a little confused by your problem description. Can you please check what you have written and ensure this is what was intended:

> I programmed the UDB4 with Pickit 3. It worked ok including normal elevon deflection for STABILIZATION mode.
>
> Reprogrammed the board using identical setup and STABILIZATION does not work- large and incorrect elevons deflections.
>

I highly doubt this has anything to do with Windows 64/32, or the MPLAB/cc versions.

My first suspicion is that you are not actually programming the matrixpilot image that you think you are. I have managed to mix myself up a few times in the past when juggling multiple project builds, and most often find that coming back to it sometime later, with a fresh point of view, fixes the problems.

If you could please repeat your experiment and post a new decription, that may be the best first approach from here in.

Also, two defective boards is unlikely, especially as they seem to work, just not work quite right, suggesting a build configuration problem. Perhaps an include path issue.

Best wishes, Robert.

--
--

[MIG-29]

Hello,

new update:

I use the same board with the Matrixpilot 3.2.1 on it.

I start it and it works OK.- the magnitudes and the directions of the
elevon deflections are OK.

I turn OFF the power on the plane and reinitialize the board.
This time it does not work OK- the deflections of elevons are OK as
magnitudes but the directions are opposite.

I turn OFF the power on the plane and reinitialize the board.

This time it works OK- both the directions of the deflections of the
elevons and the magnitudes are OK.

So without reprogramming it I obtain various results from restart to
restart.

Best regards.

On Jun 24, 3:03 am, Robert Dickenson <robert.dicken...@gmail.com>
wrote:

> Hi Florin,
>
> I too am a little confused by your problem description. Can you please
> check what you have written and ensure this is what was intended:
>
> > I programmed the UDB4 with Pickit 3. It worked ok including normal elevon
>
> deflection for STABILIZATION mode.
>
> > Reprogrammed the board using identical setup and STABILIZATION does not
>
> work- large and incorrect elevons deflections.
>
>
>
> I highly doubt this has anything to do with Windows 64/32, or the MPLAB/cc
> versions.
>
> My first suspicion is that you are not actually programming the matrixpilot
> image that you think you are. I have managed to mix myself up a few times
> in the past when juggling multiple project builds, and most often find that
> coming back to it sometime later, with a fresh point of view, fixes the
> problems.
>
> If you could please repeat your experiment and post a new decription, that
> may be the best first approach from here in.
>
> Also, two defective boards is unlikely, especially as they seem to work,
> just not work quite right, suggesting a build configuration problem.
> Perhaps an include path issue.
>
> Best wishes, Robert.
>

> > --- Hide quoted text -

[MIG-29]

The reason I tried various computers, OSs is because I wanted to
elliminate the computer/programming environment from the loop- before
turning my attention to the boards.

As I said, without even reprogramming the board I get various results
(sometimes it works OK sometimes it does not work OK) from restart to
restart.
When it does not work OK I either get very very large elevon
deflections or wrong elevon deflection direction.
Next time when I initialize the board - without reprogramming it- it
would work just OK.
I know there were some discussions about gyros not firing up
correctly. I encountered this issue on UDB3. I sent it back and I was
right.

This time it is very strange even for me to claim that both boards do
not work. But this is what it seems to be on the test bench.

I have never flown either of these boards and I will never fly them
until the mystery can be solved.

Best regards

On Jun 24, 9:04 am, MIG-29 <florin.mingirean...@gmail.com> wrote:
> Hello Robert,
>
> I used three different computers. On one of them I freshly installed
> MPLAB, C compiler and the Matrix 3.2.1 version directly from their
> respective websites.
>
> I repeated again the experiment with one of the boards and I get full
> elevon deflections for only couple of degrees tilt of the flying wing.
> Not to say that they are not deflecting in the right direction.
>
> Best regards

>
> On Jun 24, 3:03 am, Robert Dickenson <robert.dicken...@gmail.com>
> wrote:
>
>
>

> > Hi Florin,
>
> > I too am a little confused by your problem description. Can you please
> > check what you have written and ensure this is what was intended:
>
> > > I programmed the UDB4 with Pickit 3. It worked ok including normal elevon
>
> > deflection for STABILIZATION mode.
>
> > > Reprogrammed the board using identical setup and STABILIZATION does not
>
> > work- large and incorrect elevons deflections.
>
> > I highly doubt this has anything to do with Windows 64/32, or the MPLAB/cc
> > versions.
>
> > My first suspicion is that you are not actually programming the matrixpilot
> > image that you think you are. I have managed to mix myself up a few times
> > in the past when juggling multiple project builds, and most often find that
> > coming back to it sometime later, with a fresh point of view, fixes the
> > problems.
>
> > If you could please repeat your experiment and post a new decription, that
> > may be the best first approach from here in.
>
> > Also, two defective boards is unlikely, especially as they seem to work,
> > just not work quite right, suggesting a build configuration problem.
> > Perhaps an include path issue.
>
> > Best wishes, Robert.
>

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

[MIG-29]

Hello Robert,

I used three different computers. On one of them I freshly installed
MPLAB, C compiler and the Matrix 3.2.1 version directly from their
respective websites.

I repeated the experiment with one of the boards and I get full

elevon deflections for only couple of degrees tilt of the flying
wing.
Not to say that they are not deflecting in the right direction.


Best regards

[Marcus Fahlén]

Florin.

Have you tried to verify the written HEX-file?
Maybe you could try a complete erase / write cycle using the HEX-file
writer as is a pert of the PICKIT if you have not done so already.

I had som similar problems with a UDB3 and some times this was a
solution.

Best regards
///Marc

--
--

[MIG-29]

I include below the option file that I use.

But as I said: without reprogramming the board it behaves differently
from a reinitialization to another. This, in my view, pretty much
answers the question: something is going fishy on the board.

// This file is part of MatrixPilot.
//
// http://code.google.com/p/gentlenav/
//
// Copyright 2009-2011 MatrixPilot Team
// See the AUTHORS.TXT file for a list of authors of MatrixPilot.
//
// MatrixPilot is free software: you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published
by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// MatrixPilot is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with MatrixPilot. If not, see <http://www.gnu.org/licenses/
>.


////////////////////////////////////////////////////////////////////////////////
// options.h
// Bill Premerlani's UAV Dev Board
//
// This file includes all of the user-configuration for this firmware,
// with the exception of waypoints, which live in the waypoints.h
file.
//
// Note that there is a small but growing library of preset options.h
files for
// specific planes located in the MatrixPilot/example-options-files
directory.
// You can use one of those files by replacing this file with that
one.


////////////////////////////////////////////////////////////////////////////////
// Set Up Board Type
// GREEN_BOARD - Board is green and includes 2 vertical gyro daugter-
boards.
// RED_BOARD - Board is red, and includes 2 vertical gyro daugter-
boards.
// UDB3_BOARD - Board is red, and includes a single, flat, multi-gyro
daugter-board.
// UDB4_BOARD - Board is red, has 8 inputs, 8 output and no gyro
daughter-board.
// See the MatrixPilot wiki for more details on different UDB boards.
// If building for UDB4, use the MatrixPilot-udb4.mcp project file.
#define BOARD_TYPE UDB4_BOARD


////////////////////////////////////////////////////////////////////////////////
// Use board orientation to change the mounting direction of the
board.
// The following 6 orientations have the board parallel with the
ground.
// ORIENTATION_FORWARDS: Component-side up, GPS connector front
// ORIENTATION_BACKWARDS: Component-side up, GPS connector back
// ORIENTATION_INVERTED: Component-side down, GPS connector front
// ORIENTATION_FLIPPED: Component-side down, GPS connector back
// ORIENTATION_YAWCW: Component-side up, GPS connector to the
right
// ORIENTATION_YAWCCW: Component-side up, GPS connector to the
left
//
// The following 2 orientations are "knife edge" mountings
// ORIENTATION_ROLLCW: Rick's picture #9, board rolled 90 degrees
clockwise,
// from point of view of the pilot
// ORIENTATION_ROLLCW180: Rick's pitcure #11, board rolled 90 degrees
clockwise,
// from point of view of the pilot, then rotate the board 180 around
the Z axis of the plane,
// so that the GPS connector points toward the tail of the plane
#define BOARD_ORIENTATION ORIENTATION_FORWARDS


////////////////////////////////////////////////////////////////////////////////
// Choose your airframe type:
// AIRFRAME_STANDARD Elevator, and Ailerons and/or Rudder
control
// AIRFRAME_VTAIL Ailerons(optional), and Elevator and Rudder as
V-tail controls
// AIRFRAME_DELTA Aileron and Elevator as Elevons, and
Rudder(optional)
// (Note that although AIRFRAME_HELI is also recognized, the code for
this airframe type is not ready.)
#define AIRFRAME_TYPE AIRFRAME_DELTA


////////////////////////////////////////////////////////////////////////////////
// Set this value to your GPS type. (Set to GPS_STD, GPS_UBX_2HZ,
GPS_UBX_4HZ, or GPS_MTEK)
#define GPS_TYPE GPS_STD


////////////////////////////////////////////////////////////////////////////////
// Enable/Disable core features of this firmware
//
// Roll, Pitch, and Yaw Stabilization
// Set any of these to 0 to disable the stabilization in that axis.
#define ROLL_STABILIZATION_AILERONS 1
#define ROLL_STABILIZATION_RUDDER 0
#define PITCH_STABILIZATION 1
#define YAW_STABILIZATION_RUDDER 1
#define YAW_STABILIZATION_AILERON 1

// Aileron and Rudder Navigation
// Set either of these to 0 to disable use of that control surface for
navigation.
#define AILERON_NAVIGATION 1
#define RUDDER_NAVIGATION 1

// Wind Gain Adjustment
// This is an option for modulating the navigation gains in flight
// to maintain a constant turn radius in heavy winds in waypoing mode.
// Define WIND_GAIN_ADJUSTMENT as 1 to turn this feature on.
#define WIND_GAIN_ADJUSTMENT 0

// Altitude Hold
// Use altitude hold in stabilized mode? In waypoint mode?
// Each of these settings can be AH_NONE, AH_FULL, or AH_PITCH_ONLY
// - In waypoint mode, the target altitude is defined by the
waypoints or logo program.
// - In stabilized mode, when ALTITUDEHOLD_STABILIZED is set to
AH_PITCH_ONLY, the target
// altitude is whatever altitude the plane was at when switched into
stabilized mode.
// - In stabilized mode, when ALTITUDEHOLD_STABILIZED is set to
AH_FULL, the target
// altitude is determined by the position of the throttle stick on the
transmitter.
// NOTE: even when set to AH_NONE, MatrixPilot will still try to
stabilize pitch as long
// as PITCH_STABILIZATION is set to 1 above, but will not aim for any
specific altitude.
#define ALTITUDEHOLD_STABILIZED AH_FULL
#define ALTITUDEHOLD_WAYPOINT AH_FULL

// Speed Control
// If you define SPEED_CONTROL to be 1, MatrixPilot will take air
speed into account
// in the altitude controls, and will trim the throttle and pitch to
maintain air speed.
// Define DESIRED_SPEED to be the air speed that you want, in meters/
second.
#define SPEED_CONTROL 0
#define DESIRED_SPEED 10.00 // meters/second

// Inverted flight
// Set these to 1 to enable stabilization of inverted flight in
stabilized and/or waypoint modes.
#define INVERTED_FLIGHT_STABILIZED_MODE 0
#define INVERTED_FLIGHT_WAYPOINT_MODE 0

// Hovering
// Set these to 1 to enable stabilization of hovering in stabilized
and/or waypoint modes.
#define HOVERING_STABILIZED_MODE 0
#define HOVERING_WAYPOINT_MODE 0

// Note: As of MatrixPilot 3.0, Dead Reckoning and Wind Estimation are
automatically enabled.

// Camera Stabilization
// Set this value to 1, for camera to be stabilized using camera
options further below.
#define USE_CAMERA_STABILIZATION 0

// Define MAG_YAW_DRIFT to be 1 to use magnetometer for yaw drift
correction.
// Otherwise, if set to 0 the GPS will be used.
// If you select this option, you also need to set magnetometer
options in
// the magnetometerOptions.h file, including declination and
magnetometer type.
#define MAG_YAW_DRIFT 0

// Racing Mode
// Setting RACING_MODE to 1 will keep the plane at a set throttle
value while in waypoint mode.
// RACING_MODE_WP_THROTTLE is the throttle value to use, and should be
set between 0.0 and 1.0.
// Racing performance can be improved by disabling cross tracking for
your waypoints.
#define RACING_MODE 0
#define RACING_MODE_WP_THROTTLE 1.0

// Set this to 1 if you want the UAV Dev Board to fly your plane
without a radio transmitter or
// receiver. (Totally autonomous.) This is just meant for simulation
and debugging. It is not
// recommended that you actually use this option, since you'd have no
manual control to fall
// back on if things go wrong. It may not even be legal in your area.
#define NORADIO 0


////////////////////////////////////////////////////////////////////////////////
// Configure Input and Output Channels
//
// Use a single PPM input connection from the RC receiver to the UDB
on RC input channel 4.
// This frees up RC inputs 3, 2, and 1 to act as RC outputs 4, 5, and
6.
// If you're not sure, leave USE_PPM_INPUT set to 0.
// PPM_NUMBER_OF_CHANNELS is the number of channels sent on the PWM
signal. This is
// often different from the NUM_INPUTS value below, and should usually
be left at 8.
// If PPM_ALT_OUTPUT_PINS is set to 0, the 9 available RC outputs will
be sent to the
// following pins, in this order: Out1, Out2, Out3, In3, In2, In1,
RE0, RE2, RE4.
// With it set to 1, the RC outputs will be in this alternate
configuration:
// Out1, Out2, Out3, RE0, RE2, RE4, In3, In2, In1.
#define USE_PPM_INPUT 0
#define PPM_NUMBER_OF_CHANNELS 8
#define PPM_SIGNAL_INVERTED 0
#define PPM_ALT_OUTPUT_PINS 0

// NUM_INPUTS: Set to 1-5 (or 1-8 when using PPM input)
// 1-4 enables only the first 1-4 of the 4 standard input channels
// 5 also enables E8 as the 5th input channel
#define NUM_INPUTS 5

// Channel numbers for each input.
// Use as is, or edit to match your setup.
// - If you're set up to use Rudder Navigation (like MatrixNav),
then you may want to swap
// the aileron and rudder channels so that rudder is CHANNEL_1,
and aileron is 5.
#define THROTTLE_INPUT_CHANNEL CHANNEL_3
#define AILERON_INPUT_CHANNEL CHANNEL_1
#define ELEVATOR_INPUT_CHANNEL CHANNEL_2
#define RUDDER_INPUT_CHANNEL CHANNEL_5
#define MODE_SWITCH_INPUT_CHANNEL CHANNEL_4
#define CAMERA_PITCH_INPUT_CHANNEL CHANNEL_UNUSED
#define CAMERA_YAW_INPUT_CHANNEL CHANNEL_UNUSED
#define OSD_MODE_SWITCH_INPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_A_INPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_B_INPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_C_INPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_D_INPUT_CHANNEL CHANNEL_UNUSED

// NUM_OUTPUTS: Set to 3, 4, 5, or 6
// 3 enables only the standard 3 output channels
// 4 also enables E0 as the 4th output channel
// 5 also enables E2 as the 5th output channel
// 6 also enables E4 as the 6th output channel
// NOTE: If USE_PPM_INPUT is enabled above, up to 9 outputs are
available.)
#define NUM_OUTPUTS 4

// Channel numbers for each output
// Use as is, or edit to match your setup.
// - Only assign each channel to one output purpose
// - If you don't want to use an output channel, set it to
CHANNEL_UNUSED
// - If you're set up to use Rudder Navigation (like MatrixNav),
then you may want to swap
// the aileron and runner channels so that rudder is CHANNEL_1,
and aileron is 5.
//
// NOTE: If your board is powered from your ESC through the throttle
cable, make sure to
// connect THROTTLE_OUTPUT_CHANNEL to one of the built-in Outputs (1,
2, or 3) to make
// sure your board gets power.
//
#define THROTTLE_OUTPUT_CHANNEL CHANNEL_3
#define AILERON_OUTPUT_CHANNEL CHANNEL_1
#define ELEVATOR_OUTPUT_CHANNEL CHANNEL_2
#define RUDDER_OUTPUT_CHANNEL CHANNEL_4
#define AILERON_SECONDARY_OUTPUT_CHANNEL CHANNEL_UNUSED
#define CAMERA_PITCH_OUTPUT_CHANNEL CHANNEL_UNUSED
#define CAMERA_YAW_OUTPUT_CHANNEL CHANNEL_UNUSED
#define TRIGGER_OUTPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_A_OUTPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_B_OUTPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_C_OUTPUT_CHANNEL CHANNEL_UNUSED
#define PASSTHROUGH_D_OUTPUT_CHANNEL CHANNEL_UNUSED


////////////////////////////////////////////////////////////////////////////////
// Servo Reversing Configuration
// Here you can choose which reversing switches use hardware switches,
and hard code the rest.
// Note that your servo reversing settings here should match what you
set on your transmitter.
// For any of these that evaluate to 1 (either hardcoded or by
flipping a switch on the board,
// as you define below), that servo will be sent reversed controls.
#define AILERON_CHANNEL_REVERSED 1
#define ELEVATOR_CHANNEL_REVERSED 0
#define RUDDER_CHANNEL_REVERSED 0
#define AILERON_SECONDARY_CHANNEL_REVERSED 0 // Hardcoded to be
unreversed, since we have only 3 switches.
#define THROTTLE_CHANNEL_REVERSED 0 // Set to 1 to hardcode a
channel to be reversed
#define CAMERA_PITCH_CHANNEL_REVERSED 0
#define CAMERA_YAW_CHANNEL_REVERSED 0

// Set this to 1 if you need to switch the left and right elevon or
vtail surfaces
#define ELEVON_VTAIL_SURFACES_REVERSED 0


////////////////////////////////////////////////////////////////////////////////
// Mode Switch is ideally controlled by a 3-position switch on your
transmitter.
// Often the Flap channel will be controlled by a 3-position switch.
// These are the thresholds for the cutoffs between low and middle,
and between middle and high.
// Normal signals should fall within about 2000 - 4000.
#define MODE_SWITCH_THRESHOLD_LOW 2600
#define MODE_SWITCH_THRESHOLD_HIGH 3400


////////////////////////////////////////////////////////////////////////////////
// The Failsafe Channel is the RX channel that is monitored for loss
of signal
// Make sure this is set to a channel you actually have plugged into
the UAV Dev Board!
//
// For a receiver that remembers a failsafe value for when it loses
the transmitter signal,
// like the Spektrum AR6100, you can program the receiver's failsafe
value to a value below
// the normal low value for that channel. Then set the
FAILSAFE_INPUT_MIN value to a value
// between the receiver's programmed failsafe value and the
transmitter's normal lowest
// value for that channel. This way the firmware can detect the
difference between a normal
// signal, and a lost transmitter.
//
// FAILSAFE_INPUT_MIN and _MAX define the range within which we
consider the radio on.
// Normal signals should fall within about 2000 - 4000.
#define FAILSAFE_INPUT_CHANNEL THROTTLE_INPUT_CHANNEL
#define FAILSAFE_INPUT_MIN 1500
#define FAILSAFE_INPUT_MAX 4500

// FAILSAFE_TYPE controls the UDB's behavior when in failsafe mode due
to loss of transmitter
// signal. (Set to FAILSAFE_RTL or FAILSAFE_MAIN_FLIGHTPLAN.)
//
// When using FAILSAFE_RTL (Return To Launch), the UDB will begin
following the RTL flight plan
// as defined near the bottom of the waypoints.h or flightplan-logo.h
files. By default, this
// is set to return to a point above the location where the UDB was
powered up, and to loiter there.
// See the waypoints.h or flightplan-logo.h files for info on
modifying this behavior.
//
// When set to FAILSAFE_MAIN_FLIGHTPLAN, the UDB will instead follow
the main flight plan as
// defined in either waypoints.h or flightplan-logo.h. If the UDB was
already in waypoint mode
// when it lost signal, the plane will just continue following the
main flight plan without
// starting them over. And if the transmitter is still in waypoint
mode when the UDB sees it
// again, the UDB will still continue following the main flight plan
without restarting. If
// the UDB loses signal while not in waypoint mode, it will start the
main flight plan from the
// beginning.
#define FAILSAFE_TYPE FAILSAFE_RTL

// When FAILSAFE_HOLD is set to 1, then once Failsafe has engaged, and
you have subsequently
// regained your RC TX-RX connection, you will need to manually change
the Mode Switch in order
// to exit Failsafe mode. This avoids the situation where your plane
flies in and out of range,
// and keeps switching into and out of Failsafe mode, which depending
on your configuration,
// could be confusing and/or dangerous.
#define FAILSAFE_HOLD 0


////////////////////////////////////////////////////////////////////////////////
// Serial Output Format (Can be SERIAL_NONE, SERIAL_DEBUG,
SERIAL_ARDUSTATION, SERIAL_UDB,
// SERIAL_UDB_EXTRA, SERIAL_CAM_TRACK, or SERIAL_OSD_REMZIBI)
// This determines the format of the output sent out the spare serial
port.
// Note that SERIAL_OSD_REMZIBI only works with a ublox GPS.
// SERIAL_UDB_EXTRA will add additional telemetry fields to those of
SERIAL_UDB.
// SERIAL_UDB_EXTRA can be used with the OpenLog without characters
being dropped.
// SERIAL_UDB_EXTRA may result in dropped characters if used with the
XBEE wireless transmitter.
// SERIAL_CAM_TRACK is used to output location data to a 2nd UDB,
which will target its camera at this plane.
#define SERIAL_OUTPUT_FORMAT SERIAL_UDB_EXTRA


////////////////////////////////////////////////////////////////////////////////
// On Screen Display
// USE_OSD enables the OSD system. Customize the OSD Layout in the
osd_layout.h file.
#define USE_OSD 1

// NUM_ANALOG_INPUTS: Set to 0, 1, or 2
// 1 enables Radio In 1 as an analog Input
// 2 also enables Radio In 2 as another analog Input
// NOTE: Can only be set this higher than 0 if USE_PPM_INPUT is
enabled above.
#define NUM_ANALOG_INPUTS 0

// Channel numbers for each analog input
// - Only assign each channel number to one analog sensor
// - If you don't want to use an output channel, set it to
CHANNEL_UNUSED
// - Only 2 analog inputs are available, so you can't use all the
defined analog
// sensors at once
//
// ANALOG_CURRENT_INPUT_CHANNEL and ANALOG_VOLTAGE_INPUT_CHANNEL let
you plug in and
// use this Voltage/Current sensor board from SparkFun:
// http://www.sparkfun.com/products/9028
// Just plug the ground and signal lines of the chosen current input
channel into the
// ground and current outputs of the current sensor, and the signal
line of the chosen
// voltage input channel to the voltage output from the current
sensor. Values for
// instantaneous current, voltage, and mAh used will become available
for use with the
// OSD layout.
//
// ANALOG_RSSI_INPUT_CHANNEL lets you connect your RC Receiver's RSSI
output to your
// UDB, in order to see the RC signal strength on your OSD. Just plug
RSSI and ground
// from your Receiver to Input2's signal and ground on your UDB. If
you use this feature,
// you'll also need to set up the RSSI_MIN_SIGNAL_VOLTAGE and
RSSI_MAX_SIGNAL_VOLTAGE
// to match your Receiver's RSSI format. Note that some receivers use
a higher voltage to
// represent a lower signal strength, so you may need to set MIN
higher than MAX.

#define ANALOG_CURRENT_INPUT_CHANNEL CHANNEL_UNUSED
#define ANALOG_VOLTAGE_INPUT_CHANNEL CHANNEL_UNUSED
#define ANALOG_RSSI_INPUT_CHANNEL CHANNEL_UNUSED

// RSSI - RC Receiver signal strength
#define RSSI_MIN_SIGNAL_VOLTAGE 0.5 // Voltage when RSSI should
show 0%
#define RSSI_MAX_SIGNAL_VOLTAGE 3.3 // Voltage when RSSI should
show 100%


////////////////////////////////////////////////////////////////////////////////
// Trigger Action
// Use the trigger to do things like drop an item at a certain
waypoint, or take a photo every
// N seconds during certain waypoint legs.

// TRIGGER_TYPE can be set to TRIGGER_TYPE_NONE, TRIGGER_TYPE_SERVO,
or TRIGGER_TYPE_DIGITAL.
// If using TRIGGER_TYPE_SERVO, set the TRIGGER_OUTPUT_CHANNEL above
to choose which output channel
// receives trigger events, and set the TRIGGER_SERVO_LOW and
TRIGGER_SERVO_HIGH values below.
// If using TRIGGER_TYPE_DIGITAL, the trigger will be on pin RE4. In
this case make sure to set
// NUM_OUTPUTS to be less than 6 to avoid a conflict between digital
output and servo output on
// that pin.

// TRIGGER_ACTION can be: TRIGGER_PULSE_HIGH, TRIGGER_PULSE_LOW,
TRIGGER_TOGGLE, or TRIGGER_REPEATING
// The trigger action output is always either low or high. In servo
mode, low and high are servo
// values set below. In digital mode, low and high are 0V and 5V on
pin RE4.
// The action is triggered when starting on a waypoint leg that
includes the F_TRIGGER flag (see the
// waypoints.h file).
// If set to TRIGGER_PULSE_HIGH or TRIGGER_PULSE_LOW, then the output
will pulse high or low for the
// number of milliseconds set by TRIGGER_PULSE_DURATION.
// If set to TRIGGER_TOGGLE, the output will just switch from high to
low, or low to high each time
// the action is triggered.
// If set to TRIGGER_REPEATING, then during any waypoint leg with
F_TRIGGER set, high pulses will be
// sent every TRIGGER_REPEAT_PERIOD milliseconds.

// Note, durations in milliseconds are rounded down to the nearest
25ms.

#define TRIGGER_TYPE TRIGGER_TYPE_NONE
#define TRIGGER_ACTION TRIGGER_PULSE_HIGH
#define TRIGGER_SERVO_LOW 2000
#define TRIGGER_SERVO_HIGH 4000
#define TRIGGER_PULSE_DURATION 250
#define TRIGGER_REPEAT_PERIOD 4000


////////////////////////////////////////////////////////////////////////////////
// Control gains.
// All gains should be positive real numbers.

// SERVOSAT limits servo throw by controlling pulse width saturation.
// set it to 1.0 if you want full servo throw, otherwise set it to the
portion that you want
#define SERVOSAT 1.0

// Aileron/Roll Control Gains
// ROLLKP is the proportional gain, approximately 0.25
// ROLLKD is the derivative (gyro) gain, approximately 0.125
// YAWKP_AILERON is the proportional feedback gain for ailerons in
response to yaw error
// YAWKD_AILERON is the derivative feedback gain for ailerons in
response to yaw rotation
// AILERON_BOOST is the additional gain multiplier for the manually
commanded aileron deflection
#define ROLLKP 0.07
#define ROLLKD 0.007
#define YAWKP_AILERON 0.05
#define YAWKD_AILERON 0.005
#define AILERON_BOOST 0.00

// Elevator/Pitch Control Gains
// PITCHGAIN is the pitch stabilization gain, typically around 0.125
// PITCHKD feedback gain for pitch damping, around 0.0625
// RUDDER_ELEV_MIX is the degree of elevator adjustment for rudder and
banking
// AILERON_ELEV_MIX is the degree of elevator adjustment for aileron
// ELEVATOR_BOOST is the additional gain multiplier for the manually
commanded elevator deflection
#define PITCHGAIN 0.04
#define PITCHKD 0.004
#define RUDDER_ELEV_MIX 0.5
#define ROLL_ELEV_MIX 0.55
#define ELEVATOR_BOOST 0.00

// Neutral pitch angle of the plane (in degrees) when flying inverted
// Use this to add extra "up" elevator while the plane is inverted, to
avoid losing altitude.
#define INVERTED_NEUTRAL_PITCH 8.0

// Rudder/Yaw Control Gains
// YAWKP_RUDDER is the proportional feedback gain for rudder
navigation
// YAWKD_RUDDER is the yaw gyro feedback gain for the rudder in
reponse to yaw rotation
// ROLLKP_RUDDER is the feedback gain for the rudder in response to
the current roll angle
// MANUAL_AILERON_RUDDER_MIX is the fraction of manual aileron control
to mix into the rudder when
// in stabilized or waypoint mode. This mainly helps aileron-
initiated turning while in stabilized.
// RUDDER_BOOST is the additional gain multiplier for the manually
commanded rudder deflection
#define YAWKP_RUDDER 0.0625
#define YAWKD_RUDDER 0.5
#define ROLLKP_RUDDER 0.0625
#define MANUAL_AILERON_RUDDER_MIX 0.00
#define RUDDER_BOOST 1.00

// Gains for Hovering
// Gains are named based on plane's frame of reference (roll means
ailerons)
// HOVER_ROLLKP is the roll-proportional feedback gain applied to the
ailerons while navigating a hover
// HOVER_ROLLKD is the roll gyro feedback gain applied to ailerons
while stabilizing a hover
// HOVER_PITCHGAIN is the pitch-proportional feedback gain applied to
the elevator while stabilizing a hover
// HOVER_PITCHKD is the pitch gyro feedback gain applied to elevator
while stabilizing a hover
// HOVER_PITCH_OFFSET is the neutral pitch angle for the plane (in
degrees) while stabilizing a hover
// HOVER_YAWKP is the yaw-proportional feedback gain applied to the
rudder while stabilizing a hover
// HOVER_YAWKD is the yaw gyro feedback gain applied to rudder while
stabilizing a hover
// HOVER_YAW_OFFSET is the neutral yaw angle for the plane (in
degrees) while stabilizing a hover
// HOVER_PITCH_TOWARDS_WP is the max angle in degrees to pitch the
nose down towards the WP while navigating
// HOVER_NAV_MAX_PITCH_RADIUS is the radius around a waypoint in
meters, within which the HOVER_PITCH_TOWARDS_WP
// value is proportionally scaled down.
#define HOVER_ROLLKP 0.05
#define HOVER_ROLLKD 0.05
#define HOVER_PITCHGAIN 0.2
#define HOVER_PITCHKD 0.25
#define HOVER_PITCH_OFFSET 0.0 // + leans towards top, - leans
towards bottom
#define HOVER_YAWKP 0.2
#define HOVER_YAWKD 0.25
#define HOVER_YAW_OFFSET 0.0
#define HOVER_PITCH_TOWARDS_WP 30.0
#define HOVER_NAV_MAX_PITCH_RADIUS 20


////////////////////////////////////////////////////////////////////////////////
// Camera Stabilization and Targeting
//
// In Manual Mode the camera is fixed straight ahead.
// In Stabilized Mode, the camera stabilizes in the pitch axis but
stabilizes a constant yaw
// relative to the plane's frame of reference.
// In Waypoint Mode, the direction of the camera is driven from a
flight camera plan in waypoints.h
// In all three flight modes, if you set CAMERA_*_INPUT_CHANNEL then
the transmitter camera controls
// will override the camera stabilisation. This allows a pilot to
override the camera stabilization dynamically
// during flight and point the camera at a specific target of
interest.
//
// To save cpu cycles, you will need to pre-compute the tangent of the
desired pitch of the camera
// when in stabilized mode. This should be expressed in 2:14 format.
// Example: You require the camera to be pitched down by 15 degrees
from the horizon in stabilized mode.
// Paste the following line into a google search box (without the //)
// tan((( 15 /180 )* 3.1416 ))* 16384
// The result, as an integer, will be 4390. Change the angle, 15, for
whatever angle you would like.
// Note that CAM_TAN_PITCH_IN_STABILIZED_MODE should not exceed 32767
(integer overflows to negative).

#define CAM_TAN_PITCH_IN_STABILIZED_MODE 1433 // 1443 is 5 degrees
of pitch. Example: 15 degrees is 4389
#define CAM_YAW_IN_STABILIZED_MODE 0 // in degrees relative to the
plane's yaw axis. Example: 0

// Camera values to set at installation of camera servos
// All number should be integers
#define CAM_PITCH_SERVO_THROW 95 // Camera lens rotation at
maximum PWM change (2000 to 4000), in degrees.
#define CAM_PITCH_SERVO_MAX 85 // Max pitch up that plane can
tilt and keep camera level, in degrees.
#define CAM_PITCH_SERVO_MIN -22 // Max pitch down that plane
can tilt and keep camera level, in degrees.
#define CAM_PITCH_OFFSET_CENTRED 38 // Offset in degrees of
servo that results in a level camera.
// Example: 30 would mean that a centered pitch servo
points the camera
// 30 degrees down from horizontal when looking to the
front of the plane.

#define CAM_YAW_SERVO_THROW 350 // Camera yaw movement for
maximum yaw PWM change (2000 to 4000) in Degrees.
#define CAM_YAW_SERVO_MAX 130 // Max positive yaw of camera
relative to front of plane in Degrees.
#define CAM_YAW_SERVO_MIN -130 // Min reverse yaw of camera
relative to front of plane in Degrees.
#define CAM_YAW_OFFSET_CENTRED 11 // Yaw offset in degrees that
results in camera pointing forward.

// Camera test mode will move the yaw from + 90 degrees to + 90
degrees every 5 seconds. (180 degree turn around)
// That will show whether the CAM_PITCH_SERVO_THROW value is set
correctly for your servo.
// Once the camera rotates correctly through 180 degrees, then you can
adjust CAM_PITCH_OFFSET_CENTRED to center the camera.
// In Camera test mode, pitch angle changes permanently to 90 degrees
down in stabilized mode, and 0 (level) in Manual Mode.

#define CAM_TESTING_OVERIDE 0 // Set to 1 for camera to move
to test angles in stabilized mode.
#define CAM_TESTING_YAW_ANGLE 90 // e.g. 90 degrees. Will try to
swing 90 degrees left, then 90 degrees right
#define CAM_TESTING_PITCH_ANGLE 90 // In degrees.

// Set this to 1 to ignore camera target data from the flightplan, and
instead use camera target data coming in on the serial port.
// This data can be generated by another UDB running MatrixPilot,
using SERIAL_CAM_TRACK.
// NOTE: When using camera tracking, both UDBs must be set to use the
same fixed origin location.
#define CAM_USE_EXTERNAL_TARGET_DATA 0


////////////////////////////////////////////////////////////////////////////////
// Configure altitude hold
// These settings are only used when Altitude Hold is enabled above.

// Min and Max target heights in meters. These only apply to
stabilized mode.
#define HEIGHT_TARGET_MIN 170.0
#define HEIGHT_TARGET_MAX 300.0

// The range of altitude within which to linearly vary the throttle
// and pitch to maintain altitude. A bigger value makes altitude hold
// smoother, and is suggested for very fast planes.
#define HEIGHT_MARGIN 10

// Use ALT_HOLD_THROTTLE_MAX when below HEIGHT_MARGIN of the target
height.
// Interpolate between ALT_HOLD_THROTTLE_MAX and ALT_HOLD_THROTTLE_MIN
// when within HEIGHT_MARGIN of the target height.
// Use ALT_HOLD_THROTTLE_MIN when above HEIGHT_MARGIN of the target
height.
// Throttle values are from 0.0 - 1.0.
#define ALT_HOLD_THROTTLE_MIN 0.0
#define ALT_HOLD_THROTTLE_MAX 1.0

// Use ALT_HOLD_PITCH_MAX when below HEIGHT_MARGIN of the target
height.
// Interpolate between ALT_HOLD_PITCH_MAX and ALT_HOLD_PITCH_MIN when
// within HEIGHT_MARGIN of the target height.
// Use ALT_HOLD_PITCH_HIGH when above HEIGHT_MARGIN of the target
height.
// Pitch values are in degrees. Negative values pitch the plane down.
#define ALT_HOLD_PITCH_MIN -15.0
#define ALT_HOLD_PITCH_MAX 15.0
#define ALT_HOLD_PITCH_HIGH -15.0


////////////////////////////////////////////////////////////////////////////////
// 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 0.0


////////////////////////////////////////////////////////////////////////////////
// Hardware In the Loop Simulation
// Only set this to 1 for testing in the simulator. Do not try to fly
with this set to 1!
// See the MatrixPilot wiki for more info on using HILSIM.
// HILSIM_BAUD is the serial speed for communications with the X-Plane
plugin. Default is
// 19200, but 230400 is a good speedy option. Make sure the X-Plane
plugin's Setup file has
// its speed set to match.
#define HILSIM 0
#define HILSIM_BAUD 19200


////////////////////////////////////////////////////////////////////////////////
// Flight Plan handling
//
// You can define your flightplan either using the UDB Waypoints
format, or using UDB Logo
// Set this to either FP_WAYPOINTS or FP_LOGO
// The Waypoint definitions and options are located in the waypoints.h
file.
// The Logo flight plan definitions and options are located in the
flightplan-logo.h file.
#define FLIGHT_PLAN_TYPE FP_WAYPOINTS


////////////////////////////////////////////////////////////////////////////////
// Debugging defines

// The following can be used to do a ground check of stabilization
without a GPS.
// If you define TestGains, stabilization functions
// will be enabled, even without GPS or Tx turned on. (Tx is optional)
// #define TestGains // uncomment this line if you want to test
your gains without using GPS

// Set this to 1 to calculate and print out free stack space
#define RECORD_FREE_STACK_SPACE 0

[MIG-29]

Yes, I verified the HEX file. I have tried the erase/write cycle with
the HEX file writer and I get the same results.

[Peter Hollands]

Hi Florin,

By finding that the problem can start happening on "re-initialization" of the board, you have reduced the problem space considerably. I agree that you should no longer look at compiler / programmer issues / development environment issues.

Can we consider a "Systems Issue" here ...  In other words, we may be looking for some type of un-forseen interaction between your major system components. (Power issues, Power drawn by  other components, interactions with receiver, interactions with servos, injections from the ESC,  interferrence from a video transmission sysetm  and so on ...

For example:-

• Are you powering from anything the 3.3V power supplies of your UDB4 board ?
  

• What else are you power from the 5V power supplies of your UDB4 board ?
• Just to check ...  Which socket is the EM406A GPS plugged into ?
• What  is providing the VCC power to the UDB4 (Battery, BEC, UBeC?_ ,
  and what is the measured voltage is VCC to the board ?
• Are your servos being driven by the same power supply  that supplies the UDB4 ?
  

Can you give us a more overall picture of the entire "System Solution" for the plane.  What is in this plane, and how is the system all connected together ? Can you send provide a) an overall picture of the whole setup in the plane b) A more detailed written description of what is in the plane and how it is connected togerther. You should probably provide a detailed description of the make and model of servos that you are using.

A good idea would be to test one of your UDB4s in a completely different environment. Have you got some type of bench test environement ?  i.e. Put the UDB4 on a wooden board on your desk, power it from a different power source from that in the plane (e.g. a simple well charged 5V battery), a different receiver, and different servos ? Have you got a different make of GPS ? How does the UDB4 work in the test environment ?

I think if I was in your position I would check out my UDB4s from basics.

1. Reload the test firmware used by Sparkfun. The Led_test. And run it.

2. Load the Roll / Pitch / Yaw Demo, (re-read Bill's explanation of that in his PDF), and run that.

3. Run the UDB4 in a test environment on a wooden board, outside of the plane, ( and see if I could re-create the problem on my desk .... to try and remove potential system interaction issues.

Best wishes, Pete

--
--

[MIG-29]

Hello Pete,

Thanks for your answer.

Please find below the requested answers:

> - Are you powering from anything the 3.3V power supplies of your UDB4
> board ?

Yes, I am powering the OpenLog from the 3.3 V power supply from the
UDB4.


> - What else are you power from the 5V power supplies of your UDB4 board ?

The 5 Volt is generated by an external BEC from a 3S Lipo battery. The
battery is also used for the ESC of the motor.
The BEC only powers the receiver, the UDB4 and the servos.

> - Just to check ... Which socket is the EM406A GPS plugged into ?

The EM406 is plugged into the connector that does not have the battery/
supercapacitor.

> - What is providing the VCC power to the UDB4 (Battery, BEC, UBeC?_ ,

> and what is the measured voltage is VCC to the board ?

The measured voltage on the board is 5 Volt.

> - Are your servos being driven by the same power supply that supplies
> the UDB4 ?

Yes, the servos are powered from the same BEC that powers the UDB4 and
the receiver. However the servos are not powered through the UDB4. I
only have the signals and the ground together. The voltage of the
servos is taken directly from the BEC.
I use 2 standard servos on my wing. They are not power hungry. They
are not metalic gear ones. When I use high torque, power hungry servos
I use separate power supplies (separate batteries).


I have a Lipoly battery. I have the ESC connected to the Lipoly. I
also have a BEC connected to the Lipoly.

Servos get the voltage directly from the BEC. The receiver and the
UDB4 also get the voltage from the ESC.
The grounds of servo, receiver and UDB4 are common connected.

Exactly the same system and the same wing was used before with at
least 4 UDB3 autopilots. It worked flawlessly.
I usually use this wing to test the autopilots and tune them.

Tomorrow I will do the test with the UDB, receiver, 2 servos and a
NiMh battery on a woden plate and let you know about the results.

Best regards!

[MIG-29]

Oh, one more thing: I am also using a OSD together with the OpenLog on
the above setup. As I mentioned the OpenLog takes the 3.3 Volts from
the UDB while the OSD also gets its power (5Volts) from the UDB.
The connections of OpenLog and UDB are made as per manual.

Best regards!

[Keith Merrill]

Check your UDB4 Board_Orientation. Make sure your Options.h orientation matches your UDB4 board mounted in your aircraft orientation. If the X-> direction of the UDB4 board. If the board is backwards in the X-> direction is your ailerons will operate backwards In stabilization and waypoint mode.

Keith

---

From: MIG-29 <florin.mi...@gmail.com>
To: uavdevboard <uavde...@googlegroups.com>
Sent: Sunday, June 24, 2012 7:10 AM
Subject: Re: UDB4 large controls...

--
--

[Keith Merrill]

Sorry let me correct my typing errors.

Check your UDB4 Board_Orientation. Make sure your Options.h orientation matches your UDB4 board orientation that you mounted in your aircraft. Specifically the X-> direction of the UDB4 board. Also check the Y-> and Z-> directions. If the board is backwards in the X-> direction then your ailerons will operate backwards In stabilization and waypoint mode. If any other axis orientations need change servo reversing will be required. If this is the case after re mounting your UDB4 board you will need to go through and check all Radio servo directions and your Options.h file servo directions. Then if you are using HILSIM you will need to change your servo directions in your X-Plane setup file.

Keith

---

From: MIG-29 <florin.mi...@gmail.com>
To: uavdevboard <uavde...@googlegroups.com>
Sent: Sunday, June 24, 2012 7:10 AM
Subject: Re: UDB4 large controls...

--
--

[MIG-29]

Hello Keith,

Thanks for your message.
The board worked well once and then after a reinitialization didn't
work well. So the options.h are pretty much OK. More than this, I have
flown with those options.h

I will do some more tests today and report back to the discussion
board.

Best regards!

On Jun 24, 8:06 pm, Keith Merrill <kpmerr...@yahoo.com> wrote:
> Sorry let me correct my typing errors.
>
> Check your UDB4 Board_Orientation. Make sure your Options.h orientation matches your UDB4 board orientation that you mounted in your aircraft. Specifically the X-> direction of the UDB4 board. Also check the Y-> and Z-> directions. If the board is backwards in the X-> direction then your ailerons will operate backwards In stabilization and waypoint mode. If any other axis orientations need change servo reversing will be required. If this is the case after re mounting your UDB4 board you will need to go through and check all Radio servo directions and your Options.h file servo directions. Then if you are using HILSIM you will need to change your servo directions in your X-Plane setup file.
>
> Keith
>
> ________________________________

>  From: MIG-29 <florin.mingirean...@gmail.com>

[Peter Hollands]

Hi Florin,

Thanks for answering all those questions carefully.

If this was my board, and just to be safe,  I would disconnect the OpenLog from the 3.3V rail on the UDB4. The gyros and accelerometers are sensitive to having a clean power supply on that rail.  The OpenLog has it's own on board power regulator that takes higher voltages down to 3.3V within the board. So powering the OpenLog with 12V (according to datasheet) or 5v is fine.  In other words you can power the OpneLog from your VCC (5V) coming from the BEC. Officially the OpenLog needs a maximum of 6mA, so it should not be a problem. But there is a chance it is effecting the rise time of voltage during initialisation of the gyros / accels. And since you have been having intermittent problems with the UDB4 stabilisation after bootup, I would consider trying to power the OpenLog from the BEC. Or simply disconnect for a few tests, to see if that makes a difference.

In my vocabulary there are at 3 power supply rails as follows:
"VCC" (The power supply that is coming from your BEC)
"UDB4 5V"   (The 5V power supply rail within the UDB4, which is controlled by the onboard UDB 4 regulator)
"UDB4 3V"   (The 3V power supply within the UDB4, which is controlled by a second regulator on the UDB4).

If the OSD is supplied from the "UDB4 5V",  then I would also be  careful about that. Probably I would power it from somewhere else. When it comes to OSD's and Video Transmission, I defer completely to people like Ric and Ben who have much more experience. But given the history of interference from video transmission systems, I would be wary of powering the OSD from the "UDB4 5V" supply.

While talking about video transmission, if you are using the OSD you must have a powerful video transmitter on board. Can you describe what that is, how powerful, and how it is powered ? I know you have a great deal of experience in that area, but it would help to complete the overall systems picture.

I hope you have a successful test today on the wooden board in the development environment outside of the plane.

Best wishes, Pete

--
--

[Tom Pittenger]

Isn't the 5V only wired to the Em406 GPS? That is a tiny power draw so it is mostly just sitting there idle.

-TomP

--
--

[MIG-29]

Hello Peter,

I tested the boards without OpenLog and without OSD (with appropriate
modifications in options.h) and I obtained the same results.
Sometimes it works- deflections are OK both as magnitude and direction
while some other times the deflections are wrong either in magnitude
or in direction.

The change between OK and wrong takes place from one reinitialization
to another.

I supply VCC from a NiMh battery and I monitor it using a high
precision voltmeter. It never goes lower than 5 Volts.

Best regards

[MIG-29]

Hello Pete,

I got other new UDB4 boards. The behaviour is the same: in
STABILIZATION mode I get very very very large controls- for just a few
degrees of tilt the elevons are almost fully deflected.

I removed the UDB4 from the plane and powered it separately (without
the OpenLog and without the OSD). I changed the options.h to reflect
the fact that I don't have OSD and OpeLog.

The behaviour is the same. Also, a UDB3 works perfectly on the same
setup on the plane.

However, since these are 2 new boards I am pretty sure that the
probability of having a bad board is very very very low. What else
could it be?

What compiler and MPLAB IDE versions are you using?

Best regards

On Jun 25, 9:42 am, Peter Hollands <peter.holla...@gmail.com> wrote:

[MIG-29]

One more thing: I initialize the UDB4, MANUAL works OK.

I switch to STABILIZATIO and both elevons are deflected upwards (half
deflection). The initialization is done on a flat surface- I have done
it before for the UDB3 exactly in the same conditions- UDB3 works
while UDB4 doesn't! After 5-7 seconds elevons come back to the
horizontal position (no visible upwards deflection).
What might be wrong?

Best regards!

[MIG-29]

Problem solved:

Interesting thing... at least for me.

I had 5 inputs defined and 4 outputs. However since I use a flying
wing I really only had 4 inputs used and 3 outputs.
In this configuration the MANUAL mode worked OK while the
STABILIZATION mode went crazy: large deflections (full deflections)
and incorrect direction of deflections...

Next, I changed options.h and mentioned CHANNEL_UNUSED for the
channels that were not used. I also decreased the number of inputs
from 5 to 4 and outputs from 4 to 3.

In this configuration, with the same Matrixpilot code version, the
MANUAL mode worked OK and the STABILIZATION also worked beautifully!

It seems that if one mentions extra channels on input and those
channels are not really used (they are not connected to the receiver)
then the STABILIZATION mode goes crazy. Goes crazy= full deflections
for very small tilts of the plane and wrong directions for the
deflections.
Why would this happen?

Could this also happen if there is a mid-flight disconnection between
one of the receiver channels and the autopilot? Assume a wire is
broken in mid flight (the reason for which it is broken doesn't matter
right now!) then it seems that the UDB4 would go crazy...

Best regards

[William Premerlani]

Hi Florin,

Here is the explanation for what happened when you disconnected the rudder channel.

First of all, you had rudder-elevator mixing enabled, that is the first link in the chain:

#define RUDDER_ELEV_MIX 0.5

So, the above is all well and good if you define a rudder channel, as long as you have a rudder input connected. The reason is, for this feature, the controls in MP3.2.1 mix rudder output into elevator output, based on roll angle.

The logic only does the mixing if you have defined both a rudder input channel and a rudder output channel. So, if you set either of those as UNUSED, the logic ignores RUDDER_ELEV_MIX. But if you have both of them defined, the logic turns on the mixing, based on rudder output:

if ( RUDDER_OUTPUT_CHANNEL != CHANNEL_UNUSED && RUDDER_INPUT_CHANNEL != CHANNEL_UNUSED ) {

pitchAccum.WW = __builtin_mulss( rmat6 , rudderElevMixGain ) << 1 ;

pitchAccum.WW = __builtin_mulss( pitchAccum._.W1 ,

REVERSE_IF_NEEDED(RUDDER_CHANNEL_REVERSED, udb_pwTrim[RUDDER_INPUT_CHANNEL] - udb_pwOut[RUDDER_OUTPUT_CHANNEL]) ) << 3 ;

navElevMix += pitchAccum._.W1 ;

}

So, here is what happened...

Because you did not have anything connected to rudder input, there were no pulses coming in, so the trim for the rudder does not get set properly (it gets set to zero during initialization, which is far off from the normal range of 2000-400), and MP does not have saturation logic on inputs, only on outputs.

Because you had both rudder input and output channels assigned, the mixing computation from rudder output to elevator output proceeded. However, the step that computed the difference between rudder trim (which was 0) and output produced a very large value, which went into the mixing computation, which then made the elevator "hypersensitive" to roll.

Regarding your question about what would happen if rudder input got disconnected in flight...there is not much risk with that, because the issue arises mainly during initialization. After that, if pulses stop arriving, the width of the last received pulse continues to be used.

That said, there is a small risk associated with a broken PWM input wire during flight that I wish to draw to the attention of the developers:

If a PWM input wire breaks during a PWM input pulse, it will likely generate a spurious pulse width calculation. I am not sure exactly what would happen, I would have to run some tests to be sure. What I expect would happen is that the rate at which the voltage on the input pin would fall after the connection broke would depend on the shunt resistance and capacitance to ground of the input pin. At some point, the voltage would fall below a logic 1 threshold, which would generate a falling edge interrupt, causing a spurious pulse to be generated, and locked in.

The probability of a spurious pulse being generated by a broken input wire is equal to the pulse width at that time, times the frame rate. For a pulse width of 1.5 milliseconds (typical for centered stick), and a frame rate of 40 Hz, the probability that a wire breaking at random will happen during a pulse is 6%.

So, Florin, MP is not "bullet-proof" against breaking wires in flight, though it could be made so if the demand is great enough and if someone wants to implement it.

What we would have to do is do health checking on each defined channel, and take out of service when pulses stop coming in, and execute some sort of fail-safe strategies selectable for individual channels.

Best regards,

Bill

--

[William Premerlani]

Hi Florin,

A couple more comments about the effects of in-flight broken rudder input channel...

1. I was able to reproduce your symptoms by leaving the rudder channel input and output defined, but with rudder input disconnected.

2. I tested disconnecting the rudder input after initialization, and was not able to create any problems whatsoever (other than the rudder stopped responding). I did this 20 times.

Best regards,

Bill