Re: [Autopilot] Successful compilation under Fedora Core 5 (thanks, Juergen)!

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Go to https://lists.sourceforge.net/lists/listinfo/autopilot-devel which is
at the bottom of every post, and one of the options is to enter your email
to be unsubscribed.

Best regards,

On 5/7/07, ak...@ao... <ak...@ao...> wrote:
>
> Can somone please remove my email address from this list. I have been
> trying to be removed for a long time. please remove my email or if someon=
e
> can guide me on how to have my email removed.
> Thank you.
>
>
> -----Original Message-----
> From: wil...@ya...
> To: aut...@li...
> Sent: Wed, 2 May 2007 9:42 PM
> Subject: Re: [Autopilot] Successful compilation under Fedora Core 5
> (thanks, Juergen)!
>
> Since my last message I have made a lot of mistakes and, maybe, a little
> progress.  I
> currently have a simulator that responds in the correct direction to roll=
 and
> pitch
> commands, but does not respond to collective and yaw.  Actually, that is =
not
> quite true
> because raising the collective to 3/4 of full travel causes a sudden, sha=
rp roll
> into the
> ground.  The text written to stdout when sim is running makes some sense =
in that
> pitch
> stick movement causes "axis=3Dpitch ..." data to be written out; same wit=
h roll
> and
> collective stick movement.  Orientation changes are occurring, but I'm no=
t sure
> about
> translation.  Roll and pitch responses do not have the feel of a "real" h=
eli.
> Here's what
> I have done:
>
> The calibration program has never worked correctly.  See my prior message=
 for
> the behavior
> I have observed.  I'm not sure why, but this may have something to do wit=
h how
> it
> interprets joystick button commands.  An r/c transmitter, obviously, does=
 not
> include
> joystick buttons.  The Mile High Windows USB Interface calibration progra=
m seems
> to cause
> some transmitter functions to emulate buttons.  In particular, the Flight=
 Mode
> switch
> causes buttons 2 and 4 to be toggled, with one always "on" and one "off".
> Perhaps the sim
> calibration program, when it starts, sees an "on" button and blows right =
through
> the
> collective calibration lines.  The Mile High program seems to permit rese=
tting
> of the
> Interface to some factory preset that does not include buttons, only the =
four
> primary
> controls.  I have done this.  This permits the sim calibration routine to=
 work
> after a
> fashion, but, with no buttons, it won't work completely correctly.  Compi=
ling
> calibration.c in verbose mode permits extraction of some information from=
 the
> program.
> But if this program were changed to capture data upon, say, pressing of c=
arriage
> return,
> it might work correctly in this setting.
>
> Perhaps I'm getting a little ahead of myself.  I have done the following:
> 1.  reset the USB Interface
> 2.  unzip the download
> 3.  make these changes to calibrate.c:
>     Line 37:  verbose =3D 1
>     Line 144:  if( 1 )
> In verbose mode, calibration.c writes the following ("stick" refers to th=
e
> actual
> transmitter stick):
> stick       axis    min     @ stick position    max     @ stick position
> collective  0   -32767      down            29052       up
> roll        1   -28377      right           31416       left
> pitch       2   -30404      nose up         30403       nose down
> yaw     3   -30066      right           28714       left
>
> Actually, calibrate.c often writes out an additional least significant di=
git
> that appears
> to be garbage.
>
> Based upon this information and some trial-and-error regarding directiona=
lity
> (e.g., is
> the positive or negative number roll right?), I made changes to two secti=
ons in
> heli-stick.c:
>
> Beginning with Line 100:  This section is followed by the comment, "These=
 will
> have to be
> re-ordered if the joystick changes.  Bummer."  Cryptic.  Apparently, this=
 matrix
> assumes
> that the first row is axis 0, the second row is axis 1, and so on.  In my=
 case,
> axis 0 is
> collective, etc.  So I reordered this matrix, along with my guesses about
> limits, as follows:
> #else
>          { "coll",        29052, -32767 },
>          { "roll",       -28377, 31416 },
>          { "pitch",       30403, -30404 },
>          { "yaw",        -30066, 28714 },
> #endif
>
> Beginning with Line 320:
> As J=FCrgen suggested, these sections were modified to assign correct tra=
nsmitter
> sticks to
> program axes:
>                       if( sdlEvent.jaxis.axis =3D=3D 2)      {
>                          /* main rotor longitudinal tilt */
>                              getAx =3D sdlEvent.jaxis.value;
>                              /* fprintf(stderr, "axis 2 value  %i \n",get=
Ax); */
>                              handle_axis(2,getAx);
>                       }
>                       if( sdlEvent.jaxis.axis =3D=3D 1)      {
>                          /* main rotor lateral tilt goes here */
>                              getAx =3D sdlEvent.jaxis.value;
>                              /* fprintf(stderr, "axis 1 value  %i \n",get=
Ax); */
>                              handle_axis(1,getAx);
>                       }
>                       if( sdlEvent.jaxis.axis =3D=3D 0)      {
>                          /* collective goes here */
>                              getAx =3D sdlEvent.jaxis.value;
>                              /* fprintf(stderr, "axis 0 value %i \n",getA=
x); */
>                              handle_axis(0,getAx);
>
> As predicted by one of the readme's, ./bin/sim, which brings up three win=
dows,
> runs very
> slowly on my machine (1.3 MHz AMD Duron; in fact, I wonder if this limita=
tion
> may turn out
> to frustrate the effort to get a workable simulator running on my box).  =
This
> readme
> suggests trying on slow machines a script that includes:
>          ./bin/heli-sim &
>          ./bin/heli-3d -geometry 200x200 &
>          ./bin/hover &
> This brings up a window with a heli that is unresponsive in all axes.  Af=
ter
> some
> trial-and-error, I modified ./bin/sim to be:
> #!/bin/sh
> # $Id: sim,v 1.4 2002/06/02 00:48:06 tramm Exp $
>
> (
>          sleep 1;
>          ./bin/heli-3d           -geometry 512x512+300+10 -3 &
>          ./bin/heli-stick &
> ) &
>
> ./bin/heli-sim
> killall heli-stick
>
> The heli in this window behaves as described at the head of this message.
>
> So, that's where I am:  some vaguely realistic pitch and roll orientation
> control, bizarre
> collective control, and, of course, no yaw control because the transmitte=
r's yaw
> stick
> does not emulate joystick buttons.  I have tried many, many things, but I=
 just
> reproduced
> the above steps on a freshly unzipped download file and observed the same
> behavior, so I
> think the above is correct and correct.  Any suggests for further tinkeri=
ng?
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> http://autopilot.sourceforge.net/     Development mailing list
> https://lists.sourceforge.net/lists/listinfo/autopilot-devel
>
>  ------------------------------
> AOL now offers free email to everyone. Find out more about what's free
> from AOL at *AOL.com* <http://www.aol.com?ncid=3DAOLAOF00020000000437>.
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> http://autopilot.sourceforge.net/     Development mailing list
> https://lists.sourceforge.net/lists/listinfo/autopilot-devel
>
>

--=20
Fabio Miguez