I had another interesting event last night that caused my quad to shoot up
and smack into the ceiling again but for a very different reason than last
time (which was just caused by a mistake I made).
There are times when the eeprom gets wiped, corrupted, or whatever. In my
case this occurs when I attempt to write to the eeprom after calibrating
the sensors. It is not always immediately obvious that this has happened
unless you look at the parameters in QGC, see a stack dump in the comm's
console or, as it was in my case, try to fly.
The current default gains are still old and are way too high resulting in
radical behavior. My proposal would be that we change all gains such as
MC_ATTRATE_P to default to zero. Even better might be adding a throttle
limiter which defaults to zero so the motors won't even spin forcing you to
address the situation.
Which reminds me, why were all the MC_*_LIM parameters removed?
I'm really sorry to hear that. Although I do blame issues in the software for it, these safety instructions will likely help to catch them. I teach those my students and even long-term industry experts still stick to them.
Pre-flight check (after every battery change, transport, restart and in particular on param and firmware changes):
- Put the multirotor on the ground
- Hold it down with one arm
- Throttle up with the other hand and check that the magnitude, sound (no oscillations) and attitude response are correct
- Disarm, step away
- Fly
Separate from that your issue is param induced, but the actual issue is rather that one very essential property of the control scheme is violated, pointing towards a software and not a param issue as source: No matter what control response you have, it is symmetric. So if your gains are too high you have it oscillating on roll and pitch or yaw on the ground, but the collective thrust has to be = stick input.
So either its something unrelated, or an overflow making negative control gains into positive numbers.
The AR.Drone code has additional safety logic in, we should get that ASAP also in the standard multirotor mixers.
As for the controller limits, they do more harm at this stage than helping - saturating limits is a common source of bad control behaviour, without noticing. They are only mandatory in case of I terms, and right now we have none of them. If it turns out we need them we will re-add them. But they wouldn't have stopped your quad either, since they would only have limited oscillations, but not fixed the non-symmetric throttle issue you're seeing.
Again, sorry about this - as you're tinkering with the onboard control (which may later also induce issues), I think a leash is really a good idea for the next tests. I will let you know once we've ported and tested the additional sanity checking on the control outputs. We have to make sure that its correct and test it.
And can you please use the sdlog app (sdlog start)? That logfile would allow me to gain substantial insights in such an event.
I had another interesting event last night that caused my quad to shoot up and smack into the ceiling again but for a very different reason than last time (which was just caused by a mistake I made).
There are times when the eeprom gets wiped, corrupted, or whatever. In my case this occurs when I attempt to write to the eeprom after calibrating the sensors. It is not always immediately obvious that this has happened unless you look at the parameters in QGC, see a stack dump in the comm's console or, as it was in my case, try to fly.
The current default gains are still old and are way too high resulting in radical behavior. My proposal would be that we change all gains such as MC_ATTRATE_P to default to zero. Even better might be adding a throttle limiter which defaults to zero so the motors won't even spin forcing you to address the situation.
Which reminds me, why were all the MC_*_LIM parameters removed?
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
It's OK, no damage was done (just a few more small black marks on the
ceiling I can get rid of ;)
I agree with the approach to being cautious when making changes, however, I
don't see the advantage to having any default values for these parameters
(or am I missing something such as HIL?) so changing them to zero would
remove one potential area for error. In my case the issue is very clear in
that the hardcoded default for MC_ATTRATE_P is way too high for my quad.
On Wed, Nov 7, 2012 at 2:19 PM, Meier Lorenz <l...@inf.ethz.ch> wrote:
> Hi Simon,
> I'm really sorry to hear that. Although I do blame issues in the software
> for it, these safety instructions will likely help to catch them. I teach
> those my students and even long-term industry experts still stick to them.
> Pre-flight check (after every battery change, transport, restart and in
> particular on param and firmware changes):
> - Put the multirotor on the ground
> - Hold it down with one arm
> - Throttle up with the other hand and check that the magnitude, sound (no
> oscillations) and attitude response are correct
> - Disarm, step away
> - Fly
> Separate from that your issue is param induced, but the actual issue is
> rather that one very essential property of the control scheme is violated,
> pointing towards a software and not a param issue as source: No matter what
> control response you have, it is symmetric. So if your gains are too high
> you have it oscillating on roll and pitch or yaw on the ground, but the
> collective thrust has to be = stick input.
> So either its something unrelated, or an overflow making negative control
> gains into positive numbers.
> The AR.Drone code has additional safety logic in, we should get that ASAP
> also in the standard multirotor mixers.
> As for the controller limits, they do more harm at this stage than helping
> - saturating limits is a common source of bad control behaviour, without
> noticing. They are only mandatory in case of I terms, and right now we have
> none of them. If it turns out we need them we will re-add them. But they
> wouldn't have stopped your quad either, since they would only have limited
> oscillations, but not fixed the non-symmetric throttle issue you're seeing.
> Again, sorry about this - as you're tinkering with the onboard control
> (which may later also induce issues), I think a leash is really a good idea
> for the next tests. I will let you know once we've ported and tested the
> additional sanity checking on the control outputs. We have to make sure
> that its correct and test it.
> And can you please use the sdlog app (sdlog start)? That logfile would
> allow me to gain substantial insights in such an event.
> Thanks,
> Lorenz
> ------------------------------------------------------
> Lorenz Meier
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
> On Nov 7, 2012, at 1:11 PM, Simon Wilks wrote:
> I had another interesting event last night that caused my quad to shoot up
> and smack into the ceiling again but for a very different reason than last
> time (which was just caused by a mistake I made).
> There are times when the eeprom gets wiped, corrupted, or whatever. In my
> case this occurs when I attempt to write to the eeprom after calibrating
> the sensors. It is not always immediately obvious that this has happened
> unless you look at the parameters in QGC, see a stack dump in the comm's
> console or, as it was in my case, try to fly.
> The current default gains are still old and are way too high resulting in
> radical behavior. My proposal would be that we change all gains such as
> MC_ATTRATE_P to default to zero. Even better might be adding a throttle
> limiter which defaults to zero so the motors won't even spin forcing you to
> address the situation.
> Which reminds me, why were all the MC_*_LIM parameters removed?
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To
> unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com<mailto:
> px4users+unsubscribe@googlegroups.com>. For more options, visit this
> group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com. To unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com. For more options, visit this group
> at https://groups.google.com/d/forum/px4users?hl=en-US
Sorry, I missed to respond to that - yes, we'll immediately put the default params to zero. I'm just saying that whatever caused this still could happen then, since its not a linear response to the value.
It's OK, no damage was done (just a few more small black marks on the ceiling I can get rid of ;)
I agree with the approach to being cautious when making changes, however, I don't see the advantage to having any default values for these parameters (or am I missing something such as HIL?) so changing them to zero would remove one potential area for error. In my case the issue is very clear in that the hardcoded default for MC_ATTRATE_P is way too high for my quad.
Simon
On Wed, Nov 7, 2012 at 2:19 PM, Meier Lorenz <l...@inf.ethz.ch<mailto:l...@inf.ethz.ch>> wrote:
Hi Simon,
I'm really sorry to hear that. Although I do blame issues in the software for it, these safety instructions will likely help to catch them. I teach those my students and even long-term industry experts still stick to them.
Pre-flight check (after every battery change, transport, restart and in particular on param and firmware changes):
- Put the multirotor on the ground
- Hold it down with one arm
- Throttle up with the other hand and check that the magnitude, sound (no oscillations) and attitude response are correct
- Disarm, step away
- Fly
Separate from that your issue is param induced, but the actual issue is rather that one very essential property of the control scheme is violated, pointing towards a software and not a param issue as source: No matter what control response you have, it is symmetric. So if your gains are too high you have it oscillating on roll and pitch or yaw on the ground, but the collective thrust has to be = stick input.
So either its something unrelated, or an overflow making negative control gains into positive numbers.
The AR.Drone code has additional safety logic in, we should get that ASAP also in the standard multirotor mixers.
As for the controller limits, they do more harm at this stage than helping - saturating limits is a common source of bad control behaviour, without noticing. They are only mandatory in case of I terms, and right now we have none of them. If it turns out we need them we will re-add them. But they wouldn't have stopped your quad either, since they would only have limited oscillations, but not fixed the non-symmetric throttle issue you're seeing.
Again, sorry about this - as you're tinkering with the onboard control (which may later also induce issues), I think a leash is really a good idea for the next tests. I will let you know once we've ported and tested the additional sanity checking on the control outputs. We have to make sure that its correct and test it.
And can you please use the sdlog app (sdlog start)? That logfile would allow me to gain substantial insights in such an event.
I had another interesting event last night that caused my quad to shoot up and smack into the ceiling again but for a very different reason than last time (which was just caused by a mistake I made).
There are times when the eeprom gets wiped, corrupted, or whatever. In my case this occurs when I attempt to write to the eeprom after calibrating the sensors. It is not always immediately obvious that this has happened unless you look at the parameters in QGC, see a stack dump in the comm's console or, as it was in my case, try to fly.
The current default gains are still old and are way too high resulting in radical behavior. My proposal would be that we change all gains such as MC_ATTRATE_P to default to zero. Even better might be adding a throttle limiter which defaults to zero so the motors won't even spin forcing you to address the situation.
Which reminds me, why were all the MC_*_LIM parameters removed?
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com><mailto:px4users @googlegroups.com<mailto:px4users@googlegroups.com>>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com><mailto:px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bu nsubscribe@googlegroups.com>>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
Yes, you are right about that. I think I will start using a strap of some
sort too.
BTW don't feel I am insisting on you doing changes in general, I just want
to check you are OK with a proposal before I run off, do it and issue a
pull request.
On Wed, Nov 7, 2012 at 2:57 PM, Meier Lorenz <l...@inf.ethz.ch> wrote:
> Sorry, I missed to respond to that - yes, we'll immediately put the
> default params to zero. I'm just saying that whatever caused this still
> could happen then, since its not a linear response to the value.
> -Lorenz
> ------------------------------------------------------
> Lorenz Meier
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
> On Nov 7, 2012, at 2:54 PM, Simon Wilks wrote:
> It's OK, no damage was done (just a few more small black marks on the
> ceiling I can get rid of ;)
> I agree with the approach to being cautious when making changes, however,
> I don't see the advantage to having any default values for these parameters
> (or am I missing something such as HIL?) so changing them to zero would
> remove one potential area for error. In my case the issue is very clear in
> that the hardcoded default for MC_ATTRATE_P is way too high for my quad.
> Simon
> On Wed, Nov 7, 2012 at 2:19 PM, Meier Lorenz <l...@inf.ethz.ch<mailto:
> l...@inf.ethz.ch>> wrote:
> Hi Simon,
> I'm really sorry to hear that. Although I do blame issues in the software
> for it, these safety instructions will likely help to catch them. I teach
> those my students and even long-term industry experts still stick to them.
> Pre-flight check (after every battery change, transport, restart and in
> particular on param and firmware changes):
> - Put the multirotor on the ground
> - Hold it down with one arm
> - Throttle up with the other hand and check that the magnitude, sound (no
> oscillations) and attitude response are correct
> - Disarm, step away
> - Fly
> Separate from that your issue is param induced, but the actual issue is
> rather that one very essential property of the control scheme is violated,
> pointing towards a software and not a param issue as source: No matter what
> control response you have, it is symmetric. So if your gains are too high
> you have it oscillating on roll and pitch or yaw on the ground, but the
> collective thrust has to be = stick input.
> So either its something unrelated, or an overflow making negative control
> gains into positive numbers.
> The AR.Drone code has additional safety logic in, we should get that ASAP
> also in the standard multirotor mixers.
> As for the controller limits, they do more harm at this stage than helping
> - saturating limits is a common source of bad control behaviour, without
> noticing. They are only mandatory in case of I terms, and right now we have
> none of them. If it turns out we need them we will re-add them. But they
> wouldn't have stopped your quad either, since they would only have limited
> oscillations, but not fixed the non-symmetric throttle issue you're seeing.
> Again, sorry about this - as you're tinkering with the onboard control
> (which may later also induce issues), I think a leash is really a good idea
> for the next tests. I will let you know once we've ported and tested the
> additional sanity checking on the control outputs. We have to make sure
> that its correct and test it.
> And can you please use the sdlog app (sdlog start)? That logfile would
> allow me to gain substantial insights in such an event.
> Thanks,
> Lorenz
> ------------------------------------------------------
> Lorenz Meier
> Institute for Visual Computing
> ETH Zurich
> http://www.inf.ethz.ch/personal/lomeier/
> On Nov 7, 2012, at 1:11 PM, Simon Wilks wrote:
> I had another interesting event last night that caused my quad to shoot up
> and smack into the ceiling again but for a very different reason than last
> time (which was just caused by a mistake I made).
> There are times when the eeprom gets wiped, corrupted, or whatever. In my
> case this occurs when I attempt to write to the eeprom after calibrating
> the sensors. It is not always immediately obvious that this has happened
> unless you look at the parameters in QGC, see a stack dump in the comm's
> console or, as it was in my case, try to fly.
> The current default gains are still old and are way too high resulting in
> radical behavior. My proposal would be that we change all gains such as
> MC_ATTRATE_P to default to zero. Even better might be adding a throttle
> limiter which defaults to zero so the motors won't even spin forcing you to
> address the situation.
> Which reminds me, why were all the MC_*_LIM parameters removed?
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com<mailto:px4users@googlegroups.com><mailto:
> px4users@googlegroups.com<mailto:px4users@googlegroups.com>>. To
> unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com<mailto:
> px4users%2Bunsubscribe@googlegroups.com><mailto:
> px4users+unsubscribe@googlegroups.com<mailto:
> px4users%2Bunsubscribe@googlegroups.com>>. For more options, visit this
> group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To
> unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com<mailto:
> px4users%2Bunsubscribe@googlegroups.com>. For more options, visit this
> group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To
> unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com<mailto:
> px4users+unsubscribe@googlegroups.com>. For more options, visit this
> group at https://groups.google.com/d/forum/px4users?hl=en-US
> You received this message because you are subscribed to the Google Groups
> px4users group. To post to this group, send email to
> px4users@googlegroups.com. To unsubscribe from this group, send email to
> px4users+unsubscribe@googlegroups.com. For more options, visit this group
> at https://groups.google.com/d/forum/px4users?hl=en-US
No, its good in general. We need anyway a sanity check during system bootup, e.g. the thing should complain if your mag offsets are all-zero (and hence the mag output is unreliable, since its uncalibrated).
Yes, you are right about that. I think I will start using a strap of some sort too.
BTW don't feel I am insisting on you doing changes in general, I just want to check you are OK with a proposal before I run off, do it and issue a pull request.
Thanks :)
Simon
On Wed, Nov 7, 2012 at 2:57 PM, Meier Lorenz <l...@inf.ethz.ch<mailto:l...@inf.ethz.ch>> wrote:
Sorry, I missed to respond to that - yes, we'll immediately put the default params to zero. I'm just saying that whatever caused this still could happen then, since its not a linear response to the value.
It's OK, no damage was done (just a few more small black marks on the ceiling I can get rid of ;)
I agree with the approach to being cautious when making changes, however, I don't see the advantage to having any default values for these parameters (or am I missing something such as HIL?) so changing them to zero would remove one potential area for error. In my case the issue is very clear in that the hardcoded default for MC_ATTRATE_P is way too high for my quad.
Simon
On Wed, Nov 7, 2012 at 2:19 PM, Meier Lorenz <l...@inf.ethz.ch<mailto:l...@inf.ethz.ch><mailto:l...@inf.ethz.ch<mailto:l...@inf.ethz.ch>>> wrote:
Hi Simon,
I'm really sorry to hear that. Although I do blame issues in the software for it, these safety instructions will likely help to catch them. I teach those my students and even long-term industry experts still stick to them.
Pre-flight check (after every battery change, transport, restart and in particular on param and firmware changes):
- Put the multirotor on the ground
- Hold it down with one arm
- Throttle up with the other hand and check that the magnitude, sound (no oscillations) and attitude response are correct
- Disarm, step away
- Fly
Separate from that your issue is param induced, but the actual issue is rather that one very essential property of the control scheme is violated, pointing towards a software and not a param issue as source: No matter what control response you have, it is symmetric. So if your gains are too high you have it oscillating on roll and pitch or yaw on the ground, but the collective thrust has to be = stick input.
So either its something unrelated, or an overflow making negative control gains into positive numbers.
The AR.Drone code has additional safety logic in, we should get that ASAP also in the standard multirotor mixers.
As for the controller limits, they do more harm at this stage than helping - saturating limits is a common source of bad control behaviour, without noticing. They are only mandatory in case of I terms, and right now we have none of them. If it turns out we need them we will re-add them. But they wouldn't have stopped your quad either, since they would only have limited oscillations, but not fixed the non-symmetric throttle issue you're seeing.
Again, sorry about this - as you're tinkering with the onboard control (which may later also induce issues), I think a leash is really a good idea for the next tests. I will let you know once we've ported and tested the additional sanity checking on the control outputs. We have to make sure that its correct and test it.
And can you please use the sdlog app (sdlog start)? That logfile would allow me to gain substantial insights in such an event.
I had another interesting event last night that caused my quad to shoot up and smack into the ceiling again but for a very different reason than last time (which was just caused by a mistake I made).
There are times when the eeprom gets wiped, corrupted, or whatever. In my case this occurs when I attempt to write to the eeprom after calibrating the sensors. It is not always immediately obvious that this has happened unless you look at the parameters in QGC, see a stack dump in the comm's console or, as it was in my case, try to fly.
The current default gains are still old and are way too high resulting in radical behavior. My proposal would be that we change all gains such as MC_ATTRATE_P to default to zero. Even better might be adding a throttle limiter which defaults to zero so the motors won't even spin forcing you to address the situation.
Which reminds me, why were all the MC_*_LIM parameters removed?
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com><mailto:px4users @googlegroups.com<mailto:px4users@googlegroups.com>><mailto:px4users@google groups.com<mailto:px4users@googlegroups.com><mailto:px4users@googlegroups.c om<mailto:px4users@googlegroups.com>>>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com><mailto:px4users%2Bunsubscribe@googlegroups.com<mailto:px4users%2 52Bunsubscribe@googlegroups.com>><mailto:px4users+unsubscribe@googlegroups. com<mailto:px4users%2Bunsubscribe@googlegroups.com><mailto:px4users%2Bunsub scribe@googlegroups.com<mailto:px4users%252Bunsubscribe@googlegroups.com>>> . For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com><mailto:px4users @googlegroups.com<mailto:px4users@googlegroups.com>>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com><mailto:px4users%2Bunsubscribe@googlegroups.com<mailto:px4users%2 52Bunsubscribe@googlegroups.com>>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com><mailto:px4users @googlegroups.com<mailto:px4users@googlegroups.com>>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com><mailto:px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bu nsubscribe@googlegroups.com>>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users%2Bunsubscribe@googleg roups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
You received this message because you are subscribed to the Google Groups px4users group. To post to this group, send email to px4users@googlegroups.com<mailto:px4users@googlegroups.com>. To unsubscribe from this group, send email to px4users+unsubscribe@googlegroups.com<mailto:px4users+unsubscribe@googlegro ups.com>. For more options, visit this group at https://groups.google.com/d/forum/px4users?hl=en-US
