Commanded vs measured roll and pitch angles

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Commanded vs measured roll and pitch angles

Steven Bellens
Hi,

I'm experiencing significant differences between the roll/pitch angles
I send to the Asctec Pelican (using the serial interface) and roll and
pitch angles I measure (using an external, high accuracy, measurement
unit). The helicopter however does fly stable, but I'd like to know
more about the onboard LL controller which can explain those
differences. Does anyone know how these differences can be explained?
Graph considering pitch input (commanded) vs pitch measured in
appendix. I should note that this graph is the result of an experiment
in which the helicopter travelled about 15cm in X-direction in the
first 30seconds, after which it kept its position.
Also, I noticed that, when fixing (by pushing manually) roll/pitch
angles, the actual angle even gets bigger then the commanded one,
which is basically the reverse effect as shown in the graph?!

Regards,

Steven

plot.png (35K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

bouffard
Maybe it's just me, but the attachment doesn't work when viewing your message in gmail. I have to click to the thread on nabble and then click the "download attachment link".

Anyway, I've done some very preliminary system i.d. and noticed something similar though I don't have the sign reversal you have--I'm guessing that's just coming from a difference in axis convention between command and measurement. Off the top of my head I don't remember which axes I had to flip but there are definitely differences between the standard (IMO) convention (x forward, y starboard, z down, with positive roll, pitch, yaw being defined as rotations about the positive x, y, z axes respectively, i.e. as per http://en.wikipedia.org/wiki/Flight_dynamics_(aircraft)) and what AscTec uses. Given that this doesn't seem to be documented anywhere maybe it would be good to add a wiki page clearly laying out the conventions.

Anyway I did some step response tests, giving 5 and 10 degree step pitch/roll inputs. I found that the actual angle would end up at a steady state of only about 50% of the command. Initially I suspected a bug somewhere or misinterpretation of the command scaling (see http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some info on command scaling btw). I'm pretty sure that wasn't the case though, based on commanding to various angles with thrust set to zero (but props spinning), manually rotating the Pelican to near the commanded angle, and feeling that the restoring torque was zero at the commanded angle. You should probably check the same things. At this point I'm not sure what's responsible for the large steady state offset; I believe that the attitude controller is a PD controller so s.s. offset is possible (no integral action) but there should be some physical explanation. One possibility is an aerodynamic effect called blade flapping though I'm not sure if it's significant enough to explain what's been observed.

AscTec could help here if they can provide some details on the attitude controller, and/or any model identification they have for the Pelican. It would be beneficial to everyone if we could work together to build a canonical model of the Pelican.

Cheers,
Pat

On Tue, May 17, 2011 at 6:14 AM, Steven Bellens [via asctec-users] <[hidden email]> wrote:
Hi,

I'm experiencing significant differences between the roll/pitch angles
I send to the Asctec Pelican (using the serial interface) and roll and
pitch angles I measure (using an external, high accuracy, measurement
unit). The helicopter however does fly stable, but I'd like to know
more about the onboard LL controller which can explain those
differences. Does anyone know how these differences can be explained?
Graph considering pitch input (commanded) vs pitch measured in
appendix. I should note that this graph is the result of an experiment
in which the helicopter travelled about 15cm in X-direction in the
first 30seconds, after which it kept its position.
Also, I noticed that, when fixing (by pushing manually) roll/pitch
angles, the actual angle even gets bigger then the commanded one,
which is basically the reverse effect as shown in the graph?!

Regards,

Steven

plot.png (35K) Download Attachment



If you reply to this email, your message will be added to the discussion below:
http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2952441.html
To start a new topic under asctec-users, email [hidden email]
To unsubscribe from asctec-users, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

Bill Morris
Administrator
On Wed, 2011-05-18 at 11:48 -0700, bouffard [via asctec-users] wrote:

> Anyway I did some step response tests, giving 5 and 10 degree step
> pitch/roll inputs. I found that the actual angle would end up at a
> steady state of only about 50% of the command. Initially I suspected a
> bug somewhere or misinterpretation of the command scaling
> (see http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some info on
> command scaling btw). I'm pretty sure that wasn't the case though,
> based on commanding to various angles with thrust set to zero (but
> props spinning), manually rotating the Pelican to near the commanded
> angle, and feeling that the restoring torque was zero at the commanded
> angle. You should probably check the same things. At this point I'm
> not sure what's responsible for the large steady state offset; I
> believe that the attitude controller is a PD controller so s.s. offset
> is possible (no integral action) but there should be some physical
> explanation. One possibility is an aerodynamic effect called blade
> flapping though I'm not sure if it's significant enough to explain
> what's been observed.

We can confirm based on our experiments that CTRL_INPUT does not perform
as expected for roll and pitch commands. It appears that there may be a
deadband or other non-linearity.

-Bill




Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

bouffard
Hmm, I've seen a deadband in yaw as mentioned in an earlier thread,
but not roll and pitch. Maybe a difference in default parameters
between firmware builds or product releases? What did you see in your
experiments?

Cheers,
Pat

On Wed, May 18, 2011 at 12:08 PM, Bill Morris [via asctec-users]
<[hidden email]> wrote:

> On Wed, 2011-05-18 at 11:48 -0700, bouffard [via asctec-users] wrote:
>> Anyway I did some step response tests, giving 5 and 10 degree step
>> pitch/roll inputs. I found that the actual angle would end up at a
>> steady state of only about 50% of the command. Initially I suspected a
>> bug somewhere or misinterpretation of the command scaling
>> (see http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some info on
>> command scaling btw). I'm pretty sure that wasn't the case though,
>> based on commanding to various angles with thrust set to zero (but
>> props spinning), manually rotating the Pelican to near the commanded
>> angle, and feeling that the restoring torque was zero at the commanded
>> angle. You should probably check the same things. At this point I'm
>> not sure what's responsible for the large steady state offset; I
>> believe that the attitude controller is a PD controller so s.s. offset
>> is possible (no integral action) but there should be some physical
>> explanation. One possibility is an aerodynamic effect called blade
>> flapping though I'm not sure if it's significant enough to explain
>> what's been observed.
> We can confirm based on our experiments that CTRL_INPUT does not perform
> as expected for roll and pitch commands. It appears that there may be a
> deadband or other non-linearity.
>
> -Bill
>
>
>
>
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2958177.html
> To start a new topic under asctec-users, email
> [hidden email]
> To unsubscribe from asctec-users, click here.
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

Steven Bellens
Hi all,

I did some experiments to validate the LL controller.

1) Determining the relationship of commanded thrust vs measured force

I mounted the Pelican on a force sensor to determine the actual force.
Thrust commands [0..32N] are plotted vs the measured force (force
sensor) in thrust.png. As already mentioned by asctec, this
relationship is _not_ linear, but, especially around hovering
conditions, linearizing it certainly holds. The peak thrust achieved
depends heavily on the battery level. The attached graph is obtained
with an almost empty battery (replaced right afterwards). With a fully
charged one, I was able to get a peak thrust force of 29N. It never
reached the 32N as commanded however.


2) Determining the relationship of commanded roll vs measured roll angle

I'm lacking my external measurement unit this week, so I'm using the
fused IMU data from the Pelican LL controller for comparison for now
(more experiments using ground truth to follow). I made a little test
setup in which the Pelican is free to rotate only about e.g. roll
axis. The rotation axis is about the same height as the propeller
plane, and the quadrotor reacts pretty well in that test frame (I
tried before mounting it on a ball joint but as the rotation axis is
then below the Pelican, performance is very poor)
My first mistake was already the range of roll and pitch signals - I
wrongly assumed roll and pitch commands were in [-PI/2 .. PI/2 rad],
so (Patrick) thanks already for pointing me to the right information
there. I checked the new limits ([-0.9 .. 0.9 rad]) by holding the
Pelican and giving maximum roll input, which indeed satisfies the
controller at about 0.9 radians of roll rotation.
Now I tested the roll controller for changing roll inputs and did so
for various thrust levels (I noticed that the actual roll angle
depends heavily on the total thrust force). roll15.png shows commanded
vs measured roll angle for a thrust input of 15N (hover condition). I
also plotted 80% of the commanded roll, which fits pretty well with
the actual value measured. This 80% rule however does _not_ hold for
other thrust levels. I have about 73% of the commanded roll at 10N
e.g. I'm still trying to get that relationship completely for
different thrust levels. More to follow.

Regards,

Steven



2011/5/19 bouffard [via asctec-users]
<[hidden email]>:

> Hmm, I've seen a deadband in yaw as mentioned in an earlier thread,
> but not roll and pitch. Maybe a difference in default parameters
> between firmware builds or product releases? What did you see in your
> experiments?
>
> Cheers,
> Pat
>
> On Wed, May 18, 2011 at 12:08 PM, Bill Morris [via asctec-users]
> <[hidden email]> wrote:
>> On Wed, 2011-05-18 at 11:48 -0700, bouffard [via asctec-users] wrote:
>>> Anyway I did some step response tests, giving 5 and 10 degree step
>>> pitch/roll inputs. I found that the actual angle would end up at a
>>> steady state of only about 50% of the command. Initially I suspected a
>>> bug somewhere or misinterpretation of the command scaling
>>> (see <a
>>> href="http://robotics.ccny.cuny.edu/wiki/AscTecQandA for">http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some
>>> info on
>>> command scaling btw). I'm pretty sure that wasn't the case though,
>>> based on commanding to various angles with thrust set to zero (but
>>> props spinning), manually rotating the Pelican to near the commanded
>>> angle, and feeling that the restoring torque was zero at the commanded
>>> angle. You should probably check the same things. At this point I'm
>>> not sure what's responsible for the large steady state offset; I
>>> believe that the attitude controller is a PD controller so s.s. offset
>>> is possible (no integral action) but there should be some physical
>>> explanation. One possibility is an aerodynamic effect called blade
>>> flapping though I'm not sure if it's significant enough to explain
>>> what's been observed.
>> We can confirm based on our experiments that CTRL_INPUT does not perform
>> as expected for roll and pitch commands. It appears that there may be a
>> deadband or other non-linearity.
>>
>> -Bill
>>
>>
>>
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2958177.html
>> To start a new topic under asctec-users, email
>> [hidden email]
>> To unsubscribe from asctec-users, click here.
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2963360.html
> To start a new topic under asctec-users, email
> [hidden email]
> To unsubscribe from asctec-users, click here.

thrust.png (41K) Download Attachment
roll15.png (41K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

bouffard
On Tue, May 24, 2011 at 9:18 AM, Steven Bellens [via asctec-users] <[hidden email]> wrote:
Hi all,

I did some experiments to validate the LL controller.

1) Determining the relationship of commanded thrust vs measured force

I mounted the Pelican on a force sensor to determine the actual force.
Thrust commands [0..32N] are plotted vs the measured force (force
sensor) in thrust.png. As already mentioned by asctec, this
relationship is _not_ linear, but, especially around hovering
conditions, linearizing it certainly holds. The peak thrust achieved
depends heavily on the battery level. The attached graph is obtained
with an almost empty battery (replaced right afterwards). With a fully
charged one, I was able to get a peak thrust force of 29N. It never
reached the 32N as commanded however.

Interesting. I've never seen a range with real units for the thrust commands. Where did you get the [0..32N] from?

I'm curious how the commanded vs. actual force plot looks for a constant command, have you tried that? It would be interesting to see what a constant (say, hover condition) command would produce as the battery depletes. Though I suspect it might only affect the peak thrust as I haven't noticed a large variation of thrust command required for hover. Again, some insight from AscTec into what's going on under the hood would help us all here.
 
2) Determining the relationship of commanded roll vs measured roll angle

I'm lacking my external measurement unit this week, so I'm using the
fused IMU data from the Pelican LL controller for comparison for now
(more experiments using ground truth to follow). I made a little test
setup in which the Pelican is free to rotate only about e.g. roll
axis. The rotation axis is about the same height as the propeller
plane, and the quadrotor reacts pretty well in that test frame (I
tried before mounting it on a ball joint but as the rotation axis is
then below the Pelican, performance is very poor)
My first mistake was already the range of roll and pitch signals - I
wrongly assumed roll and pitch commands were in [-PI/2 .. PI/2 rad],
so (Patrick) thanks already for pointing me to the right information
there. I checked the new limits ([-0.9 .. 0.9 rad]) by holding the
Pelican and giving maximum roll input, which indeed satisfies the
controller at about 0.9 radians of roll rotation.

0.9 rad = 51.566201561774093 deg; AscTec has said "For Pitch and Roll, multiply the values with 25 millidegree (+-2047 * 25 millidegree = +-51.175 degree)." Did you get the 0.9 rad number from them or were you just rounding off (it's only 0.7% difference but still I'd rather use the exact correct value).
 
Now I tested the roll controller for changing roll inputs and did so
for various thrust levels (I noticed that the actual roll angle
depends heavily on the total thrust force). roll15.png shows commanded
vs measured roll angle for a thrust input of 15N (hover condition). I

So in terms of the thrust input is that 15/32*4095 = 1920 counts?
 
also plotted 80% of the commanded roll, which fits pretty well with
the actual value measured. This 80% rule however does _not_ hold for
other thrust levels. I have about 73% of the commanded roll at 10N
e.g. I'm still trying to get that relationship completely for
different thrust levels. More to follow.

Nice work and thanks for sharing with us. Looking forward to your next results..

Pat
 

Regards,

Steven



2011/5/19 bouffard [via asctec-users]
<[hidden email]>:

> Hmm, I've seen a deadband in yaw as mentioned in an earlier thread,
> but not roll and pitch. Maybe a difference in default parameters
> between firmware builds or product releases? What did you see in your
> experiments?
>
> Cheers,
> Pat
>
> On Wed, May 18, 2011 at 12:08 PM, Bill Morris [via asctec-users]
> <[hidden email]> wrote:
>> On Wed, 2011-05-18 at 11:48 -0700, bouffard [via asctec-users] wrote:
>>> Anyway I did some step response tests, giving 5 and 10 degree step
>>> pitch/roll inputs. I found that the actual angle would end up at a
>>> steady state of only about 50% of the command. Initially I suspected a
>>> bug somewhere or misinterpretation of the command scaling
>>> (see <a

>>> href="<a href="http://robotics.ccny.cuny.edu/wiki/AscTecQandA for&quot;&gt;http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some">http://robotics.ccny.cuny.edu/wiki/AscTecQandA for">http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some

>>> info on
>>> command scaling btw). I'm pretty sure that wasn't the case though,
>>> based on commanding to various angles with thrust set to zero (but
>>> props spinning), manually rotating the Pelican to near the commanded
>>> angle, and feeling that the restoring torque was zero at the commanded
>>> angle. You should probably check the same things. At this point I'm
>>> not sure what's responsible for the large steady state offset; I
>>> believe that the attitude controller is a PD controller so s.s. offset
>>> is possible (no integral action) but there should be some physical
>>> explanation. One possibility is an aerodynamic effect called blade
>>> flapping though I'm not sure if it's significant enough to explain
>>> what's been observed.
>> We can confirm based on our experiments that CTRL_INPUT does not perform
>> as expected for roll and pitch commands. It appears that there may be a
>> deadband or other non-linearity.
>>
>> -Bill
>>
>>
>>
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion
>> below:
>>
>> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2958177.html
>> To start a new topic under asctec-users, email
>> [hidden email]
>> To unsubscribe from asctec-users, click here.
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2963360.html

> To start a new topic under asctec-users, email
> [hidden email]
> To unsubscribe from asctec-users, click here.

thrust.png (41K) Download Attachment
roll15.png (41K) Download Attachment



If you reply to this email, your message will be added to the discussion below:
http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2980469.html
To start a new topic under asctec-users, email [hidden email]
To unsubscribe from asctec-users, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

Steven Bellens
2011/5/24 bouffard [via asctec-users]
<[hidden email]>

>
> On Tue, May 24, 2011 at 9:18 AM, Steven Bellens [via asctec-users] <[hidden email]> wrote:
>>
>> Hi all,
>>
>> I did some experiments to validate the LL controller.
>>
>> 1) Determining the relationship of commanded thrust vs measured force
>>
>> I mounted the Pelican on a force sensor to determine the actual force.
>> Thrust commands [0..32N] are plotted vs the measured force (force
>> sensor) in thrust.png. As already mentioned by asctec, this
>> relationship is _not_ linear, but, especially around hovering
>> conditions, linearizing it certainly holds. The peak thrust achieved
>> depends heavily on the battery level. The attached graph is obtained
>> with an almost empty battery (replaced right afterwards). With a fully
>> charged one, I was able to get a peak thrust force of 29N. It never
>> reached the 32N as commanded however.
>
> Interesting. I've never seen a range with real units for the thrust commands. Where did you get the [0..32N] from?

Stefan mentioned it on this mailing list in "Relation between thrust
command and resulting lift force"

<quote>
The commando equals a certain rpm of the motors. There is a rpm
controller at each brushless motor controller!

At the AscTec Hummingbird: 0-100% (0 ... 4095) equals ca. 10grams –
380grams thrust per propeller
At the AscTec Pelican: 0-100% (0 ... 4095) equals ca. 25grams –
800grams thrust per propeller

Please keep in mind that this graph is not linear! However I hope it
is a good ball park figure which enables you to control your UAV
properly.
<\quote>

>
> I'm curious how the commanded vs. actual force plot looks for a constant command, have you tried that? It would be interesting to see what a constant (say, hover condition) command would produce as the battery depletes. Though I suspect it might only affect the peak thrust as I haven't noticed a large variation of thrust command required for hover. Again, some insight from AscTec into what's going on under the hood would help us all here.

Me neither, but I'll test it anyway :)

>
>>
>> 2) Determining the relationship of commanded roll vs measured roll angle
>>
>> I'm lacking my external measurement unit this week, so I'm using the
>> fused IMU data from the Pelican LL controller for comparison for now
>> (more experiments using ground truth to follow). I made a little test
>> setup in which the Pelican is free to rotate only about e.g. roll
>> axis. The rotation axis is about the same height as the propeller
>> plane, and the quadrotor reacts pretty well in that test frame (I
>> tried before mounting it on a ball joint but as the rotation axis is
>> then below the Pelican, performance is very poor)
>> My first mistake was already the range of roll and pitch signals - I
>> wrongly assumed roll and pitch commands were in [-PI/2 .. PI/2 rad],
>> so (Patrick) thanks already for pointing me to the right information
>> there. I checked the new limits ([-0.9 .. 0.9 rad]) by holding the
>> Pelican and giving maximum roll input, which indeed satisfies the
>> controller at about 0.9 radians of roll rotation.
>
> 0.9 rad = 51.566201561774093 deg; AscTec has said "For Pitch and Roll, multiply the values with 25 millidegree (+-2047 * 25 millidegree = +-51.175 degree)." Did you get the 0.9 rad number from them or were you just rounding off (it's only 0.7% difference but still I'd rather use the exact correct value).

I rounded it.

>
>>
>> Now I tested the roll controller for changing roll inputs and did so
>> for various thrust levels (I noticed that the actual roll angle
>> depends heavily on the total thrust force). roll15.png shows commanded
>> vs measured roll angle for a thrust input of 15N (hover condition). I
>
> So in terms of the thrust input is that 15/32*4095 = 1920 counts?

Yes

Steven

>
>>
>> also plotted 80% of the commanded roll, which fits pretty well with
>> the actual value measured. This 80% rule however does _not_ hold for
>> other thrust levels. I have about 73% of the commanded roll at 10N
>> e.g. I'm still trying to get that relationship completely for
>> different thrust levels. More to follow.
>
> Nice work and thanks for sharing with us. Looking forward to your next results..
> Pat
>
>>
>> Regards,
>>
>> Steven
>>
>>
>>
>> 2011/5/19 bouffard [via asctec-users]
>> <[hidden email]>:
>> > Hmm, I've seen a deadband in yaw as mentioned in an earlier thread,
>> > but not roll and pitch. Maybe a difference in default parameters
>> > between firmware builds or product releases? What did you see in your
>> > experiments?
>> >
>> > Cheers,
>> > Pat
>> >
>> > On Wed, May 18, 2011 at 12:08 PM, Bill Morris [via asctec-users]
>> > <[hidden email]> wrote:
>> >> On Wed, 2011-05-18 at 11:48 -0700, bouffard [via asctec-users] wrote:
>> >>> Anyway I did some step response tests, giving 5 and 10 degree step
>> >>> pitch/roll inputs. I found that the actual angle would end up at a
>> >>> steady state of only about 50% of the command. Initially I suspected a
>> >>> bug somewhere or misinterpretation of the command scaling
>> >>> (see <a
>> >>> href="<a href="http://robotics.ccny.cuny.edu/wiki/AscTecQandA for&quot;&gt;http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some">http://robotics.ccny.cuny.edu/wiki/AscTecQandA for">http://robotics.ccny.cuny.edu/wiki/AscTecQandA for some
>> >>> info on
>> >>> command scaling btw). I'm pretty sure that wasn't the case though,
>> >>> based on commanding to various angles with thrust set to zero (but
>> >>> props spinning), manually rotating the Pelican to near the commanded
>> >>> angle, and feeling that the restoring torque was zero at the commanded
>> >>> angle. You should probably check the same things. At this point I'm
>> >>> not sure what's responsible for the large steady state offset; I
>> >>> believe that the attitude controller is a PD controller so s.s. offset
>> >>> is possible (no integral action) but there should be some physical
>> >>> explanation. One possibility is an aerodynamic effect called blade
>> >>> flapping though I'm not sure if it's significant enough to explain
>> >>> what's been observed.
>> >> We can confirm based on our experiments that CTRL_INPUT does not perform
>> >> as expected for roll and pitch commands. It appears that there may be a
>> >> deadband or other non-linearity.
>> >>
>> >> -Bill
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> ________________________________
>> >> If you reply to this email, your message will be added to the discussion
>> >> below:
>> >>
>> >> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2958177.html
>> >> To start a new topic under asctec-users, email
>> >> [hidden email]
>> >> To unsubscribe from asctec-users, click here.
>> >
>> >
>> > ________________________________
>> > If you reply to this email, your message will be added to the discussion
>> > below:
>> > http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2963360.html
>> > To start a new topic under asctec-users, email
>> > [hidden email]
>> > To unsubscribe from asctec-users, click here.
>> thrust.png (41K) Download Attachment
>> roll15.png (41K) Download Attachment
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion below:
>> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2980469.html
>> To start a new topic under asctec-users, email [hidden email]
>> To unsubscribe from asctec-users, click here.
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion below:
> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p2980804.html
> To start a new topic under asctec-users, email [hidden email]
> To unsubscribe from asctec-users, click here.
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

bouffard
On Tue, May 24, 2011 at 11:26 AM, Steven Bellens [via asctec-users]
<[hidden email]> wrote:
>> Interesting. I've never seen a range with real units for the thrust
>> commands. Where did you get the [0..32N] from?
> Stefan mentioned it on this mailing list in "Relation between thrust
> command and resulting lift force"

Aha. Somehow that thread managed to slip by me. Thanks. I've put that
info on the QandA wiki page
(http://robotics.ccny.cuny.edu/wiki/AscTecQandA)

Pat
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

daniel@asctec
Hi guys,

let me try to solve the confusion. Steven, thanks for posting the plot. There are two factors, that could explain a difference between commanded and measured pitch and roll angles on the Pelican.

First, and most important, the attitude controller is a PD controller running at 1 kHz; there is no I-part compensating for residual errors. If the vehicle is well balanced, a command should result in the desired pitch/roll angles. In the case of the AscTec Pelican this depends a lot on the payload. If there is no payload installed, the center of mass is way underneath the rotors, resulting in a force pushing the vehicle back to horizontal when commanded to a certain angle in a static environment. When airborne, the resulting angles also depend on the trajectory flown. If you have a laser scanner installed using our mount on top of the Pelican the center of mass is close to the rotors, and therefore the resulting angle should be closer to what is actually commanded.

Second, there is a so called random walk of the accelerometers resulting in an absolute measurement error in pitch and roll of up to +-3 degrees (usually less). This could also explain a difference between a command and an external measurement of the absolute angles.

When designing a position control loop it makes sense to include some kind of error integral to compensate for residual positioning errors resulting due to the effects above. For instance, our GPS controller does have something like an integral part to push the vehicle towards the desired position, even if the payload is not balanced.  

Hope that helps.
Daniel
Reply | Threaded
Open this post in threaded view
|

Re: Commanded vs measured roll and pitch angles

Steven Bellens
Hey Daniel,

2011/5/30 daniel@asctec [via asctec-users]
<[hidden email]>:

> Hi guys,
>
> let me try to solve the confusion. Steven, thanks for posting the plot.
> There are two factors, that could explain a difference between commanded and
> measured pitch and roll angles on the Pelican.
>
> First, and most important, the attitude controller is a PD controller
> running at 1 kHz; there is no I-part compensating for residual errors. If
> the vehicle is well balanced, a command should result in the desired
> pitch/roll angles. In the case of the AscTec Pelican this depends a lot on
> the payload. If there is no payload installed, the center of mass is way
> underneath the rotors, resulting in a force pushing the vehicle back to
> horizontal when commanded to a certain angle in a static environment. When
> airborne, the resulting angles also depend on the trajectory flown. If you
> have a laser scanner installed using our mount on top of the Pelican the
> center of mass is close to the rotors, and therefore the resulting angle
> should be closer to what is actually commanded.
You are completely right! I had about the same thought this weekend
and I modified my test set-up in order to balance the Pelican as
perfect as possible (I attached the battery at the bottom and I move
it little bits to tune the set-up). I also have my external
measurement unit back, so I could obtain ground truth reference
measurements. Plots of the new experiment in appendix, the attitude
controller does a _very_ good job in tracking the commanded angle, I
must say. I have only tested this for roll angles currently - I guess
the pitch results should be similar. Also, I didn't notice any
significant dependency on the thrust level - tested with 10 / 15 / 20N
and results were all similar (Plot is generated with 15N thrust
input).

The percentage deviation in my previous experiments can be explained
due to the fact the Pelican was not completely balanced (rotation
point above COG). This results in gravity exercing a moment around the
rotation axis, and subsequent force increasing as the distance between
COG and rotation axis increases. For small angles, a linear increase
in angle maps to a linear force increase, which explains my previous
results.

>
> Second, there is a so called random walk of the accelerometers resulting in
> an absolute measurement error in pitch and roll of up to +-3 degrees
> (usually less). This could also explain a difference between a command and
> an external measurement of the absolute angles.
>
> When designing a position control loop it makes sense to include some kind
> of error integral to compensate for residual positioning errors resulting
> due to the effects above. For instance, our GPS controller does have
> something like an integral part to push the vehicle towards the desired
> position, even if the payload is not balanced.
Yes, we did that already :).

Steven

>
> Hope that helps.
> Daniel
>
>
> ________________________________
> If you reply to this email, your message will be added to the discussion
> below:
> http://asctec-users.986163.n3.nabble.com/Commanded-vs-measured-roll-and-pitch-angles-tp2952441p3002191.html
> To start a new topic under asctec-users, email
> [hidden email]
> To unsubscribe from asctec-users, click here.

roll_control.png (39K) Download Attachment