Replies to This Discussion

DeveloperPermalink Reply by R_Lefebvre on May 2, 2012 at 11:53am

I didn't have any luck cleaning up the signal on the MB1260.  I suspect it's just too sensitive.  But you're already getting much better results than me.  Or it might be I got some swarf in my sensor since I do a lot of machining in the shop.

Don't forget, those spikes might even be a flying insect.

I don't agree with the hovering pressure affecting vibes, but it you want to investigate that's up to you.

I was going to suggest you try some of the common FBL vibration mitigation ideas.  First one would be to use the two-layer approach.  Pad, metal plate, pad, sensor.

Also, how exactly is that fiberglass board held down?  I wonder if it could be vibrating on the frame?

• ▶ Reply

Permalink Reply by Wesley Chuen on May 2, 2012 at 12:07pm

lol @ flying insect!  It is possible since the 1260 has a resolution of 1cm I believe.

I have my APM2 sticked onto a blank PCB using 3M foam pad and lightly held down with screws and nuts on 4 corners.  Then the whole thing sit on some sticky anti-vibration pad that is 5mm think.  I forgot to get the metal plate part.  Going to order a piece now.

Permalink Reply by Wesley Chuen on May 2, 2012 at 5:48pm

This random drifting is pissing me off.  Today, I tried to tune it again and I eventually had to use full stick to counter it!  FULL STICK!!!  and that was still not enough before it land, and it striked the blades.  I'm taking the whole thing apart and re-mounting it at the bottom under the heli, just to rule out if that is the problem.

Permalink Reply by Wesley Chuen on May 2, 2012 at 9:08pm

ok.  I feel better now.

DeveloperPermalink Reply by R_Lefebvre on May 3, 2012 at 5:04am

Wesley, can you send me a PM with your email address?  Tridge looked at your logs, and he needs you to do some tests.  Your logs are unusual.

Permalink Reply by Wesley Chuen on May 3, 2012 at 9:44am

PM Sent.  However, I moved the APM2 to under the heli last night though.  Just finished it at 7am.  Let's see if the random drift still happens.

Permalink Reply by Francisc Bereczky on May 2, 2012 at 12:14pm

You say "The "leaning" problem is in random direction.  Sometimes to the left or right and I have to hold the roll more and more.  Sometimes is the pitch.  And it could change direction during one session of hovering.  That's why I used to call it the random drifting problem."

In my opinion this drift is not quite random. Try to link the drift to the RC sticks movements.

Today I made an experiment with APM1 on the table. No vibrations, no sonar ...

I uploaded Arducopter 2.5.4 with a modified AP_MotorsMatrix.cpp. 

I modified the following code:

// mix roll, pitch, yaw, throttle into output for each motor

for( i=0; i<AP_MOTORS_MAX_NUM_MOTORS; i++ ) {

   if( motor_enabled[i] ) {    motor_out[i] = _rc_throttle->radio_out +

                                         _rc_roll->pwm_out * _roll_factor[i] +

                                         _rc_pitch->pwm_out * _pitch_factor[i] +

                                         _rc_yaw->pwm_out*_yaw_factor[i];

   }

}

pushing the four components of the sum to the four outputs.

I noticed that moving a stick (pitch, roll or yaw) the corresponding output drifts slowely until reaches a limit. Moving the stick in opposite direction the output drifts back.

Is this a software bug?

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on May 2, 2012 at 12:27pm

I have no idea.  Sorry, my understanding of the code was blown with the move to motors library and pointers.

What do you think is the bug exactly?

Permalink Reply by Francisc Bereczky on May 2, 2012 at 12:44pm

I have no ideea. I try for the last few weeks to understand the code.

Unforunatelly I am not a software developper, I am a beginner with C++.

An expert must answer your question.

I only noticed a strange behavior in stabilise. To find such a bug (if it is the case) deep digging is necessary.

DeveloperPermalink Reply by R_Lefebvre on May 2, 2012 at 12:56pm

Oh, you know what?  Did you have the APM board sitting flat on the table?  If you did, the effect you are seeing is probably simply due to the fact that the board is not moving, so the I terms are building up.  That would be normal.

Try your test again after setting all the Stab and Rate I terms to zero.

Permalink Reply by Francisc Bereczky on May 2, 2012 at 1:01pm

Thanks for the tip. I will make the test tomorow.

Permalink Reply by Francisc Bereczky on May 3, 2012 at 6:39am

The test confirmed what you said about I terms.

For this test my modified code in AP_MotorMatrix.cpp is this:

 // mix roll, pitch, yaw, throttle into output for each motor
 i=0;
  if( motor_enabled[i] ) {
  motor_out[i] = _rc_throttle->radio_out;
  }
 i=1;
  if( motor_enabled[i] ) {
  motor_out[i] = 1500 + _rc_roll->pwm_out * _roll_factor[i];
  }
 i=2;
  if( motor_enabled[i] ) {
  motor_out[i] = 1500 + _rc_pitch->pwm_out * _pitch_factor[i];
  }
 i=3;
  if( motor_enabled[i] ) {
  motor_out[i] = 1500 + _rc_yaw->pwm_out*_yaw_factor[i];
  }

I tried to see the behaviour of each term. There are a few things I do not understand.

1. Pitching or rolling the AP output increases on Ch1 in both cases. I expected no variations here.

2. Ch2 and Ch3 are acting as I expected, there output is proportional with the roll respectively the pitch angle. 

3. Turning to left or right (yawing) the AP Ch4 seems to be proportional with the yaw rate not with the yaw angle. 

• ‹ Previous
• 1
• 2
• 3
• Next ›
• Page