Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.
First time visiting? Here are some places to start:- Looking for a certain topic? Check out the categories filter or use Search (upper right).
- Need support? Ask a question to our Community Support category.
- Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
- Be respectful, on topic and if you see a problem, Flag it.
If you would like to contact our Community Manager personally, feel free to send a private message or an email.
New features for measurement: Relative Measure, Euler to MC, and MC to Euler
jnewth
Member, OS Professional Posts: 72 PRO
Announcing: Relative Measure, Euler → MC, and MC → Euler
Written by Joshua Newth (former Part Studios dev, now at Reframe Systems) and Greg Brown (Head of Product at Onshape).
What’s new
Relative Measure — Get X, Y, Z displacements between two points relative to any coordinate system (mate connector), not just the world frame. Ideal for robotics.
Euler → MC — Specify a start frame, an Euler/Tait‑Bryan convention, and a set of angles; the tool creates a mate connector at the resulting orientation. Supports the full set of Euler/Tait‑Bryan conventions.
MC → Euler — Compute Euler angles between two coordinate systems under the chosen Euler/Tait‑Bryan convention (reverse of Euler → MC).
Why it matters
Onshape’s native measurement tools are powerful, but they always report in the world frame. These extensions close that gap for some niche use cases by adding local-frame measurements and reliable Euler conversions.
Care was taken for the conversions to be correct, canonical, and symmetric. The tools also avoid reporting or accepting aliased angle sets, and correctly detect and report gimbal lock and other errors endemic in euler angle workflows.
If you like implementation details: I’ll publish a short blog post covering tricky edge cases and gotchas discovered while building the FeatureScript.
Where to get them
Relative Measure - https://cad.onshape.com/documents/56d995a2ad08f2cdae9d49cf/v/cb21050a585a128c66192b9b/e/29e1313f5a74cb195acb5056
Euler angle tools - https://cad.onshape.com/documents/c5c44c9774eb0052579a2407/v/5b2d4bd4a2b47c132ff86167/e/75b1d59e74c3198627aea7d1
Comments
Looking forward to the blog post. I have run into a few situations requiring some comparison of relative relationships between the ends of twisted frame bodies that I could have used a more streamlined implementation of an euler angle tool to help resolve. My mind has also drifted off into quaternion land wondering if I could implement some game dev tricks for more performant patterning features but that's even farther away from the native world coordinate system approach.
That looks interesting.
A simple option to select a mate connector in the "regular" measure tool is still needed though! Especially in assemblies were there aren't really any decent workarounds.
Just read through the comments in the documentation. Gimbal lock and Euler angles go together like peanut butter and jelly. That's one of the reasons I was barking up the quaternion tree in my previous coordinate system transformation explorations. Fewer available utils to use there though.
@Derek_Van_Allen_BD Onshape std library is generally written in terms of matrixes. You could certainly write a quat library for your own work, but (imo) the usual reasons for quats (performance, interpolation, and fewer matrix multiplys) don't make much improvement in Onshape. That said: if you write it I will read it!
For avoiding gimbal lock and such: I'd recommend just using the rotation matrix transforms. Onshape has some utilities builtin to make this type of code a little simpler to write but it's still pretty error-prone. In fact: The blog post will mostly be a recitation of the many (many) numerical and programmatic mistakes one person can make when trying to implement euler angle tools!
@eric_pesty Strong agreement. I think @GregBrown identified a core pain point that needs addressing which is why he wanted to write these tools. Onshape dev team has a lot of stuff on their plate so who knows the timing? But they are aware of the need.
As @jnewth points out, additional tools for transformations in quaternion form are good opportunities for custom features. I have my own set of Matrix to Quaternion and a hotrodded
Transformfeature that takes, amongst other things, a homogeneous transform matrix as inputs. This is pretty niche!The
Euler to MCfeature is much more aligned with observed robotics workflows since a) many robots use Euler angle-based inputs, and b) different robot manufacturers use different Tait-Bryan or Proper Euler approaches. There is also an option to save rotation matrix as variable which is the gateway to these even more niche tools I described. It is simple to, in Onshape's Variable table, to construct a full transform object partly based on the variable created in theEuler to MCfeature….Josh and Greg, these look great!
The Onsherpa | Reach peak Onshape productivity
www.theonsherpa.com