• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

How would you design a cyclocopter?

This might be a little too dense for you to fully follow, but it's something for you to chew on if you are interested. One of my final dynamics projects was on modeling the dual cyclo. It might help explain the nature of the forces/moment acting on the system. You can see in the early time history data, there are some oscillations: this is from the cross-coupling of roll/pitch/yaw.
 

Attachments

As for your pitch oscillation problem...I'm thinking that you should not be assigning pitch_pid to the rear rotors, just the nose rotor. Reason being is that if you spool the rear motors in response to pitch (lets say it is nose up but should be level, so the rear motors spool up to counter), the torque from the rotor on your config from spooling up will actually create a nose-up moment, where you intended on creating a nose-down moment with the thrust.

Keeping the rear motors fixed in response to pitch, whose torque is inversely related to the desired pitch, will eliminate this weird canceling between rotor torque and rotor thrust when responding to pitch disturbances. This will mean that only the front rotor stabilizes pitch which will couple to roll as it changes its speed. So your roll axis needs to be able to handle the disturbances from the nose rotor as it responds to pitch (you can see what I mean by roll-pitch coupling with this example). Not a problem if you have roll tuned well.
 

2jujube7

Well-known member
As for your pitch oscillation problem...I'm thinking that you should not be assigning pitch_pid to the rear rotors, just the nose rotor. Reason being is that if you spool the rear motors in response to pitch (lets say it is nose up but should be level, so the rear motors spool up to counter), the torque from the rotor on your config from spooling up will actually create a nose-up moment, where you intended on creating a nose-down moment with the thrust.

Keeping the rear motors fixed in response to pitch, whose torque is inversely related to the desired pitch, will eliminate this weird canceling between rotor torque and rotor thrust when responding to pitch disturbances. This will mean that only the front rotor stabilizes pitch which will couple to roll as it changes its speed. So your roll axis needs to be able to handle the disturbances from the nose rotor as it responds to pitch (you can see what I mean by roll-pitch coupling with this example). Not a problem if you have roll tuned well.
Alright so I switched the directions of the two rear rotors, which seems to greatly increase pitch stability. To be honest, I designed the cyclocopter to go together like this in order to make the pitching more stable, but it appears that my logic was backwards for some reason and I did the opposite of what I was trying to do.

The thought is that I can then take pitch control out of the nose rotor, which should in turn eliminate the roll/pitch coupling?

Haha I thought that the stabilization/flight controller would come together easy once I got the rotors generating enough thrust.
 
The thought is that I can then take pitch control out of the nose rotor, which should in turn eliminate the roll/pitch coupling?
That'll definitely help. You will still run into the issue at higher throttle where the torque from the nose rotor will require one of the rear rotors to spool up much higher than the other side. So might be worth doubling the i_limit on the controller so the roll integral can spool up high enough to compensate.
 

2jujube7

Well-known member

Doing better. I'll try increasing the i_limit to see what that'll do.

I feel like it could use a little more fine tuning, but overall it flies significantly better. It's getting good enough for possibly a flight outside where I'll have room to let off the string completely.
 

2jujube7

Well-known member
I haven't tried it yet. I'm not super confident on the cyclocopter's abilities to not destructively oscillate, so I'm going to do a little more tethered testing. There's not quite enough room for me to completely give it slack with my current setup, but that last video was pretty close to a free flight.
 

2jujube7

Well-known member
I decided that I'm definitely still having problems with oscillations, and although I may be able to fly it, it would be a bit of a stretch to call it a "stable hover". I'm going to restart the tuning and try an actual PID tuning strategy, instead of the "attempt to (somewhat randomly) change values in a way that would make it more stable" that I've been doing.

I'm going to attempt a free flight tomorrow afternoon though no matter where it's at.