First flight with the UDB in a nitro helicopter

[Marc-X]

Hello everyone.
Yesterday evening I took my Kyosho Caliber out for a spin with the UDB
mounted.
First of all I had to do all basic trimming of the helicopter since I
had done a complete rebuild to change bearings and to balance all
rotary components.
After a while the helicopter started to behave the way I wanted. I
have always flewn it "nose heavy, but now I tried to balance it so
that it flew with the same attitude as it sits on the skids. I have
mounted two small water levels on the frame to be able to "reset" the
UDB in a true level. To have the helicopter balanced, I had to mount
an 8-cell AA pack of NiMh to the boom braces, close to the frame.
After this the helicoper balances as it sits on the ground.

When I had the helicopter in a stable hover, I flipped the mode switch
over to "auto" and immediately the helicopter started to bank
backwards and to the left. I repeated this a few times with the same
sesult. Now it had become too dark to continue flying since it was
difficult to see the attitude clearly.

It looks like I have to adjust the MP-H variables that accounts for
the difference in flight attitude and "sitting" attitude. To me it
doesn't look as this behaviour comes from vibrations since the
behaviour is consequent. Will try to do some more flying tomorrow if
the weather allows me.


Marc

[William Premerlani]

Hi Marcus,

Cool. Glad that you are making progress. It sounds like everything is normal.

You are exactly correct. When a heli is hovering, it cannot be level. So, there are roll and pitch tilt variables that you have to adjust in the heli code to account for it.

The reason that the heli cannot have 0 roll is because of the tail rotor. It acts like a propeller. When the heli is level, the torque that it generates is balanced by the main blades, but there is nothing counteracting the force! So, what happens is that a good heli pilot automatically rolls the heli just a little bit after takeoff to balance it out.

What might not be so clear is why you also need to pitch the heli. John McClelland explained it to me once, but I forget why. I think it has something to do with the torque generated by the rotor.

In any case, there are roll and pitch variables that you need to adjust. John is the best guy to explain how. Basically, you initialize the UDB with the heli level, but you have to dial in the amount of roll and pitch needed for a stationary hover.

Best regards,

Bill

[John McClelland]

Hi Marc

Glad you got to the point of a test flight. There are a couple things you
want to check to get stable hover.

I did not understand the need for the 8-cell AA battery pack to balance the
heli. That is a lot of weight. The way you want to balance it is so that
it flies properly in manual mode. If this is what it takes, then OK.

I for

[John McClelland]

Ooops hit send too quick....

So check you balance in manual mode. Get all the trims set for a stable
hover in manual.

Not sure which Tx you are using and which switch, but if you are using the
flight mode switch (3 way) on a Specktrum, each mode has its own trims. So
in this case you need to set the trims for auto mode switch setting to be
the same as manual that you just set.

Initialize the UDB with roll and pitch leveled on the ground.

Now the pitch and roll tilt offsets are acting on a "normal" heli setting.
In a hover you need to apply enough roll to compensate for the sideways
thrust of the tail rotor. This is done in the UDB using the ROLLTILT
defined in options.h. Same is true for pitch, this is a smaller effect due
to the torque generated by the tail rotor. This offset is PITCHTILT. They
are typically 2 and 0.5 degrees respectively, but can vary from heli to
heli.

If you still see the heli tending to the right/left and/or forward/backward
change ROLLTILT and PITCHTILT appropriately. These offsets will only
correct rotations about the x/y axes, not a translation (like wind). I find
it is fine to get it close. once in a hover in auto give it a little trim.

Hope this helps.

John

----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>
Sent: Saturday, August 28, 2010 11:36 AM
Subject: First flight with the UDB in a nitro helicopter

[William Premerlani]

Hi John and Marcus,

I see that John's computer must have "hiccupped".

I think what John was going to say is:

1. Don't make any changes to your heli's balance on account of the UDB. The UDB can be set up to account for the roll and pitch attitude of your heli in a hover. Set up your heli for the best flight characteristics. Certainly don't add any weight that is not needed.

2. Determine the roll and pitch attitude of your heli in a hove. John will tell you how, but I think you can figure out how to estimate it.

3. Enter the roll and pitch parameters into the code.

4. Power up with the heli level.

5. Take off, get into a stable hover.

6. Switch into stabilized, note any shifts in roll and pitch.

7. Fine tune the roll and pitch adjustment parameters, and fine tune.

By the way, my theory on why the heli might pitch in a hover is simply the location of the center of gravity, now that I think about it. The roll is due to the side force of the tail rotor.

Best regards,

Bill

[William Premerlani]

Marcus and John,

Just to revise something in my previous email:

Now that I think about it some more, I think the pitching of a heli in a hover is cause by a combination of the torque produced by the tail rotor, and the location of the center of gravity.

Best regards,

Bill

[Marc-X]

Hi guys,

If I remember correctly, the roll / pitch tendency is also influenced
by the gyroscopic properties of the helicopters rotating masses (both
main and tail rotor). If you move a spinning gyroscope, you will have
torque forces effecting it, right?. (long time since I had anything to
do with this stuff)


Just to clarify what I wrote regarding CG and to detail my radio /
heli setup:

The heli has always been nose heavy. Everyone who sees themselves as
"helicopter gurus" has pointed out that the heli should be "level".
When reading "beginners guides" on the net, it usually says something
like: "at, or slightly ahead of" the main mast. How much is "slightly
ahead" in metric units?? I don't remember where the CG used to be in
my first helicopter (25 years ago).This helicopter builds up nose
heavy, and nowhere in the build manual is a CG marked.
When I re-built the heli this time, I took the trouble to move the
CG to exactly under the main rotor shaft by exchanging the original
engine for a slightly lighter and more powerful one, and adding a
battery pack to the boom braces just behind the frame. This gives me
the extra power I need for cameras and the CG where it's "supposed to
be".

Radio setup:
The radio I use is a Futaba FF9 Super (9CHP). I have set all FLIGHT
modes to the same amount of EXPO and DR, except HOLD, which is linear.

The pitch curves are the same in all flight modes, except MODE1 (take-
off and landing) where I have NO negative pitch.The pitch is
50-55-60-70-80 in NORMAL and 40-50-60-70-80 in all other flight modes.
HOLD is 0-25-50-75-100 with throttle at idle.

I have this setup with no acrobatic modes when experimenting with the
UDB to avoid any confusion if experiencing an emergency situation. The
last thing I want is to throw the helicopter into the ground by
flipping the wrong switch in an emergency.
To minimize the risk, the UDB switch is next to the governor, which is
harmless to switch off because throttle curve will hold the throttle
at 50-75% anyway. This is enough power to fly inverted if necessary.

Throttle is controlled by a governor on a 3-way switch
(OFF-1300rpm-1700rpm). In NORMAL flight mode the governor is switched
off in lowest stick position. This is used to take-off and land.IDLE-
UP 1,2 and 3 is all set to maintain 50-75% throttle setting if
governor is switched off. HOLD mode is 100% linear with the throttle
at high IDLE.

The gyro (Futaba GY-611) is controlled by a two-way switch (HH /
NORMAL) at the left side of radio,
The governor (Futaba GV-1) is controlled by a three-way switch at the
right side of radio.

The UDB is controlled by a two-way switch at the right side of radio,
next to the governor switch.

I will now set the pitch and roll correction values to zero, to see
how the helicopter behaves without them. Then try to compensate for
the helis natural tendency to roll / pitch. Possibly have someone to
video the helicopter for later study of the behavior.

How are your CG in respect to the main mast?

Cheers!

Marc.

On Aug 28, 8:59 pm, William Premerlani <wpremerl...@gmail.com> wrote:
> Marcus and John,
>
> Just to revise something in my previous email:
>
> Now that I think about it some more, I think the pitching of a heli in a
> hover is cause by a combination of the torque produced by the tail rotor,
> and the location of the center of gravity.
>
> Best regards,
> Bill
>
> On Sat, Aug 28, 2010 at 2:56 PM, William Premerlani

> <wpremerl...@gmail.com>wrote:

> >> ----- Original Message ----- From: "Marc-X" <marcus.fah...@gmail.com>

[Marc-X]

Hi John,

Let's see if I have got this right:

The ROLL and PITCH -TILT are not that critical, they can be fine tuned
with ordinary trim input from the TX? The issue is that you will have
different ROLL / PITCH behavior in STABILIZED / NON-STABILIZED mode if
you don't get the ROLL, and PITCH -TILT "spot-on"? Maybe I should
setup a flight-mode temporarily for the "UDB stabilized" flying, and
see how much trim difference there is between "normal" flying and
"stabilized" flying, and estimate the values for ROLL and PITCH -TILT
from here?

On the other hand, I could use a flight mode switch for the UDB
control permanently and forget all about the trim difference (since
the trims are individual for each flight mode setting). In this case I
have to set the ROLL and PITCH -TILT values to 0, right? Will this
have any consequences that I'm not seeing here?

I don't really have any use for all flight modes since I will not do
any 3D stuff with this helicopter anyway. It's meant to be a camera
ship.


Cheers!

Marc

On Aug 28, 8:51 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[John McClelland]

Hi Marc

While not critical, it is important to get them close. These offsets go
directly into the DCM calculation so that it's "normal" attitude is gravity
offset by ROLL and PITCHTILT. without them you are always fighting the UDB
to maintain a stable hover.

But perhaps more importantly, it is a bad idea to have a big offset in going
from manual to auto (and later nav). At least for me, when I go from auto
to manual it is usually because there is a problem. The last thing you want
is to compound the problem with a sudden roll or pitch.

You also become sensitive to the boost gain since this multiplies the
difference of you Tx (incuding trims) from the neutral position recorded at
init of the UDB.

So my statement was to get it close, but don't spend 5 minutes getting
everything perfect. And if your mode switch carries its own trims, copy
them to make them the same manual and auto once you have things trimmed up.

You really only do this once since things mostly stay the same from flight
to flight and small changes aren't important.

You might as well get your Tx setup for a 3 position switch since we will
eventually impliment navigation and you will need it.

John

----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>.

Sent: Saturday, August 28, 2010 10:48 PM
Subject: Re: First flight with the UDB in a nitro helicopter

[Marc-X]

Heli guys;

Second flight was due yesterday evening. Since I'm not 100%
comfortable with the helicopter yet, I really can't tell too much yet.
What I observed when kicking in the "AUTO" mode (stab mode really), is
that the heli starts to oscillate slightly.
Because I flew the heli without any practice braces over hard
concrete, I chickened out and switched over to "manual" mode
immediately.
The heli had a tendency to drift backwards as soon as the UDB was
engaged.

The only adjustments done since last flight is slightly lowered
"SERVOSAT" parameter. I have this value set to "65" now ("75" last
flight) because I observed larger servo throws with the UDB engaged
compared to the UDB disengaged.
With the UDV engaged, I have servo binding, but not otherwise.

Is this "SERRVOSAT" value a percentage of to the RADIO input pulse, or
a percentage of a "standard" saturation value of 2000uSec?

I have my radio "SWASH AFR" set to -65 for all three servos. (That
means that the swash servos are limited to a max 65% throw, and
reversed). This is according to the build manual.


Cheers!

Marc



On Aug 29, 5:29 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[John McClelland]

Hi Marc

What type of oscillation did you observe? About what axes? Did you change
any of the gains from the distribution files?

The drifting backwards can be due to a number of sources. Where your trims
in manual set to cancel this? If so and the same trims are present in auto
and the heli was level on init and there wasn't a wind blowing it backwards
(a lot of ands), then just adjust PITCHTILT to correct it.

As I note in the documentation, you still need to "fly" the heli even in
stabilized mode since you will never get it perfectly trimmed up and the UDB
only stabilizes rotations not translations, other than the TILT offsets to
compensate for tail rotor thrust and torque. We have been working on code
to do translation stabilization but is limited by the sensors being used.
Something like optical flow could work, but we haven't got there yet.

SERVOSAT limits the range of the output PWMs. You can see the code in
defines.h:

#define SERVORANGE (int) ( SERVOSAT*1000 )
#define SERVOMAX 3000 + SERVORANGE
#define SERVOMIN 3000 - SERVORANGE

So making it less than one will limit the servo throw. Using it to limt
servo binding is the right thing to do (and sounds consistent with your Tx
limits). There are other factors that can produce large outputs including
large gains and boosts. So it would be useful to see your options.h to see
how you have things set up.

Best,
John

----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>

[Marcus Fahlén]

Bill,

The oscillations I observed is in the "pitch" attitude.

There were practically NO wind yesterday evening when I flew the bird. The bird hovers almost stationary without the UDB engaged, with very little stick input. As I said, I'm still setting up the DR and EXPO to my liking after rebuilding, but I'm slowly getting there. (very close now). Adjusted the pitch curves and EXPO somewhat yesterday to have it behave rather "sluggish" at mid-stick. I don't want to have it all over the place when making small pitch adjustments close to ground.

My "options.h" (somewhat "re-arranged" to be easier to work with):

Kind regards

Marc

////////////////////////////////////////////////////////////////////////////////

// Kyosho Caliber 5 (nr 1) options.h

////////////////////////////////////////////////////////////////////////////////

// Serial telemetry output:

// Serial Output Format (Can be SERIAL_NONE, SERIAL_DEBUG, SERIAL_ARDUSTATION, SERIAL_UDB, or SERIAL_OSD_REMZIBI)

// Note that SERIAL_OSD_REMZIBI only works with GPS_UBX.

#define SERIAL_OUTPUT_FORMAT SERIAL_DEBUG

// Telemetry output scaling value

// The default loop frequency of 40Hz

// is scaled by this number

#define TELEMETRY_PRESCALER 10.0

// Roll and Pitch TILT parameters

// ROLLTILT compensates for sideways thrust of tail rotor

// PITCHTILT compensates for torque of tail rotor 

#define ROLLTILT 2.0 // Right roll tilt angle, in degrees (2.0)

#define PITCHTILT 0.5 // Pitch tilt angle in degrees that the nose of the plane will pitch downward (0.5)

////////////////////////////////////////////////////////////////////////////////

// Mode Switch 

// Normal signals should fall within about 2000 - 4000.

// These value represents .5 uS (microsecond) units.

// Thus 2000-4000 = 1 to 2 mS (milliseconds).

// For Futaba "full-throw" channels use 5000 for MODE_SWITCH_THRESHOLD_HIGH.

#define MODE_SWITCH_THRESHOLD_LOW 2000

#define MODE_SWITCH_THRESHOLD_HIGH 5000

////////////////////////////////////////////////////////////////////////////////

// The Failsafe Channel is the RX channel that is monitored for loss of signal

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

#define FAILSAFE_INPUT_MIN 1500

#define FAILSAFE_INPUT_MAX 4500

////////////////////////////////////////////////////////////////////////////////

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

//!!!!! FILTERSHIFT filters raw gyro and accel data.  For Heli I found that FILTERSHIFT = 3

//!!!!! caused oscillations with the FILTERSHIFT = 6 gains for roll and pitch.  Had to reduce gains 

//!!!!! to 0.4 of standard gains to kill oscillations, but not great stability at low gain.

//!!!!! Leave at 6 for heli for now

#define FILTERSHIFT 6 // filter shift divide

////////////////////////////////////////////////////////////////////////////////

// Set Up Board Type (Set to RED_BOARD, GREEN_BOARD, RED_GREEN_BOARD, INVENSENSE_BOARD, JERRYS_BOARD)

//

#define BOARD_TYPE INVENSENSE_BOARD

////////////////////////////////////////////////////////////////////////////////

// Choose your airframe type:

// 

#define AIRFRAME_TYPE AIRFRAME_HELI

////////////////////////////////////////////////////////////////////////////////

// 

// SWASH1 120 deg swash (Futaba SR-3)

// SWASH2 90 deg swash

// SWASH3 140 deg swash 

#define SWASH_TYPE SWASH1

////////////////////////////////////////////////////////////////////////////////

// Set this value to your GPS type.  (Set to GPS_STD or GPS_UBX)

#define GPS_TYPE GPS_UBX

////////////////////////////////////////////////////////////////////////////////

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

#define PITCH_STABILIZATION 1

//!!!!! YAW_STABILIZATION is off for now until we get HH heli code incorporated

#define YAW_STABILIZATION_RUDDER 0 // leave 0 for helis for now

#define YAW_STABILIZATION_AILERON 0 // leave 0 for helis for now

// Aileron and Rudder Navigation

// Set either of these to 0 to disable use of that control surface for navigation.

#define AILERON_NAVIGATION 0

#define RUDDER_NAVIGATION 0

// Altitude Hold

#define USE_ALTITUDEHOLD 0

// Camera Stabilization

// !!!!! Should be set to 0 until tested for heli's

#define USE_CAMERA_STABILIZATION 0

// Racing Mode

// !!!!! Should be set to 0 for heli's

#define RACING_MODE 0

// !!!!! Should be set to 0 until tested for heli's

#define NORADIO 0

////////////////////////////////////////////////////////////////////////////////

// Configure Input and Output Channels

// NUM_INPUTS: Set to 4 or 5 

//   4 enables only the standard 4 input channels

//   5 also enables E8 as the 5th input channel

#define NUM_INPUTS 4

// Channel numbers for each input.

// !!!!! Only the 3 swash servos AILERON_INPUT_CHANNEL, ELEVATOR_INPUT_CHANNEL, AILERON_SECONDARY_INPUT_CHANNEL

// !!!!! and MODE_SWITCH_INPUT_CHANNEL are used for helis at this time

#define THROTTLE_INPUT_CHANNEL CHANNEL_UNUSED

#define AILERON_INPUT_CHANNEL CHANNEL_3

#define ELEVATOR_INPUT_CHANNEL CHANNEL_2

#define AILERON_SECONDARY_INPUT_CHANNEL CHANNEL_1

#define RUDDER_INPUT_CHANNEL CHANNEL_UNUSED

#define MODE_SWITCH_INPUT_CHANNEL CHANNEL_4

#define CAMERA_ROLL_INPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_PITCH_INPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_YAW_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

#define NUM_OUTPUTS 3

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

//

// !!!!! Only the 3 swash servos AILERON_INPUT_CHANNEL, ELEVATOR_INPUT_CHANNEL, AILERON_SECONDARY_INPUT_CHANNEL

// !!!!! are used for helis at this time 

#define THROTTLE_OUTPUT_CHANNEL CHANNEL_UNUSED

#define AILERON_OUTPUT_CHANNEL CHANNEL_3

#define ELEVATOR_OUTPUT_CHANNEL CHANNEL_2

#define RUDDER_OUTPUT_CHANNEL CHANNEL_UNUSED

#define AILERON_SECONDARY_OUTPUT_CHANNEL CHANNEL_1

#define CAMERA_ROLL_OUTPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_PITCH_OUTPUT_CHANNEL CHANNEL_UNUSED

#define CAMERA_YAW_OUTPUT_CHANNEL CHANNEL_UNUSED

////////////////////////////////////////////////////////////////////////////////

// Servo Reversing Configuration

// 

#define AILERON_CHANNEL_REVERSED HW_SWITCH_1

#define ELEVATOR_CHANNEL_REVERSED HW_SWITCH_2

#define RUDDER_CHANNEL_REVERSED 0

#define AILERON_SECONDARY_CHANNEL_REVERSED HW_SWITCH_3 

#define THROTTLE_CHANNEL_REVERSED 0 

#define CAMERA_ROLL_CHANNEL_REVERSED 0

#define CAMERA_PITCH_CHANNEL_REVERSED 0

#define CAMERA_YAW_CHANNEL_REVERSED 0

// Aileron/Roll Control Gains

// ROLLKP is the proportional gain, approximately 0.25

// ROLLKD is the deriviate (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 reponse to yaw rotation

// AILERON_BOOST is the additional gain multiplier for the manually commanded aileron deflection

// BOOST terms are truncated to closest 1/8 (0.125)

#define ROLLKP 0.2 //!!!!! Used in Heli (.2)

#define ROLLKD 0.1 //!!!!! Used in Heli (.1)

#define YAWKP_AILERON 0.0625 //!!!!! Used in Heli 

#define YAWKD_AILERON 0.0 //!!!!! Used in Heli 

#define AILERON_BOOST 0.3 //!!!!! Used in Heli AILERON AND ELEVATOR BOOST MUST BE THE SAME 

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

// BOOST terms are truncated to closest 1/8 (0.125)

#define PITCHGAIN 0.2 //!!!!! Used in Heli (.2)

#define PITCHKD 0.1 //!!!!! Used in Heli (.1)

#define RUDDER_ELEV_MIX 0.0 //!!!!! Not used in Heli

#define ROLL_ELEV_MIX 0.0 //!!!!! Not used in Heli

#define ELEVATOR_BOOST 0.3 //!!!!! Used in Heli AILERON AND ELEVATOR BOOST MUST BE THE SAME

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

// RUDDER_BOOST is the additional gain multiplier for the manually commanded rudder deflection

// BOOST terms are truncated to closest 1/8 (0.125)

#define YAWKP_RUDDER 0.0625 //!!!!! Will be used in Heli

#define YAWKD_RUDDER 0.0 //!!!!! Will be used in Heli

#define RUDDER_BOOST 0.5 //!!!!! Will be used in Heli 

// The following section is for camera stabilization

// These values are untested and will need adjustment

#define CAMERA_ROLLKP 0.5

#define CAMERA_PITCHKP 0.5

#define CAMERA_YAWKP 0.5

////////////////////////////////////////////////////////////////////////////////

// Configure altitude hold

// These settings are only used when USE_ALTITUDEHOLD is enabled above.

//!!!!! Not used in Heli yet

// Min and Max target heights in meters.  These only apply to stabilized mode.

#define HEIGHT_TARGET_MIN 25.0

#define HEIGHT_TARGET_MAX 100.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.35

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

#define ALT_HOLD_PITCH_MAX 15.0

#define ALT_HOLD_PITCH_HIGH 0.0

////////////////////////////////////////////////////////////////////////////////

// Waypoint handling

//

// The Waypoint definitions and options are located in the waypoints.h file.

//!!!!! Navigation is not supported with Heli's yet

////////////////////////////////////////////////////////////////////////////////

// the following define is used to test the above gains and parameters.

// if you define TestGains, their functions will be enabled, even without GPS or Tx turned on.

//!!!!! Not tested with Heli's

// #define TestGains // uncomment this line if you want to test your gains without using GPS

////////////////////////////////////////////////////////////////////////////////

//

// !!!!! The lines below do NOTHING in heli code.

// !!!!! Just needs to be here for compatiblity and should be initialized to 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.

//!!!!! Not used with Heli's

#define RTL_PITCH_DOWN 0.0

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

// !!!!! Not applicable for heli's

#define ELEVON_VTAIL_SURFACES_REVERSED 0

[John McClelland]

Hi Marc

 

(This is John btw)

 

So your oscillations are in pitch...nose up and down but stable in roll in auto mode with no Tx inputs on your part.  But no oscillations in manual mode.  You are using the "standard" gains for roll and pitch.  These are very conservate.  I did some tests that showed you have to almost double them before you see oscillations.  If you could describe the pitch oscillations a little more it would be helpful...things like magnitude of angular rotation, period, do they damp out or there all the time, etc.

 

From what you describe, I would simply adjust PITCHTILT to zero out the backward tendency....show work.

 

I looked in the Kyosho Caliber 5 manual online and it shows a 90 degree swash.  You have 120 degrees in options.h.  Is this just a different model?

[John McClelland]

Marc

 

A couple other things....

 

How do you have the UDB mounted?  Is it mounted on foam?  Where on the heli?  Jerry's board had some indications of saturation before he did some vibration damping. 

 

Some photos of your setup could help?  The swash arrangement, how you have mounted the UDB, cabling etc.

[Marc-X]

Sorry John,
I was tired last night so I wrote Bill for simplicity ;1
I willl take some snaps on the chopper tonite, but in the meantime I
can confirm that the Cal5 is upgraded to 120 deg eCCPM. The UDB is
mounted on the "nose" atop of the battery box. I have one it this way:

I have cut a thin plastic card from an empty gunpowder box The card is
the same size as the UDB. There are holes in the corners, matching the
holes in the UDB. Through these I have zip-ties (with the lock at the
bottom of the card, then a 3 mm piece of silicone fuel tubing, then
the UDB, then another piece of fuel tubing, and finally a lock part
from another zip-tie and the leftover is trimmed flush to the zip-tie
lock. This is of course repeated in every corner.
The whole assebly is then fastned to the top of battery box with
multiple layers of double sided foam tape. If vibrations is the issue
here, i will exchange the foam tape with heavy duty Velcro (the really
fluffy stuff).


Cheers

Marc

[John McClelland]

I think a picture would help me understand this mount. I have found a 1/4"
dense foam pad (as used to wrap the Rx in many setups) velcroed to the
airframe works well. Foam tape is probably not good enouugh.

We should do some accel/gryo tests. Do you have OpenLog to record data in
flight?

Best,
John

----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>

Sent: Tuesday, August 31, 2010 3:09 AM
Subject: Re: First flight with the UDB in a nitro helicopter

[Marc-X]

John,

I don't have OpenLog, but I have ordered a XBee PRO 868Mhz development
kit. When it arrives I will log some data for you. I tried to UL some
pics of my setup, but couldn't for some reason. I sent them to your
gmail account instead.

Cheers!


Marc

On Aug 31, 6:05 am, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[Riccardo Kuebler]

Marc,

I already was interested in Xbee Pro 868MHz, but was not sure about their duty cycle.

I'm interested about your results and if this (the duty cycle limit) is not a problem for flight data transmission.

Best regards,

Ric

2010/9/1 Marc-X <marcus...@gmail.com>

[Marc-X]

Ric,

Maximum data throughput according to manufacturer is 230.4kbps. With a
max duty cycle of 10% it gives 23kbps which should be good enough if
I'm not totally out in the woods... I'm going for 19.2 kbps for my
datalink. Have I missed something here?

Marc

[John McClelland]

Thanks Marc...I have sent you a reply with some suggestions.

John
----- Original Message -----

From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>

[Marc-X]

John and Bill,

I discovered another thing that puzzles me:
Just to see how the PITCHTILT value affect the swash, I increased it
to 10.0
What happens is that the swash tilts FORWARDS an great amount when
switching on "stability" mode. This is the opposite direction of what
I expected. Everything else works in the right direction: When tilting
the helicopter, the swash compensates by tilting in the opposite
direction. The same goes for pitching...

By INCREASING the PITCHTILT value I thought I would allow for more
forward pitch, but on my setup it is the opposite. I will now DECREASE
the PITCHTILT value and perhaps use negative numbers before next
flight. This explains why my helicopter threw itself backwards in my
first flight attempt.

Will also do some more vibration damping if this seems to be
necessary.

Cheers!

Marc

On Sep 1, 3:36 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[Riccardo Kuebler]

Marc,

are you sure that you calculation is right ?

In my knowledge duty cycle is time related, so you have 10% time transmission at 230'400 (using only 19'200), not 23'040 all the time long.
I don't know (remember) how the transmit time is managed.

There was a discussion on DIYDrones some time ago.

I guess that if you want random values that could be ok, but worthless if you would like e.g. to control a tracking antenna.

Best regards,

Ric

2010/9/1 Marc-X <marcus...@gmail.com>

John and Bill,

[Marc-X]

Ric,

No, quite frankly I don't know. I guestimated ;)
We will see in a week or so. Do the other XBee products have higher
throughput?

Marc

On Sep 1, 7:38 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Marc,
>
> are you sure that you calculation is right ?
>
> In my knowledge duty cycle is time related, so you have 10% time
> transmission at 230'400 (using only 19'200), not 23'040 all the time long.
> I don't know (remember) how the transmit time is managed.
>
> There was a discussion on DIYDrones some time ago.
>
> I guess that if you want random values that could be ok, but worthless if
> you would like e.g. to control a tracking antenna.
>
> Best regards,
>
> Ric
>

> 2010/9/1 Marc-X <marcus.fah...@gmail.com>

[Riccardo Kuebler]

Marc,

I used 2.4GHz and 900MHz Xbees. They don't have a duty cycle, they transmit all the time in FHSS one and DSSS the other.

I tried both with Ardustation for tracking antenna and tracking videocam (1 and 2 :)

One time was wondering about this one : high power, but low data rate (9'600).

I was interested in this too. Very interesting, but too much expensive.

Ric

2010/9/1 Marc-X <marcus...@gmail.com>

[Marcus Fahlén]

This will be my second choice if the XBee PRO doesn't work, but I really hope it will... Not sure about the math, but thought the effective throughput would be 230kbps / 10 in single channel mode, and that it was possible to configure them to have them hop as the other XBees...

Maybe I did a big mistake here?

Marc

On Wed, Sep 1, 2010 at 11:19 PM, Riccardo Kuebler <kue...@ticino.com> wrote:

Marc,

[John McClelland]

Marc

The UDB coordinate system is marked on the board. X (Pitch) is left, Y
(Roll) is forward, and Z( Altitude) is down. Using the Right Hand Rule, a
positive Pitch rotation is nose down...a psotive Roll is roll right. Both
TILT parameters are positive (in the dist file).

The TILT parameters are offsets to the normal coordinate system...they are
not stability offsets. So the UDB is doing exactly what it is supposed to
be doing.

[Marc-X]

John,

That's good to hear. It means the helicopter did exactly what it
should do on my first test flight, namely pitch backwards, since it's
still slightly nose heavy and I had a possitive value for PITCHTILT: i
probably just had a too large value so the UDB overcompensated.

Now I have the board mounted on a 2cm thick piece of rather dense
foam, (the kind of pluck foam you get when buying a Pelican guncase).
We'll see if that makes any difference.

Cheers!

Marc

John McClelland wrote:
> Marc
>

[John McClelland]

Marc

Not quite. If you are nose heavy and a positive PITCHTILT it would go
forward. You would need a negative PITCHTILT to cancel the forward motion.

Normally PITCHTILT is very small if the heli is well balanced. I find
something like 0.5 deg is all that is needed. I would suggest you set it to
zero, get things tuned up and see which way it wants to move. If it tends
backwards add some positive PITCHTILT until it cancells out. If you are
getting large values, it probably means your CG is off and should be
corrected.

I'm not sure what a Pelican guncase is, but here is a link to the type of
foam a lot of people use to wrap their electronics with. It is what I use
to provide vibration isolation for the UDB...seems to work well.

http://www.hobby-lobby.com/foam_rubber_1_2x8x12_rc_hardware_3764_prd1.htm

I velcro the UDB to the foam. The only direct vibration path is through the
servo cables. Use the flexible type cables and leave some slack between the
frame and the UDB.

When you get telemetry working, I can send you a patch to write the accels
and gyros to the serial port. This is the best diagnostic of vibration
effects on the accels and gyros. Remember that heli vibrations are the core
reason why the original UDB did not work. It is all about vibrations when
you are talking helis.

Best

[John McClelland]

Marc

I see the link I sent is 1/2" foam...I actually use 1/4" but that is mostly
because I have little clearance between the skip plate and the bottom of the
frame.

[Marc-X]

Heli guys,

This might be the end of the flying season for me:

For some reason yet unknown, I lost tail control of my helicopter
today resulting in a fatal crash. Rotor blades, tail blades, tail
rotor shaft, main rotor shaft, feathering shaft, blade grips, and
several frame parts are the damage I have noticed so far. In fact
every bit that I scavanged from my other heli the last time I crashed
is broken. Due to my financial situation I'm not sure when I will have
this heli in the air again, but I have a birthday coming up the 30th
this month. so that gives me some hope ;)

What is most annoyoing is that I never had a chance to engage the auto
pilot. The incident happened immediately after take-off. Everything
seemed fine when suddenly the heli started to yaw to the left. I
landed to check if the gyro was in head hold mode and it was. I
increased the gain a little bit an took off again. Now everything
looked fine again, but suddenly the heli yawed hard to the left and I
had no chance to correct it. The flight ended with a spectacular
crash, luckily without any funky chicken dance.... A priliminary
investigation reveals that maybe the tail rotor drive shaft had come
loose... It certainly doesn't look right, but I have to tear the whole
thing apart to see what has happened. Luckily no one got hurt in the
incident.

A very depressed Marc.

[John McClelland]

Marc...I am so sorry about your crash...I think we were making good progress
on the heli code and once you get your heli back together, I'm sure we will
get it all to work.

So just to confirm, this had nothing to do with the UDB?

Wishing you a rapid recovery

John
----- Original Message -----
From: "Marc-X" <marcus...@gmail.com>
To: "UAVHeliBoard" <UAVHel...@googlegroups.com>
Sent: Thursday, September 02, 2010 12:15 PM
Subject: Re: First flight with the UDB in a nitro helicopter

[Riccardo Kuebler]

Marc,

I'm very sorry for that. I was following with interest your progress, wondering if it was the case to buy a bigger hely to play with UDB.

This is the main reason I consider flying hardware as consumables / disposables.

I know this is not that much comforting, but at least this attitude allowed me to continue with this great hobby for about forty years.

But a crash is still a shock ! No antidote for this.

Best regards,

Ric

2010/9/2 Marc-X <marcus...@gmail.com>

[Marcus Fahlén]

John,

No, the UDB is not to blame. Somehow I lost control over the tail.

Marc

[Marcus Fahlén]

Thanks Ric.

I am tearing the chopper apart right now to see if I can figure out what really happened.

Will report my findings.

Marc.

[Marc-X]

John and everyone else following this thread:

I think I have found the culprit:
A set screw, locking the final drive shaft to the one-way bearing had
come loose, allowing the drive belt to the tail rotor to "slip".
This was enough to loose control of the tail when doing a fast climb
out when tail authority is important. The tail gyro probably gave
maximum deflection, and the tail blades stalled because of this
slipping. This is the only fault I have found so far when
investigating this mess. I thought i could save the tail boom, but it
is bent as a banana as well...


Marc.


On Sep 2, 8:42 pm, "John McClelland" <mcclelland.j...@gmail.com>
wrote:

[John McClelland]

Thanks for the update Marc...that would do it.

[William Premerlani]

Marcus,

You have my deepest sympathies. Next time I go flying I will have a moment of silence for your heli before I take off.

Best,

Bill

[Marc-X]

Thanks for yor kind words, Bill.
I willll probably be in the air again later this weekend depending of
the availability of 600mm main blades at my LHS that's affordable to
me. Problem is that they have the market to themselves, so they can
charge almost anything for spare parts. Other things except for rotor
blades, I will fix with a little fiberglass, epoxy resin and some
carbon fibre tubing. I'll let you know and probably post some pics of
the result later.

Cheers!

Marc.

On Sep 2, 2:22 pm, William Premerlani <wpremerl...@gmail.com> wrote:
> Marcus,
>
> You have my deepest sympathies. Next time I go flying I will have a moment
> of silence for your heli before I take off.
>
> Best,
> Bill
>

[Marc-X]

Ric,

I can now confirm that you are right, I'm wrong, but there IS light in
the tunnel in for of an easy "fix":

The XBee PRO stops sending data after 6 minutes of transmission, (A
counter onboard counts up to 0x64 and then shuts down transmission.
I have solved this temporarily by using a PIC chip to force a hard
reset on the XBee. A very quick and dirty way to do it but it works
OK.
The best way I can think of, getting around this problem would be to
modify the serialIO.c in MatrixPilot to send the reset command through
the UART instead of doing it the "hard ware way". But since my
Assembler skills are far better than my C skills, I had to do it like
this.
Hopefully I can get the UART way working, or someone else might be
interested in adding these few lines to the serialIO.c source?
I couldn't get the 2. part below working with regard to guard time so
I scrapped the C writing...

For one who knows his C, it shouldn't take more than 30 minutes to
hack it together... but 30 minutes is valuable when there is only
24h / day and we have a long list of desirable options with higher
priority...

Anyway, what must be be done is something like:

In the serial debug transmission code implement an OPTIONAL function
loop that
1. Using a timer, count down < 6 minutes TX time
2. Then send the escape sequence (+++) through the UART with regard to
a minimal guard time of 2ms before and after each character. (Guard
time is configurable in the XBee between 2 and 3300 ms)
3. IF "OK" next, else JMP 2.
4. Send the reset command ("ATFR")
5. Listen for the confirmation string ("OK")
6. IF "OK", JMP 6, else JMP 2.
7. Continue whatever it was doing...

It might look cleaner to read the Duty Cycle counter, but I think it
takes far more time than a regardless reset. We don't need to bother
buffering any data either since we are really only interested in
recent data on the GCS, so let's just throw it in the bit bucket...

To expand this "XBee control scheme" in the UDB, you could also adapt
your output power based on your "HOME" distance and sending the
appropriate commands to the XBee. (ATPL 0-4) which regulates output
power between 1mW - 300mW. This is on MY todo list, but I have to
learn C first ;)
This would make these 868 PRO XBees more "user friendly" for us, but
at the same time users in the European union will break the laws if
exceeding a TX duty cycle of 10%.... serious business...

By the way, the duty cycle has NOTHING to do with heat build-up as
reported elsewhere, this has been confirmed by Digi / MaxStream.

Cheers!

Marc

On Sep 1, 7:38 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:

> Marc,
>
> are you sure that you calculation is right ?
>
> In my knowledge duty cycle is time related, so you have 10% time
> transmission at 230'400 (using only 19'200), not 23'040 all the time long.
> I don't know (remember) how the transmit time is managed.
>
> There was a discussion on DIYDrones some time ago.
>
> I guess that if you want random values that could be ok, but worthless if
> you would like e.g. to control a tracking antenna.
>
> Best regards,
>
> Ric
>

> 2010/9/1 Marc-X <marcus.fah...@gmail.com>

[Riccardo Kuebler]

Marc,

that's great news ! I mean the fact you will be able to have them working.

I find so stupid to have a device blocking after 6 minutes, if you can restart it again and have it working for other 6 minutes, so several times in an hour, what about the real efficiency of a duty cycle ?.

In the Swiss regulation it is well written that you have to stay in that duty cycle.

Anyway here 868MHz is allowed for non specific SRD up to 25mW, 100% duty cycle, and up to 500mW, 10% duty cycle.

This frequency is used for RFID, wireless audio, alarms...

I'm wondering if setting power to increase with distance, which could be a great solution not wasting power, could jam the RC receiver. When you are far away, with a low RC signal, you output the more power. This frequency is very near the exact double of 433MHz (the frequency most of us use for long range flights) : armonics ?

I don't understand what "multiple transmission, acknowledgement" means. The other modules are DHSS or FHSS, which means they are disturb resistant and not disturbing, what about the 868MHz module ?

I whish you will be able to have them working satisfactory :)

Best regards,

Ric

2010/9/14 Marc-X <marcus...@gmail.com>

[Marc-X]

On Sep 14, 8:34 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Marc,
>

> that's great news ! I mean the fact you will be able to have them working.
>
> I find so stupid to have a device blocking after 6 minutes, if you can
> restart it again and have it working for other 6 minutes, so several times
> in an hour, what about the real efficiency of a duty cycle ?.
>

I have had a "session" logged to disk from my bench setup:

2 pcs XBee 868 PRO
XBee modules sitting 100cm appart
Powerlevel:0 (1mW)
MAC Retries=A (10)
Multi transmit=0
Baudrate=19200
TELEMETRY FORMAT = "ArduStation" running at "full throttle" (40Hz)
The setup uses NO GPS so the position is LAT / LON is only single
character (0) in the captured data.
The data is captured using "TeraTerm" on a machine running WinXP.
Two sessions were run, the first with the UDB sitting at a NEGATIVE 45
degree tilt angle creating slightly more data in the stream. (3 bytes
for each RLL output).
The second run was with the UDB sitting LEVEL. (1 byte for each RLL
output)

The amount of data captured to disk during FIRST "session" (from RESET
to Duty Cycle=0x64)
is reported by WinXP to be 839.009 bytes (839.680 bytes on disk).

The amount of data captured to disk during SECOND "session" (from
RESET to Duty Cycle=0x64)
is reported by WinXP to be 837.984 bytes (839.680 bytes on disk).

These files are captured as "TRUE TEXT FILE".
I haven't captured any files as BINARY, but could do that if you want
me to.

> In the Swiss regulation it is well written that you have to stay in that
> duty cycle.
> Anyway here 868MHz is allowed for non specific SRD up to 25mW, 100% duty
> cycle, and up to 500mW, 10% duty cycle.
> This frequency is used for RFID, wireless audio, alarms...
>

AFAIK it is the same here in Norway

> I'm wondering if setting power to increase with distance, which could be a
> great solution not wasting power, could jam the RC receiver. When you are
> far away, with a low RC signal, you output the more power. This frequency is
> very near the exact double of 433MHz (the frequency most of us use for long
> range flights) : armonics ?
>

I have been thinking this myself... Obviously this has to be carefully
tested before flying with increasing power level output.

> I don't understand what "multiple transmission, acknowledgement" means. The
> other modules are DHSS or FHSS, which means they are disturb resistant and
> not disturbing, what about the 868MHz module ?
>

These are SINGLE CHANNEL and uses a protocol to retry failed
transmissions on one channel.

> I whish you will be able to have them working satisfactory :)
>
> Best regards,
>
> Ric
>

Same to you.


// Marc


> 2010/9/14 Marc-X <marcus.fah...@gmail.com>

[Riccardo Kuebler]

Marc,

great !
But the sessions you mentioned were restarted automatically by soft or did you restart them manually ?

Btw, I still don't have 868MHz Xbees. I'm wondering if buy them or not. I'm wondering about the real needs for them. For long range they could be useful for tracking antenna and telemetry realtime data, this last not very needed now. I can't read the Ardustation if I fly FPV.
For short range I contacted ACT, the 2.4GHz system I use, and Klaus tell me that he could change the software to let me transmit plain text telemetry on the return channel of this system, but not before the end of the year. I could have it then on RC system.

In short I would like to use 868MHz system, but if it work in a simply way. The most it becomes complicate, the more it can fail and flying FPV long range the system has to be symple and reliable.

Best regards,

Ric

2010/9/15 Marc-X <marcus...@gmail.com>

[Marcus Fahlén]

Ric,

The sessions were started by resetting the XBee manually. I just now (stopped 4 min ago) timed one "session" and it stopped after 8 min. 40 sec.

I agree that the XBee 868 PRO is overkill in most RC FPV applications, but I want to be able to explore now what the future can bring.

(I'm planning on building a large, long-range replica of the "MQ-9 Reaper" drone and then I want to go a looong way... ) 

Cheers!

Marc

[Riccardo Kuebler]

Marc,

8'40" : that's great news !

I'm waiting then for your plane here, then upload some swiss chocolate and send it you back :D

Ric

2010/9/15 Marcus Fahlén <marcus...@gmail.com>

[Marcus Fahlén]

Super!

Marc

[Marc-X]

Rick,

Now it's beginning to look more like it....
I just ran another logged session with the XBee's.
This time I ran the telemetry at 4Hz (one position update every
second, all other values updated 4 times per second)
The XBee Baud rate was set to 4800, otherwise all the same parameters.

This achieved a whopping 36 min. 05 sec TX time. with a transferred
data amount of 571.482 bytes.
Remember that these "positions" and other values are ZERO (single
byte) in this experimental setup. Real life performance would achieve
a bit less time because of this.

Anyway, you'll get a respectable flight with continuous transmission
if you can manage with only one reported position per sec. (4Hz update
rate) This also means that my "dirty hack" with resets every other
time interval will not disturb the data as much as I first feared. The
impact seems to be minimal.
I will try some different settings for the XBee's to see if it's
possible to further increase the transfer time at 4800 baud, but I
don't expect it to be significant.
A lowering of the Baud rate to 2400 will probably achieve a full hour
of continuous data transmission. I will try this next.

Cheers!

Marc

On Sep 15, 12:02 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Marc,
>

> 8'40" : that's great news !
>
> I'm waiting then for your plane here, then upload some swiss chocolate and
> send it you back :D
>
> Ric
>

> 2010/9/15 Marcus Fahlén <marcus.fah...@gmail.com>

>
>
>
> > Ric,
>
> > The sessions were started by resetting the XBee manually. I just now
> > (stopped 4 min ago) timed one "session" and it stopped after 8 min. 40 sec.
> > I agree that the XBee 868 PRO is overkill in most RC FPV applications, but
> > I want to be able to explore now what the future can bring.
> > (I'm planning on building a large, long-range replica of the "MQ-9 Reaper"
> > drone and then I want to go a looong way... )
>
> > Cheers!
>
> > Marc
>

> > On Wed, Sep 15, 2010 at 9:44 AM, Riccardo Kuebler <kueb...@ticino.com>wrote:
>
> >> Marc,
>
> >> great !
> >> But the sessions you mentioned were restarted automatically by soft or did
> >> you restart them manually ?
>
> >> Btw, I still don't have 868MHz Xbees. I'm wondering if buy them or not.
> >> I'm wondering about the real needs for them. For long range they could be
> >> useful for tracking antenna and telemetry realtime data, this last not very
> >> needed now. I can't read the Ardustation if I fly FPV.
> >> For short range I contacted ACT, the 2.4GHz system I use, and Klaus tell
> >> me that he could change the software to let me transmit plain text telemetry
> >> on the return channel of this system, but not before the end of the year. I
> >> could have it then on RC system.
>
> >> In short I would like to use 868MHz system, but if it work in a simply
> >> way. The most it becomes complicate, the more it can fail and flying FPV
> >> long range the system has to be symple and reliable.
>
> >> Best regards,
>
> >> Ric
>

> >> 2010/9/15 Marc-X <marcus.fah...@gmail.com>

> ...
>
> read more »

[Marc-X]

Ric,

With a baud rate of only 2400 I had the XBee running for a full hour.
What happened next puzzles me a bit however: (well really not when
thinking how the duty cycle probably is calculated)

The session ran for 1hour 16 sec. then stopped and had a pause of 6
min. I had a hope that If you could achieve a continuous hour you wold
be "home free", but NO.
The duty cycle doesn't reset on the hour mark as I had hoped. Anyway,
it's possible that 2400 baud is not high speed enough if you have the
full data set. I haven't tried to do any calculations, and will
probably not do it either since I tend to miss something anyway, so
it's essential a waste of time ;)

The session transfered approx 165.000 bytes (I missed to stop the log
before the duty cycle timed out and the data started to flow again.
Every other parameter is set up as before.
The value I used for U1BRG to achieve 2400 Baud = 103 (just followed
the trend here, not knowing what I was doing as usual with C :)
Hope this is useful for you (or someone else). It's not especially
useful for me or my thought application, since I'm aiming for the
"real time" feel in the data readout.
It's however interesting to see how these XBees behave in different
situations.

We now know that the 868 XBee PRO is useful for long-range, high-speed
data transmissions for real-time readout, IF we construct a device or
method for time-lapsed resetting, thereby violating the laws in
certain areas (Europe). I'm not sure how the usage of single channel
868 MHz devices are regulated in other parts of the world.


Cheers!

Marc

On Sep 15, 12:02 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Marc,
>

> 8'40" : that's great news !
>
> I'm waiting then for your plane here, then upload some swiss chocolate and
> send it you back :D
>
> Ric
>

> 2010/9/15 Marcus Fahlén <marcus.fah...@gmail.com>

>
>
>
> > Ric,
>
> > The sessions were started by resetting the XBee manually. I just now
> > (stopped 4 min ago) timed one "session" and it stopped after 8 min. 40 sec.
> > I agree that the XBee 868 PRO is overkill in most RC FPV applications, but
> > I want to be able to explore now what the future can bring.
> > (I'm planning on building a large, long-range replica of the "MQ-9 Reaper"
> > drone and then I want to go a looong way... )
>
> > Cheers!
>
> > Marc
>

> > On Wed, Sep 15, 2010 at 9:44 AM, Riccardo Kuebler <kueb...@ticino.com>wrote:
>
> >> Marc,
>
> >> great !
> >> But the sessions you mentioned were restarted automatically by soft or did
> >> you restart them manually ?
>
> >> Btw, I still don't have 868MHz Xbees. I'm wondering if buy them or not.
> >> I'm wondering about the real needs for them. For long range they could be
> >> useful for tracking antenna and telemetry realtime data, this last not very
> >> needed now. I can't read the Ardustation if I fly FPV.
> >> For short range I contacted ACT, the 2.4GHz system I use, and Klaus tell
> >> me that he could change the software to let me transmit plain text telemetry
> >> on the return channel of this system, but not before the end of the year. I
> >> could have it then on RC system.
>
> >> In short I would like to use 868MHz system, but if it work in a simply
> >> way. The most it becomes complicate, the more it can fail and flying FPV
> >> long range the system has to be symple and reliable.
>
> >> Best regards,
>
> >> Ric
>

> >> 2010/9/15 Marc-X <marcus.fah...@gmail.com>

> ...
>
> read more »

[Marc-X]

Ric and anyone else listening,

Last report of the "quick-and-dirty" RESET method for "extending" the
XBee TX duty cycle:
This does NOT work as expected!

I really built a small device tonite, using a PIC16F630 and a small
relay to emulate the RESET button.
I used relay cycling times from 200ms up to 2 sec. in intervals of
200ms without success.
What happens is that after a reset the XBee is in an unknown state. It
can be either transmitting, or not...
If this is a firmware feature or not is hard to tell... I had observed
that sometimes the Bee needed several hits on the reset switch, but I
suspected my micro switch to be faulty, or very bouncy. There might
still be bouncing in the relay throw when engaging, but I really
expected this to work... Sh*T!

I even tried to use the relay to power toggle the Bee with the exactly
same result.

Now my only hope to get this to work as I hoped is the more "elegant"
way, namely trough the UART. That MUST work! The tricky part is to
send the escape characters at the correct rate (for me that is) For
anyone used to C programming it should be done in a "few" minutes.


Cheers!

Marc

On Sep 15, 12:02 pm, Riccardo Kuebler <kueb...@ticino.com> wrote:
> Marc,
>

> 8'40" : that's great news !
>
> I'm waiting then for your plane here, then upload some swiss chocolate and
> send it you back :D
>
> Ric
>

> 2010/9/15 Marcus Fahlén <marcus.fah...@gmail.com>

>
>
>
> > Ric,
>
> > The sessions were started by resetting the XBee manually. I just now
> > (stopped 4 min ago) timed one "session" and it stopped after 8 min. 40 sec.
> > I agree that the XBee 868 PRO is overkill in most RC FPV applications, but
> > I want to be able to explore now what the future can bring.
> > (I'm planning on building a large, long-range replica of the "MQ-9 Reaper"
> > drone and then I want to go a looong way... )
>
> > Cheers!
>
> > Marc
>

> > On Wed, Sep 15, 2010 at 9:44 AM, Riccardo Kuebler <kueb...@ticino.com>wrote:
>
> >> Marc,
>
> >> great !
> >> But the sessions you mentioned were restarted automatically by soft or did
> >> you restart them manually ?
>
> >> Btw, I still don't have 868MHz Xbees. I'm wondering if buy them or not.
> >> I'm wondering about the real needs for them. For long range they could be
> >> useful for tracking antenna and telemetry realtime data, this last not very
> >> needed now. I can't read the Ardustation if I fly FPV.
> >> For short range I contacted ACT, the 2.4GHz system I use, and Klaus tell
> >> me that he could change the software to let me transmit plain text telemetry
> >> on the return channel of this system, but not before the end of the year. I
> >> could have it then on RC system.
>
> >> In short I would like to use 868MHz system, but if it work in a simply
> >> way. The most it becomes complicate, the more it can fail and flying FPV
> >> long range the system has to be symple and reliable.
>
> >> Best regards,
>
> >> Ric
>

> >> 2010/9/15 Marc-X <marcus.fah...@gmail.com>

> ...
>
> read more »

[Chad Amonn]

Hey guys this is Chad (robocopter) I need to buy some xbees and I wanted to check with you first. I am aiming for maximum distance without compromising data rate. I would like to eventually log detailed flight data in real time in order to make a flight dynamics model. Also it would be cool to be able to control the plane/heli through the xbees.
Hope you guys can point me in the right direction. Btw I'm sorry I am putting this message in the wrong spot, I'm writing from my phone.

[Marcus Fahlén]

What is your range NEEDS? I see you write MAXIMUM distance, but there is always some sort of sacrifice involved choosing radio modems. Are you aiming at 1 - 10km, 10 - 20km, 50 - 80km or even more. How large is your budget? (There are quite large differences in price for radio modems, but the XBees are limited upwards at approx. US$ 90 pp.

What country do you live in and what restrictions do you have there?

There is more to this than "just" range and throughput...

As a starting point I would suggest you looking at 900 XBee PRO, This is good for up to 10km with a throughput of up to 156kbits /sec.

They don't have any duty cycle compared to the 868 XBee PRO which is the most powerful of all the XBee's

Marc

[Chad Amonn]

Hey Marc, thanks for your fast reply. I live in the united states and I was hoping to be be able to get both modules for around 200  us dollars. I really don't know much about the restrictions here but I think most xbee modules are safe. Most of my applications for it would be within 2 miles range but it would be nice to take things to 5 miles (~8km) when everything on my uav plays nicely. Some of my concerns about the 2.4 GHz and 900 MHz modules are that I have a 2.4GHz spectrum dx7 transmitter and I am using a 900 Mhz down link for my fpv gear. I wouldn't want the xebecs to interfere on either of these channels. Does this make you think a particular model would be good for me? Also, is the 868 a European version? Thanks.  

[Marcus Fahlén]

Hello Chad,

The 868 is most likely for the European market...

The XBee 900 will obviously collide with your video down link.

Most of the FPV'ers here use 450 Mhz radio gear, 5.2, 2.4 or 900 Mhz video and whatever is left for data.

All XBees I know about, except the 868 is 2.4 GHz or 900MHz, so you will have the obvious risk of collisions even if using FHSS.

I'm not sure about how the 2.4 GHz XBee will interact with a FHSS RC radio.

Marc

[Riccardo Kuebler]

Hi,

the 2.4GHz Xbee is DHSS, but anyway is not recommended to have a tx so near a RC rx which has to manage with a low level signal.

Are you going to 5 miles with a 2.4GHz RC ? I'm not very sure ...

Better a 433MHz system.

Ric

2010/9/17 Marcus Fahlén <marcus...@gmail.com>

[Marcus Fahlén]

Hi guys!

Here is another report of my testing of the 868 PRO XBee for telemetry use. The 868 PRO is the most powerful XBee module ever produced, and therefore ideal as a telemetry link (I thought). The problem with them as most of you now know, is that they have a 10% duty cycle, meaning that they only transmits effectively for 6 minutes per hour. There is however a way around this problem since they set the count to 0 again when doing a reset. This can be done via AT commands through the same UART the telemetry is sent. 

Yesterday night I did a"nor very scientific" range test of my XBee setup in the helicopter. Just wanted to see if they were as good as it seems in an urban environment. 

I had the XBee mounted to the development board (RS-232) with a loop-back adapter attached to it. The board is attached to the boom braces, just behind the main mechanics. The antenna on the drone is a 83mm long "wire whip" and it's pointing down towards the ground. This I think is the best way of mounting the XBee with the developmet board. Later I will get a "XBee Explorer" or similar, and mount it to the horizontal stabilizer, still with the antenna pointing down.

I drove to a place where I could place the helicopter in a "less than ideal place", to get both LOS and non-LOS measurement. It ended up in a construction area close to where I live, just a few km down the road. I placed the helicopter standing on top of a steel container (the type used for storing tools and materials). The height above ground was approx 2m.

In the car I had my toughbook with the other XBee sitting an an USB development board. This one had a magnetic antenna sitting on the roof. The best antenna I could find at home was a small cellular phone antenna (used for signal boosting in home alarm systems) This whip is 190mm long with a 4 turn coil, 8mm in outside diameter close to the base (13mm). The coil itself is 15mm long. I'm aware that this antenna probably isn't giving me the best possible signal quality, but it outperformed the supplied "duck" antenna anyway.

First I started to drive round with the XBee's set to 1mW TX power, but I anly got a few Km before the link was lost.

I turned up the TX power to max (300mW), and that was a different story. (How nice it is to be able to configure the XBee's over the air!)

I drove down to the local gas station to get me something to drink, and still had good reception! 8some lost packets, but what the heck,  most of the packets got through. This was over a distance of more than 4.28Km NON line of sight! Remember that the helicopter was not sitting on high ground compared to where I was driving.

I then crossed the bridge over to the Tromsoe Island, and there I got full signal strength because I was in line of sight, and 30 meters above the place where I parked the helicopter, Still with a lot of junk around obstructing the view. Even when driving around "downtown" between a lot of buildings (most of them 4 stories high with rather narrow streets), I got acceptable reception. Well ther were still some lost packages, but I had a 90% rate of receives packages. The XBee wasn't set to re-transmit on failure. 

NOW I only have figure out how to reset the XBee's every 6 minutes or so to deal with the pesky duty cycle". I have written most of the code, but I can't get the timing right. (I need a loop that wastes 5-10 ms from terminating the telemetry data stream and the escape characters sent to the XBee. (the so called guard time is configurable down to 2ms). That means I have to stop the telemetry output for at least 2ms and then send the escape sequence (+++ as default). Then it's just to send whatever command you like to the XBee module for whatever you want to do. You can for example adjust the output power based on the range to the drone, or the RSSI signal quality.I have mots of the code in place, but I fail when trying to code the timing loop. (C isn't my primary language :)

Below I attach some pictures from Google Earth so that you can get a better picture of my "test environment".

Cheers!

// Marc