motor calibration?

[linas]

I notice that the dmitry head publishes these topics:

 * /dmitry/cmd_face_pau [pau2motors/pau] 1 publisher
 * /dmitry/cmd_eyes_pau [pau2motors/pau] 1 publisher
 * /dmitry/point_head [basic_head_api/PointHead] 1 publisher

Where are the first two specified/generated? How are they calibrated? I'm trying to figure out how these would need to be changed, to work with the eva head.

Based on discussions a few weeks ago, I got the impression that basic_head_api is going away, and won't be used with eva, but now I'm wondering if that's still true, if that still makes sense?

[vytasrgl]

All PAU messages are calibrated in pau2motors node which uses config from robots_config for specific robot. Basic head api here is used for convenience to convert Euler angle to quaternion which is accepted by pau2motors. So we do not really need basic_head_api.

[linas]

OK. Who will remove the basic_head_pi, and when? Or is it still temporarily needed?

I'd be happier if you used the standard SU(2) algebra insead of quaternions. Quaternions have been obsolete for the last 100 years, and only got revived due to a screw-up in the computer-graphics industry in the 1980's . Certainly, computing the holonomic constraint bundles for arms and legs and maybe the facial muscles will be easier in SU(2) than with quaternions, yeah? Certainly less error-prone.

[Gaboose]

I'm not familiar with SU(2), is it basically the Euler angles? Currently the neck commands flow like this: [robo_blender] --euler--> [basic_head_api] --quaternion--> [pau2motors] --basically euler--> [neck motors].

So it makes sense to circumvent basic_head_api and send the head rotation directly to pau2motors as we discussed with Vytas some time ago.

However basic_head_api is still used by one of the pages in ros_motors_webui. And in my humble opinion it's also a convenient tool to test the "pau2motors -> motors" pipeline without robo_blender ("divide and test" either by eye or automated). Even though basic_head_api ultimately won't make its way to the final product.

[Gaboose]

Clarification: Not to test the quaternion conversion but the PAU conversion of pau2motors through --make_face_expr--> [basic_head_api] --cmd_face_pau--> or only the motor nodes through: --make_coupled_face_expr--> [basic_head_api] --cmd_pololu--> etc.

[linas]

OK. I'll try to figure this out. I want to start working on the perception synthesizer, soon, and to do that, I'll need to figure out all the different coordinate systems. Another change (when this gets done) is that ROI messages will come from the perception synthesizer, instead of coming from pi_vision. So pi_vision will send data to update a global 3D map, The global 3d map will then publishevents about what i's seeing.

If you know quaternions, then you more--or-less know su(2). Basically, quaternions is su(2) "done wrong", due to historical accident. su(2) is the double-cover of http://en.wikipedia.org/wiki/Rotation_group_SO(3)

The reason that quaternions is 'wrong" is that i^2=j^2=k^2=-1 which is not the actual algebraic shape of 3D tangent space. by contrast, the SO/su groups get it right: L_x^2=L_y^2=L_z^2=+1 notice the plus one. This implies that the algebra is purely real, and does not require complex numbers to get it working. By making rotations purely real, you can say things like "object B is rotating around axis A" and you can actually point in the direction of axis A. With quaternions, you can't actually point in the direction "i" because its a complex number. That's just insane: real space is really 3-dimensional, there are no "imaginary" directions in it. 3D is not like a complex number.

The historical accident is, as far as I can tell, that one of the early pioneers of 3D graphics wrote a college textbook in the 1970's using quaternions, instead of so(3) or su(2). Why he did that, I can't guess .. presumably, he was ignorant of how rotations actually work in 3D space, which is bizarre, because its standard material for undergrad mechanical engineering and physics (where its done right). That mistake has been getting propagated ever since ... we shouldn't keep repeating the mistake over and over. (It gets repeated because it is partly harmless: the group manifolds are isomorphic, in the same way that so(2) and u(1) are isomorphic. So people get away with the crime.)

[Gaboose]

Ok. Just so you know, Blender uses quaternions. But we're not touching them from our software.

[linas]

Gahh. Like I said, someone fucked up in the 1970's and like a brainless zombie, the mistake just keeps stumbling along, multiplying ...