-
Notifications
You must be signed in to change notification settings - Fork 696
Use tau instead of pi for rotations #554
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
This is not a nay on your proposal, but I typically just use Also has the benefit to give some sort of indication of what units the value your assigning there has. |
|
That came up on the Discord, too. My response:
|
Where is Personally, I'd rather we start using something like nholthaus/units or bernedom/SI.
I guess because of the updated Python? There's nothing special in |
For the moment only at the top of the two changed files :) But if Python can do it, so can C++.
Yes. The Python update made this possible in a whole chunk of the ecosystem, which is another reason why I think it's worth teaching. A custom |
It would also not be needed. There's |
Much like the real circle constant tau :) I'm happy to add the example to the help page. It seems like Travis is failing independently of this PR due to a Ruby issue, by the way. |
|
Not a huge fan of this. I don't think the tutorial is a good place to introduce a new variable that's not even MoveIt-related |
|
I consider it useful for MoveIt users, since they will specify rotations in their code. We already point out helpful patterns to new users in other sections of the tutorials, like here or here. The change is very limited in scope and won't negatively impact understanding. In the best case, a reader will go "Oh that's convenient" and have learned something. Worst case they will go "ok some angles, whatever" and proceed as they normally would have. It is as unobtrusive as it gets: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general I approve. You wasted half my day by pointing me to \tau, @felixvd. well... sigh
This can be quite useful for roboticists, so they might get to hear about it in a tutorial.
I do see @gavanderhoorn's arguments to use deg2rad methods.
They are useful and I guess especially relevant for engineers and fresh students (I've had to explain radians to a lot of students in terms of degrees over the years...).
In the context of this tutorial I personally prefer \tau though (of course also for its touch of nerdiness). But it also raises awareness for the radian unit in the messages. You can obviously specify radian(45), but it does give you an excuse not to look into what 0.78539... actually means. Whereas you definitely start thinking about it when pi or tau is involved.
Please resolve the conflict @felixvd .
Tau is the circle constant C/r (diameter over radius) = 2*pi = tau. This makes writing rotations easier. See https://tauday.com/tau-manifesto for more reasoning.
You're welcome 😎
I have used it in multiple projects and attest to the usefulness. It is like removing a pebble from your shoe you didn't know was there. All the arguments you mention are correct.
I rebased and added one line-end comment like this to each file as a pedagogical measure / mnemonic aid:
|
|
`joint_goal[1] = -tau/8 # 1/8 of a turn`
If you think such comments are helpful, at least keep the sign. :)
|
|
I'm still not a big fan of this, for all the previously mentioned reasons, but I'm just one voice here and I also don't care enough to prevent this from getting merged. From a didactic point of view I find it strange to introduce a new concept for something so fundamental in a tutorial which deals with completely different aspects of MoveIt, while conversion methods to-from radians and degrees are readily available and are used almost everywhere. But again: please merge if the consensus is there. |
My first reaction was "MoveIt doesn't reach people in 6th grade, so...", my second was "The amount of 'basic' things that confuse university students and graduates is off the charts, and there are high school students in robotics clubs reading these tutorials", and my third was "We're just using it, not holding a lecture on it". I don't know which to choose, but I know that this is a useful conceptual tool that readers are unlikely to know about, so I think it has a place in a tutorial. Since you mentioned that conversion methods are used almost everywhere (a testament to pi's unwieldiness, imo), I had a look through our tutorials but couldn't find them in there. However, I found a raw radian usage that I took the liberty of converting.
I moved the comment to a positive value to avoid confusion. I think they might be helpful for certain readers at this stage. |
v4hn
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's a matter of ideology I guess.
I approve this proposal as-is.
Either way it's good to streamline radian specifications in the tutorials.
I was very surprised to see 90.0/180.0*M_PI in the tutorial code.
|
This is a pretty great thread. "You wasted half my day" lol! |
|
I agree that tau is a much better alternative to pi, even if pi is probably more commonly used and known across the board. +1 from me to get this merged as is. |
davetcoleman
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reviewing further, seems good to me.
Tau is the circle constant C/r (diameter over radius) = 2*pi = tau. This makes writing rotations easier. See https://tauday.com/tau-manifesto for more reasoning. * Add more explicit comments * Add clearer radian definition in MGI C++ tutorial Co-authored-by: v4hn <me@v4hn.de>


With Ubuntu 20.04 and Noetic, Python 3.8 has become the default. The circle constant
tau = C/r = 2*pihas been added to the Python math module in 3.6.I don't want to open the whole debate here - this page and this video should summarize the arguments well enough. In short, it is an extremely useful representation for robotics, because we constantly write rotations using radians, and using tau saves mental operations. Although rotating around an axis is not difficult to do, chaining rotations in your head is confusing enough that Robert made this helper tool and I keep using this one. Something as seemingly simple as multiplying by (or was it dividing by?) 2 to describe a rotation is similarly "not difficult, but still confusing". We should not have unnecessary confusions in our way.
The natural way we think of rotations is in full turns. Just consider this part of the tutorial where we define joint angles. Try to imagine the configuration of this robot in your head*:
Now try to do it with this description, remembering that one tau is one turn, as per this outrageously simple diagram:
Did converting the angles in your head give you the slightest bit of pause? Likely not much, since as I said, it isn't difficult. But that's because dealing with these numbers all the time is literally our job. It is much more cumbersome for anyone who starts out, and this layer of obfuscation serves no use.
I am convinced that using "1 turn" as the unit for rotations makes writing rotations in radians a ton easier. I have started using it myself and have no idea why I hadn't done so earlier. It is just the weight of convention**.
Converting is trivial, as this affects only 3 files, and there is no need to change anything in the main code base. This is just introducing a useful shorthand in our educational materials, for users who would benefit from seeing it. There is precedent for saying "I'm just going to do this" in
this somewhat amusing discussion of the issue. I think we should follow this example.
This works on Python 2.7 since I guarded the Python include, so it can be backported to Melodic and Kinetic.
Pinging @tylerjw and @DLu since they've been working on the tutorials.
* I know robot configurations are already hard to imagine because the axes inconveniently switch signs, but you get the point.
** Actually I was expressing all rotations in degrees because it was so annoying to do the conversion in my head.
edit: This issue is a little controversial, so if you could add a reaction to this post (:+1: , :confused: or :-1:) on this post, that will be helpful.