# How should Reaction Wheels work?

## Recommended Posts

So, my apologies to Tuareg over this, I didn't ignore anything you said, but I struggle to understand just from theory. I have to be able to visualise it to understand it and that typically means breaking it down to it's base elements (conservation of rotational momentum in this case).

This wasis my major sticking point. For Tuareg's position to be correct, I hadhave to be making an incorrect assumption about this situation:

If a torque is applied for x seconds to a block on the end of the arm, and is then swapped with the center block (no change in linear momentum or angular momentum) and then reversed for x seconds, what is the final rotational velocity? The unity simulation poses that it will be non-zero while conservation of momentum poses that it will be zero.

When I was thinking of this, I seem to have been observing it from the reference frame of the body *which was rotating* while considering the ang. momentum of the blocks (I feel like an idiot for missing that)

When the block on the end of the arm is spun up, in the frame of the body it has the same ang. velocity and hence momentum as the central block.

However, in a stationary reference frame, the motion of the body is counter to that of the wheels and that decreases it's apparent spin velocity proportional to the distance it orbits at.

As the orbital distance of the wheel is reduced, it's apparent spin velocity increases. The block moving out experiences no change in ang. velocity and thus the ang. velocity of the body must also increase to again balance ang. momentum.

Thus angular momentum is conserved by a torque not acting at the center of mass causing a slower rotation of the body in free space.

Atleast, that makes sense to me. Could always be barking up the wrong tree again (I feel like I'm still missing something, what I have no clue...)

Doesn't make sense in the morning:sealed:, wheel spin rate has to be constant in any position on the rotating body and any position on the body has the same counter spin rate.

I'm lost in the middle somewhere. I have a feeling Tuareg's position is the correct one, but I cannot rationalise it.

My apologies once again to Tuareg for any offense I may have caused, it was not intended. I may have been somewhat frustrated at the inability to reach a consensus in a field that I consider to be about as black and white as you can get, but I shouldn't have let that have an on effect my discussion.

Edited by Crzyrndm
##### Share on other sites

I found this. What do you think?

##### Share on other sites

I found this. What do you think?

http://i.imgur.com/xK7r5EJ.webm

that is balancing on its tip with the CoM above the contact point, when the reaction wheel gets saturated it can tip in the other direction and desaturate it

##### Share on other sites

that is balancing on its tip with the CoM above the contact point, when the reaction wheel gets saturated it can tip in the other direction and desaturate it

nope, thats a giro not a rw and it doesnt need desaturation

##### Share on other sites

nope, thats a giro not a rw and it doesnt need desaturation

Top comment, from one of the people who built it:

"A shout-out to those who think that Cubli is a gyroscope. It is not. In a gyroscope the wheel spins at a high angular velocity to keep constant orientation. In the Cubli we use reaction torques to balance. These torques are what the Cubli's structure 'feels' when the three motors attached to it accelerate or decelerate the wheels. In fact, Cubli's controller tries to minimize wheel velocities in addition to keeping the structure upright. This method is more reactive to external disturbances and reduces vibrations and sensor noise."

##### Share on other sites

I found this. What do you think?

http://i.imgur.com/xK7r5EJ.webm

Um, I hope this isn't one of these "lander supporting itself crazily is actually feasible" arguments. That thing has big wheels (relative to it's size), and it's balanced on the point, not holding itself up, and as ratchet freak pointed out, it can do little maneuvers to de-saturate against gravity.

You can see it in other videos - it can climb up to it's balancing point, but it has to spin up the wheels massively before doing so, despite the wheels being relatively large. That tells us that the wheels don't generate much torque, relatively speaking.

That being said, I bet it's control software is orders of magnitudes better than KSP's SAS, and I wouldn't mind if someone bought me one as a present (it's neat and I want one, but I wouldn't want to pay more than 20-40 bucks for what amounts to a knick-nack, the lil lady would smack me with a pan if I showed up with more useless toys, so I don't wanna pay much more than that smack~).

(Interesting to note that the wheels are mounted on axles on the uh.. axis of mass though. Is that telling, or is that just because it's designed to work with semi-fixed pivot points?)

##### Share on other sites

That being said, I bet it's control software is orders of magnitudes better than KSP's SAS, and I wouldn't mind if someone bought me one as a present (it's neat and I want one, but I wouldn't want to pay more than 20-40 bucks for what amounts to a knick-nack, the lil lady would smack me with a pan if I showed up with more useless toys, so I don't wanna pay much more than that smack~).

(Interesting to note that the wheels are mounted on axles on the uh.. axis of mass though. Is that telling, or is that just because it's designed to work with semi-fixed pivot points?)

Control software probably based off the same principals as stock SAS (simple PID could definitely work, but then so could a number of other systems they could be using), but has a little more smarts for things that SAS doesn't have to worry about. They also have a single system so the software can (and will) be perfectly tuned for that particular object, while Squad has to make do with a middle of the road choice unless they want to get into auto tuning (*blegh*).

On your other point, note that centering the wheels means you can make them larger within the same boundaries, and makes centering CoM easier. There are more possible reasons than just torque to locate them that way.

EDIT

And now I want to make one. That would be an amusing thing to trot out (except then I'd need to build it -.-; Software: Check, Electronics: Check, Construction: MIA...)

Edited by Crzyrndm
##### Share on other sites

Control software probably based off the same principals as stock SAS (simple PID could definitely work, but then so could a number of other systems they could be using), but has a little more smarts for things that SAS doesn't have to worry about. They also have a single system so the software can (and will) be perfectly tuned for that particular object, while Squad has to make do with a middle of the road choice unless they want to get into auto tuning (*blegh*).

Ugh. Stock SAS is terrible. Like, worse-than-keyboard-input terrible. I've not really researched PID very much (my own control systems use exact calculations, tied with my deterministic delta-t system, so I've never needed to deal with any significant error), but if that's a simple PID system, it doesn't fill me with confidence then.

On your other point, note that centering the wheels means you can make them larger within the same boundaries, and makes centering CoM easier. There are more possible reasons than just torque to locate them that way.

That's true, but I noticed that they weren't as large as they could have been, and yet were still centered. It may also have to do with the pivoting action, however, like the from-the-garage examples. Still, the few examples where I could actually see where wheels are mounted in space systems seemed to have them mounted such that their axle's vector goes through the CoM (I like to call this the 'axis of mass', because I'm silly).

ANd just how come we haven't heard from actual aerospace engineers who deal with these things in orbit? I'd be highly surprised to find out that there aren't any here..

##### Share on other sites

Ugh. Stock SAS is terrible. Like, worse-than-keyboard-input terrible. I've not really researched PID very much (my own control systems use exact calculations, tied with my deterministic delta-t system, so I've never needed to deal with any significant error), but if that's a simple PID system, it doesn't fill me with confidence then.

It's terrible because it's static and generic. It doesn't account for how your vessel will respond in the slightest, it does the exact same thing for a heavyweight craft with barely any control as a 0.1t super twitchy thing. PID controllers are used by MJ (auto tuned AFAIK) and Pilot Assistant (manual tuning). The behaviour achieved by either of them showcases what they can do a whole lot better.

##### Share on other sites

It's terrible because it's static and generic. It doesn't account for how your vessel will respond in the slightest, it does the exact same thing for a heavyweight craft with barely any control as a 0.1t super twitchy thing. PID controllers are used by MJ (auto tuned AFAIK) and Pilot Assistant (manual tuning). The behaviour achieved by either of them showcases what they can do a whole lot better.

I might have to give MechJeb another peek to see how it handles. I presume that would be the 'SmartASS' thing that I saw.

(I looked at it before as it has some enhanced RCS systems, that are better than stock. They still fall way short of what I want though)

##### Share on other sites

Current reaction wheels are too powerful. They make command pods hard to control and reduce RCS to "for-docking-only".

With keyboard controls it's, hm.. not enjoyable to point a command pod during reentry manually in the right direction(even with precision on).

I prefer smooth less fast movement to instant 180Ã‚Â° turns.

So I'd like to see a balancing of reaction wheels in conjunction with a balancing of keyboard input to get an overall smoother gameplay.

## Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

×   Pasted as rich text.   Paste as plain text instead

Only 75 emoji are allowed.