Hi, Amit. Yes, applying a mobility forces is what I meant by "internal". It models a motor on the wheel axle. It was the earlier body force that was external (the rocket-powered pinwheel).

Regards,
Sherm

Hi, Amit. If a reaction wheel is activated by a motor, you should switch back to using a mobility force on a Pin joint to model that, so that you correctly get torques on both bodies. As I mentioned, the current implementation is similar to a fireworks pinwheel where you have a pair of rockets attac...

Hi, Amit. I'm not sure I understand what you're trying to do, physically. The mobility force you had before very accurately models a motor at the joint -- motors apply equal and opposite torques to the armature and case. The current set up with a body force is a kind of external "hand of god" where ...

Hi, Simone. Congratulations on getting a custom mobilizer to work -- very nice! I think you are correct that that's the only way to implement the singularity-free behavior you want. The fact that MobilizedBody::FunctionBased assumes 3 angles for rotation dooms it. (BTW that is itself a custom mobili...

Sorry for the delay in responding to this. I ran your program to see what's happening. My guess is you didn't realize that when you apply a mobility force it is applied equal and opposite to the two connected bodies. So a torque is being applied both to the actuated wheel and the free-floating chass...

Hi, Simone. Simbody's integrators interpolate when a reporting time doesn't coincide with a step completion.

That's on by default but can be controlled by Integrator methods like setAllowInterpolation().

Regards,
Sherm

Hi Simone. If you use one of SImbody's variable step integrators, it should be able to figure out to take small steps over the rapid transition automatically.

Regards,
Sherm

Awesome! Thanks, Walter.

Sadly, no. There is a nice Assembly analysis in Simbody but no InitialVelocity analysis (there should be!) You can work around that by adding a velocity constraint (or Motion object) to one of the dofs (assuming a net-1-dof system). Then constraint projection will figure out all the other velocities...

You could try:
- CPodes limited to Order 1 (that makes it implicit Euler)
- SemiExplicitEulerIntegrator
- Use fixed step or very loose accuracy requirement, like 10%
- Use less damping or large masses to avoid extreme stiffness

Optimization is still probably the most direct approach.