Replies to This Discussion

3D RoboticsPermalink Reply by Chris Anderson on July 26, 2012 at 10:23am

Palo: Can you please upgrade to 2.7? We don't support older versions of the code after a new release. 

• ▶ Reply

Permalink Reply by palo sestak on July 26, 2012 at 11:44am

Chris: I already did. Not tested it yet (have no time due to my little sonny)

Anyway the case with climbing to the sky and diving back is still actual even with version 2.7... 

• ▶ Reply

Permalink Reply by John Campen on July 11, 2012 at 7:04am

For X8 coaxial quads using APM1, how do the channels out put the signal for yaw? The props on each arm in normal flight counter rotate at the same speed. However for Yaw to work the speed for the two props would have to be different correct? Can someone explain how this is configured for the 8X quad and what the props are doing for yaw?

• ▶ Reply

Permalink Reply by Glenn M on July 11, 2012 at 11:21pm

I'm running a tricopter (2.6 with Robert Lefebvre's yaw control branch) and am finding that my yaw servo will jam hard over to the right when disarmed, and today this led to the servo burning out. I only have one more of these servos on hand, so I'm quite keen to modify the code so that this will not happen again.

I see in another thread from late 2011 (here) about the same problem, It was mentioned that modifying radio.pde, and in the function void output_min() changing a line  APM_RC.OutputCh(CH_7, g.rc_3.radio_min); to  APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300);

 

However it seems in 2.6 the function void output_min() only contains the following:

 

void output_min()
{
motors.enable();
motors.output_min();
}

Is there something I can place in this function to limit the travel of my yaw servo, and if so, what should the line of code be? If I added APM_RC.OutputCh(CH_7, g.rc_3.radio_min + 300); within the function, is this still the correct syntax to have the desired effect?

 

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on July 12, 2012 at 6:05pm

Glenn, I had a look at your issue.  No, you can't just add that function in output_min();  It has to go in the motors class now.  But, it's a pretty easy fix I think, and here it is:

https://code.google.com/r/robertlefebvre-wip2/source/detail?r=2ffe7...

So grab that, and give it a shot.

If you want, you can also try:

_rc_yaw->radio_min + 300

Or:

_rc_yaw->control_in

The second option there will actually make the yaw servo move just as if it was in flight. That is what we do on Helicopters, I actually sort of like it.  I'm not positive it will work the same way on Tri, but there's a good chance it will (I don't have a tri to test).  Give it a shot, disconnect your servo rod.

Let me know which you like better, and I'll push it to trunk.

Thanks for your legwork, it actually made it really easy to find the problem.

• ▶ Reply

Permalink Reply by Glenn M on July 12, 2012 at 6:35pm

Excellent, thanks so much for this.

I've just loaded that in, and it works like a charm. It really feels like this thing has ninja precision and control now! Hopefully my servos will begin to live longer lives too.

• ▶ Reply

Permalink Reply by Bruce Jones on July 12, 2012 at 9:35pm

For those of us who don't have the means to build this, any idea if and when the fixes will be released in the mainline code?

Thanks

• ▶ Reply

DeveloperPermalink Reply by Randy on July 12, 2012 at 10:11pm

Yes, I think Robert's checking in the changes to trunk.  So it'll likely show up in 2.6.1 which isn't that far off actually.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on July 13, 2012 at 4:31am

Yeah, I just need confirmation from Glenn, and which mode he likes best.

• ▶ Reply

Permalink Reply by Glenn M on July 13, 2012 at 5:20am

Sorry I didn't get a chance to try the other options. It was working well with the initial change, so I just stuck with that for today. I'll give the others a go in the morning.

• ▶ Reply

DeveloperPermalink Reply by R_Lefebvre on July 13, 2012 at 8:24am

Ok cool, let me know.  I sort of like having the servo move when the motor is off on my heli.  It is of course totally safe, and testing the servo before flight is never a bad thing.  However the question is this:

On the heli, we have a really good setup, such that, the servo won't go beyond it's endpoints, no matter what. For example, if you command yaw on the ground, it doens't actually move, so you have a huge yaw error, thus the servo can move far trying to get it to actually turn (which is impossible because it's on the ground).

Do you have those protections with the Tricopter?  Do you set enpoints for the tail servo? I didn't see them at first look.

If you don't have protection (and it would appear you don't since you had the original problem... ) then I'll have to leave it where the tail servo just stays centered.  And that is what I did, BTW.  Instead of moving to "radio min +300", I have it set to the center, which is "radio trim".

• ▶ Reply

Permalink Reply by Glenn M on July 13, 2012 at 6:08pm

OK I see what you mean now.

On my tri, the servo travel is mechanically restricted by the yaw mechanism before the limit of the servo's movement is reached. There's no endpoint set for my servo travel, so if it was allowed to move when disarmed, when I held the throttle/yaw stick over to the corner to arm, it would be trying to push it past the limit of mechanical movement, and placing strain on the servo.

So for now I think I am happy to leave it so that it stays centred when disarmed. If there was a way to set a parameter to limit the travel of the servo at either extreme in pwm, then I would be more comfortable with it being hard over to the side, since it wouldn't be trying to push past where it was allowed to go.

Changing the min/max pwm values for rc4_max and min would be different though wouldn't it, as that would limit the actual travel of the stick?

• ▶ Reply

• ‹ Previous
• 1
• …
• 59
• 60
• 61
• 62
• 63
• …
• 68
• Next ›
• Page