Replies to This Discussion

Permalink Reply by Bill Jowitt on February 26, 2012 at 8:06am

Robert - so what about the initial transition from Stabilise to Loiter? Should we have a Stab_I value to build up a wind compensation (drawn from the attitude on invoke?)? What about the current entry criteria? I understand those to be that you can't have user input (i.e. manually holding it in place, giving it an attitude). Unless I am doing something wrong, at the moment we do have a "hiccup" with pitch changes and the copter being blown back in a wind. This is the problem that I am trying to describe in Issue 361. Regards, Bill

• ▶ Reply

Permalink Reply by Tomas Soedergren on February 26, 2012 at 4:59pm

Randy, Bill, Robert & Dave - thanks for joining in on the loiter policy challenge!

The friction/no friction issue is present in both strategies, since they ultimately output  attitude as the response to position error. Seems like my main objection to speed strategy is the calculation detour and presumed lag which is introduced by the speed management. But I can see the advantage regarding transition (to traverse) I-term transfer. Possibly also in optical flow sensor fusion (?).

However, there is one thing I do have a firm opinion about: When commanding loiter entry while copter is in a fairly steady state (stationary hover) the lat/lon attitude at entry should be used as a attitude reference /I-term bias/ to start out from. I support Bills issue on this (please see issue tracker).

I guess the whole loiter (lateral control) task would benefit massively by the introduction of a well performing inertial reference.

• ▶ Reply

DeveloperPermalink Reply by Randy on February 27, 2012 at 11:30pm

Tomas,

     optical flow should help with the position control..just need to tune it a bit more and integrate it better in the loiter so that both GPS and optical flow can be used at the same time.

     the inertial reference argument comes up a lot but nobody's really got it working.  There's simply too much noise in the accelerometer values we use to make it work on a copter.  If you can find someone to prove me wrong we'd all be very happy!!

     I'm not sure about the lag argument..the control loops run very very quickly...whether there's one or two or three in series, it's milliseconds in any case.

• ▶ Reply

Permalink Reply by Tomas Soedergren on February 28, 2012 at 3:45pm

Randy,

Ok about optical flow

By the way, have you studied the HeliCommand Profi? Captron (the manufacturer) was a pioneer in using optical flow for position holding and ground speed management.They also use optics for low level height measurement (up to max 3m, I think). I have one of these units on my MaxiJoker 2 photo ship. One can choose to select optical / optical+GPS / GPS as position reference using one of the control channels. I does "seamless" transition if optic conditions are insuffiecient, but if one know from the beginning that it will have difficulties (over water, snow, trees / roofs), better to disable optic and just use GPS (which works good!)

Another feature to take note about, regarding HeliCommand Profi, is that they have got a pressure port that connects to the pickup via tubing, so you can mount it at the point (normally close to rotor shaft) that offers the least disturbed air. That solution should be considered for APM too, especially for use in trad heli.

About inertial reference.

Yeah I have heard about the noise problem. Still, this method has been applied in rockets and aircrafts for a long time. And a rocket with engines engaged surely comes with extreme vibrations. Suspension might be one part solution and robust filtering (Kalman?) another part.

The lagging I referred to would not be due to the control loop; rather by the GPS update interval. Speed calculation needs at least two readings, while position just requires one. By the wandering nature and relatively low resolutionof GPS position readings it seems to me like the precision in speed calculated from this would be relatively low, compared with the precision of the reported position deviation. Though, I lack the mathematical means to prove that.

Tomas

• ▶ Reply

Permalink Reply by Dave C on February 28, 2012 at 4:03pm

Great info Tomas thanks, optical flow is my next big project (i.e. listen to what everyone is saying and then test it to death)

Keep talking :)

• ▶ Reply

Permalink Reply by Gustav Kuhn on February 26, 2012 at 3:55am

I've just loaded the latest code and hovered around the garden a bit.

Only used Stabilize mode, is VERY stable.

Thanks dev team !

• ▶ Reply

Permalink Reply by PACEFE on February 26, 2012 at 4:05am

HI,

     roll and pitch angle are converter from RC to a max of 45 degrees:

Radio,pde

    g.rc_1.set_angle(4500);
    g.rc_2.set_angle(4500);

But later are constrained to 25 degrees:

Arducopter.pde

#else

    // limit the error we're feeding to the PID
    target_angle         = constrain(target_angle, -2500, 2500);

This means that joystick usefull travel is only about 40%.

Wouldnt it be better:

Radio.pde:

#if FRAME_CONFIG == HELI_FRAME

    g.rc_1.set_angle(4500);
    g.rc_2.set_angle(4500);

    #else

    g.rc_1.set_angle(2500);
    g.rc_2.set_angle(2500);

#endif

Can we get banking angle adjustable from Mission Planner?

Pablo

• ▶ Reply

Permalink Reply by PACEFE on February 26, 2012 at 5:17am

Can we get a speed limitation in stabilized mode?

I would be nice to be able to travel at a certain adjustable speed also in stabilized mode.

Can some of the Gurus provide a way to calculate the forward and lateral speed of the copter?

Regards,

Pablo

• ▶ Reply

DeveloperPermalink Reply by Randy on February 27, 2012 at 11:27pm

PACEFE,

     don't know if you'll see this reply as this thread moves quickly.  ..anyway, what you've missed is that at the top of the get_stabilize_roll function it changes teh meaning of target_angle to actually mean angle error (slightly bad form I know!).  So the 25 degree constraint is a constraint on the difference between what your radio says and what the attitude of the copter is.

// angle error

target_angle = wrap_180( target_angle - dcm.roll_sensor );

 

• ▶ Reply

Permalink Reply by PACEFE on February 28, 2012 at 12:19pm

Thanks Randy!

                            I`ve noticed it long after posting.

For a newby like me is a very interesting way of programming. Apples can become Bananas at any time ;-)

• ▶ Reply

Permalink Reply by RickP on February 26, 2012 at 7:44am

I've been tuning git-latest (7956f84e8...) on a jdrones hexa with the 880kv motors. Whilst its improving with tuning - the most disappointing thing is that it feels far worse just hovering than a month back. I've changed the APM2 mount to the recommended mount (o-rings) as though it flew ok before, it was suffering from the 'leans' over a floght. I've changed the leg mounts to get the CoG more central. Both of those should improve matters I thought.

I ended up with Stab P of 4.5, Rate P of 0.10, no I and Stab D of 0.01. Whilst it hovers okay for a while (even hands free), it will suddenly lurch off in a direction and occasionally oscillates. Its leaving me with little confidence and no inclination to go and test alt-hold and loiter :(

• ▶ Reply

Permalink Reply by romeo on February 26, 2012 at 9:07am

octa x468hd APM2 default pid's . alt_hold is ok 20-30cm, loiter no sign of such work. increase the P?  gps is 3d-solid blue.

• ▶ Reply

• ‹ Previous
• 1
• …
• 40
• 41
• 42
• 43
• 44
• …
• 90
• Next ›
• Page