Fix pelvis dofs

[suhlrich]

you can't do cartwheels, or other gymnastics-type activities with these pelvis-ground rotation ranges. let's open them up, like we did with the other 4 pelvis-ground dofs.

[carmichaelong]

Thanks @suhlrich. The changes themselves look good, but I want to make sure that it won't cause some surprising changes to users while balancing making a new version / option for a seemingly minor change.

Something I did for testing was to see how results using test_main changed. Maybe a little surprisingly to me was that, despite some possible different scaling of the problem with a different bounds on range, the output .mot files appear to be exactly the same. These motions, however, are a simple walk and some squats. This would support not creating a new version for these models.

Were there any motions that you were able to test that also showed they were stable for current typical use cases?

[suhlrich]

thanks for testing. I have not tested this specific change. However, when I opened up pelvis_rotation some time ago, I tested and found the same thing you did. I haven’t looked, but I expect there’s some regularization on the first IK frame, then I think subsequent frames are discouraged from changing dramatically from the prior frame. I have never observed a pelvis rotation that is +/-360 unneccesarily, and that one has been open for a long time, so I expect that list and tilt will similarly be fine. I for sure don’t think we should call it a new model. I don’t have time to test deeply, so if you’d like to see more testing, I’m happy to just table the PR. It was just something I found when students were doing handstands for a class project :) On Mar 10, 2026, at 4:47 PM, carmichaelong ***@***.***> wrote:  [https://avatars.githubusercontent.com/u/7455790?s=20&v=4]carmichaelong left a comment (opencap-org/opencap-core#273)<#273 (comment)> Thanks @suhlrich<https://github.com/suhlrich>. The changes themselves look good, but I want to make sure that it won't cause some surprising changes to users while balancing making a new version / option for a seemingly minor change. Something I did for testing was to see how results using test_main changed. Maybe a little surprisingly to me was that, despite some possible different scaling of the problem with a different bounds on range, the output .mot files appear to be exactly the same. These motions, however, are a simple walk and some squats. This would support not creating a new version for these models. Were there any motions that you were able to test that also showed they were stable for current typical use cases? — Reply to this email directly, view it on GitHub<#273 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AKOYGJ3YKUTRFXIZMEOUX7T4QCLOBAVCNFSM6AAAAACWNPAHIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DAMZUHE2DMOJTGY>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[carmichaelong]

@suhlrich sorry this slipped down the list. I think it's best just to replace the model, but we should make this clear in a couple ways so that folks can better trace if they notice their results changing.

1. Add an entry to CHANGELOG.md in this repo. You could just add it to the current list of v1.1 (the idea is this is the current working version, and at some point we can create a tag in github when we think it's a good time to have a stable commit to point to)
2. Notify users of the change with some date attached to it. I don't think we have a mechanism for this yet, but could be some button that points to a webpage of a list of changes over time.

I was at first thinking this could fit in with the current testing and release if we only needed to document the first point, but could push to after the release in case figuring out a nice page for documenting updates could slow things down right now.