Discussion:
[Rock-dev] vizkit3d: fixing interpretation of transformer configuration
Alexander Duda
2014-05-21 08:27:18 UTC
Permalink
Hi,

there is a change on master how vizkit3d interprets the transformer
configuration. The change is necessary because vizkit3d and
driver/transfomer were using different ones:

Vizkit3d and driver/transformer are now using the following convention:
* All transformations are defined as SOURCE_IN_TARGET frame.

Example:
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")

Meaning:
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
This is also the reason for its name body_in_world:
points_in_body*body_in_world=points_in_world

At the same time the transformation T also describes the translation and
rotation to convert a world coordinate system to a body coordinate system:
body = world*T = world*world_to_body = world*body_in_world
world_to_body = body_to_world^(-1) = body_in_world

Greets Alex
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
Leif Christensen
2014-05-21 08:35:49 UTC
Permalink
Post by Alexander Duda
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
If we are talking about Transformation Matrices and points, it should
imho be

body_in_world*points_in_body = points_in_world

since we are talking about a Matrix-Vector-Produkt.

LG,
Leif
--
Leif Christensen

DFKI Bremen
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0)421 17845-4149
Fax: +49 (0)421 17845-4150
E-Mail: leif.christensen at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------
Alexander Duda
2014-05-21 08:40:12 UTC
Permalink
Post by Leif Christensen
Post by Alexander Duda
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
If we are talking about Transformation Matrices and points, it should
imho be
body_in_world*points_in_body = points_in_world
since we are talking about a Matrix-Vector-Produkt.
At least someone is reading this ;-)

Alex
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
Javier Hidalgo Carrió
2014-05-21 09:55:53 UTC
Permalink
Hi Alex,

I hope this does not change how the TransformerGraph of gui/vizkit3d
visualizes the transformation matrices.
Because from my point of view, the driver/transformer is the one which
has a confusing way of interpreting transformations.

Transformation is just a matrix which express one frame with respect to
another. That is all!
Therefore, this is what we should specify in the transformer. Meaning
that, for example:
T_2_3 is a matrix which express frame_3 w.r.t frame_2. In algebra, it
means the base of the subspace frame_3 is expressed (columns vectors) in
the base of the subspace of frame_2.
Another thing is what the user can do with such a matrix. For example:
v2 = T_2_3 * v3 (v2 is vector expressed in frame2 and v3 is a vector
expressed in frame_3). Which convert v3 into v2 and here is when the
different interpretation comes.

Thanks for the work,

Javier.
Post by Alexander Duda
Hi,
there is a change on master how vizkit3d interprets the transformer
configuration. The change is necessary because vizkit3d and
* All transformations are defined as SOURCE_IN_TARGET frame.
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
At the same time the transformation T also describes the translation and
body = world*T = world*world_to_body = world*body_in_world
world_to_body = body_to_world^(-1) = body_in_world
Greets Alex
Alexander Duda
2014-05-21 10:34:10 UTC
Permalink
Post by Javier Hidalgo Carrió
Hi Alex,
I hope this does not change how the TransformerGraph of gui/vizkit3d
visualizes the transformation matrices.
The visualization stays the same. But the interpretation of the
transformer configuration changes for vizkit3d only.

Former:
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"world"
=> "body")

must no be written as:
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")

to have the same visualization in vizkit3d (this is aligned with the
transformer)

Greets Alex
Post by Javier Hidalgo Carrió
Because from my point of view, the driver/transformer is the one which
has a confusing way of interpreting transformations.
Transformation is just a matrix which express one frame with respect to
another. That is all!
Therefore, this is what we should specify in the transformer. Meaning
T_2_3 is a matrix which express frame_3 w.r.t frame_2. In algebra, it
means the base of the subspace frame_3 is expressed (columns vectors) in
the base of the subspace of frame_2.
v2 = T_2_3 * v3 (v2 is vector expressed in frame2 and v3 is a vector
expressed in frame_3). Which convert v3 into v2 and here is when the
different interpretation comes.
Thanks for the work,
Javier.
Post by Alexander Duda
Hi,
there is a change on master how vizkit3d interprets the transformer
configuration. The change is necessary because vizkit3d and
* All transformations are defined as SOURCE_IN_TARGET frame.
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
At the same time the transformation T also describes the translation and
body = world*T = world*world_to_body = world*body_in_world
world_to_body = body_to_world^(-1) = body_in_world
Greets Alex
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
Javier Hidalgo Carrió
2014-05-22 17:24:53 UTC
Permalink
Hi Alex,

The visualization stays the same. But the interpretation of the
transformer configuration changes for vizkit3d only.
Post by Alexander Duda
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"world"
=> "body")
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")
It works for me when using static transformations. But, regarding
dynamic transformations:
Does it also apply to the dynamic transformations given by a rbs on an
output port?

Former:
dynamic_transform "vicon.pose_samples", "world" => "body"
with rbs.sourceFrame = "world"
with rbs.targetFrame = "body"

must now be written as:
dynamic_transform "vicon.pose_samples", "body" => "world"
with rbs.sourceFrame = "body"
with rbs.targetFrame = "world"

However, in the transformer_broadcaster the frames for dynamic
transformation are called from_frame and to _frame.
I am not making it work with the new interpretation. Did anyone already
try it?

Thanks,

Javier.
Post by Alexander Duda
to have the same visualization in vizkit3d (this is aligned with the
transformer)
Greets Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transformer_broadcaster.png
Type: image/png
Size: 265808 bytes
Desc: not available
Url : Loading Image...
Alexander Duda
2014-05-22 17:53:36 UTC
Permalink
Before, the change was made vizikt3d was showing the transformations in
reversed order and was not aligned with the transformer configuration.
This should be fixed by now.

The only thing you have to do is to correctly configure the transformer.
Nothing has changed here.

All tranformations are given as source_in_target which is unfortunately
called source_to_target in our code being ambiguous because no one knows
if the transformation is transforming samples or coordinate systems (in
our case samples).

Alex
Post by Javier Hidalgo Carrió
Hi Alex,
The visualization stays the same. But the interpretation of the
transformer configuration changes for vizkit3d only.
Post by Alexander Duda
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"world"
=> "body")
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")
It works for me when using static transformations. But, regarding
Does it also apply to the dynamic transformations given by a rbs on an
output port?
dynamic_transform "vicon.pose_samples", "world" => "body"
with rbs.sourceFrame = "world"
with rbs.targetFrame = "body"
dynamic_transform "vicon.pose_samples", "body" => "world"
with rbs.sourceFrame = "body"
with rbs.targetFrame = "world"
However, in the transformer_broadcaster the frames for dynamic
transformation are called from_frame and to _frame.
I am not making it work with the new interpretation. Did anyone
already try it?
Thanks,
Javier.
Post by Alexander Duda
to have the same visualization in vizkit3d (this is aligned with the
transformer)
Greets Alex
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
Sylvain Joyeux
2014-05-22 18:51:55 UTC
Permalink
Can one of you write down all that stuff (wording, exact mathematical
meaning, conventions in naming variables in the code, ...) right now (not
"later when I have the time") in a document in the "conventions and
guidelines part" of the wiki, and refer to it in the doxygen documentation
of the RigidBodyState as well as the transformer ?

Sylvain
Post by Alexander Duda
Before, the change was made vizikt3d was showing the transformations in
reversed order and was not aligned with the transformer configuration.
This should be fixed by now.
The only thing you have to do is to correctly configure the transformer.
Nothing has changed here.
All tranformations are given as source_in_target which is unfortunately
called source_to_target in our code being ambiguous because no one knows
if the transformation is transforming samples or coordinate systems (in
our case samples).
Alex
Post by Javier Hidalgo Carrió
Hi Alex,
The visualization stays the same. But the interpretation of the
transformer configuration changes for vizkit3d only.
Post by Alexander Duda
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"world"
Post by Javier Hidalgo Carrió
Post by Alexander Duda
=> "body")
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
Post by Javier Hidalgo Carrió
Post by Alexander Duda
=> "world")
It works for me when using static transformations. But, regarding
Does it also apply to the dynamic transformations given by a rbs on an
output port?
dynamic_transform "vicon.pose_samples", "world" => "body"
with rbs.sourceFrame = "world"
with rbs.targetFrame = "body"
dynamic_transform "vicon.pose_samples", "body" => "world"
with rbs.sourceFrame = "body"
with rbs.targetFrame = "world"
However, in the transformer_broadcaster the frames for dynamic
transformation are called from_frame and to _frame.
I am not making it work with the new interpretation. Did anyone
already try it?
Thanks,
Javier.
Post by Alexander Duda
to have the same visualization in vizkit3d (this is aligned with the
transformer)
Greets Alex
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140522/d238ffdb/attachment.htm
Alexander Duda
2014-05-23 10:23:00 UTC
Permalink
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.

Alex
Post by Sylvain Joyeux
Can one of you write down all that stuff (wording, exact mathematical
meaning, conventions in naming variables in the code, ...) right now
(not "later when I have the time") in a document in the "conventions
and guidelines part" of the wiki, and refer to it in the doxygen
documentation of the RigidBodyState as well as the transformer ?
Sylvain
On Thu, May 22, 2014 at 7:53 PM, Alexander Duda
Before, the change was made vizikt3d was showing the
transformations in
reversed order and was not aligned with the transformer configuration.
This should be fixed by now.
The only thing you have to do is to correctly configure the transformer.
Nothing has changed here.
All tranformations are given as source_in_target which is
unfortunately
called source_to_target in our code being ambiguous because no one knows
if the transformation is transforming samples or coordinate systems (in
our case samples).
Alex
Post by Javier Hidalgo Carrió
Hi Alex,
The visualization stays the same. But the interpretation of the
transformer configuration changes for vizkit3d only.
Post by Alexander Duda
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"world"
Post by Javier Hidalgo Carrió
Post by Alexander Duda
=> "body")
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
Post by Javier Hidalgo Carrió
Post by Alexander Duda
=> "world")
It works for me when using static transformations. But, regarding
Does it also apply to the dynamic transformations given by a rbs
on an
Post by Javier Hidalgo Carrió
output port?
dynamic_transform "vicon.pose_samples", "world" => "body"
with rbs.sourceFrame = "world"
with rbs.targetFrame = "body"
dynamic_transform "vicon.pose_samples", "body" => "world"
with rbs.sourceFrame = "body"
with rbs.targetFrame = "world"
However, in the transformer_broadcaster the frames for dynamic
transformation are called from_frame and to _frame.
I am not making it work with the new interpretation. Did anyone
already try it?
Thanks,
Javier.
Post by Alexander Duda
to have the same visualization in vizkit3d (this is aligned
with the
Post by Javier Hidalgo Carrió
Post by Alexander Duda
transformer)
Greets Alex
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <tel:%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150> (Faxe
bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de <mailto:Alexander.Duda at dfki.de>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/3640cc7d/attachment.htm
Javier Hidalgo Carrió
2014-05-23 12:39:38 UTC
Permalink
Hi Alex,
Thanks for taking the initiative. It is clear to me and there is not
doubt when using static transformations.
However, I added the case when using dynamic transformations. Please
fill free to edit as well.

Javier.
Post by Alexander Duda
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/9a7eb632/attachment.htm
Janosch Machowinski
2014-05-23 13:07:41 UTC
Permalink
Sorry Guys,
but I don't get your source in target thing.
All our transformations are simply a transformation from a frame
A to a frame B. This corresponds with the naming scheme of source and
target and 'body2Odometry'
Also
Point_b = a2b * Point_a
is for me a completely logical way of writing this down.
Greetings
Janosch
Post by Javier Hidalgo Carrió
Hi Alex,
Thanks for taking the initiative. It is clear to me and there is not
doubt when using static transformations.
However, I added the case when using dynamic transformations. Please
fill free to edit as well.
Javier.
Post by Alexander Duda
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.
Alex
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/63c52d7f/attachment-0001.htm
Alexander Duda
2014-05-23 13:29:28 UTC
Permalink
Post by Janosch Machowinski
Sorry Guys,
but I don't get your source in target thing.
All our transformations are simply a transformation from a frame
A to a frame B. This corresponds with the naming scheme of source and
target and 'body2Odometry'
Also
Point_b = a2b * Point_a
is for me a completely logical way of writing this down.
Greetings
Janosch
No, they are not transformations of frames they are the transformation
of samples (which is the inverse) and this is exactly the reason why a2b
is a bad naming.

I updated the wiki for dynamic transformations. There is no different
between static and dynamic transformations. Also the visualization of
the RigidBodyState should be according to ainb (in the source code
called a2b because of historical reason but the meaning is the same ).
If this is not the case then there is a mistake which has to be fixed.

Alex
Post by Janosch Machowinski
Post by Javier Hidalgo Carrió
Hi Alex,
Thanks for taking the initiative. It is clear to me and there is not
doubt when using static transformations.
However, I added the case when using dynamic transformations. Please
fill free to edit as well.
Javier.
Post by Alexander Duda
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.
Alex
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/e241eaff/attachment.htm
Sascha Arnold
2014-05-23 13:30:15 UTC
Permalink
Hi,
currently a Transformation body2Odometry is the same as bodyInOdometry.
Witch transformes a sample from the body frame to the odometry frame.

What we have to define is what is the target and what is the source in
that case.
One can say the source is the body frame and the target is the odometry
frame, because the sample is transformed that way. But the
Transformation (the arrow direction) points from odometry to body in
that case, therefore one can also say odometry is the source and body is
the target.

The Proposal was to use the 'in' definition in the future to be clearer
here.


Sascha
Post by Janosch Machowinski
Sorry Guys,
but I don't get your source in target thing.
All our transformations are simply a transformation from a frame
A to a frame B. This corresponds with the naming scheme of source and
target and 'body2Odometry'
Also
Point_b = a2b * Point_a
is for me a completely logical way of writing this down.
Greetings
Janosch
Post by Javier Hidalgo Carrió
Hi Alex,
Thanks for taking the initiative. It is clear to me and there is not
doubt when using static transformations.
However, I added the case when using dynamic transformations. Please
fill free to edit as well.
Javier.
Post by Alexander Duda
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.
Alex
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Sascha Arnold
Unterwasserrobotik

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-4197
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Sascha.Arnold at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/79fc5aa0/attachment.htm
Javier Hidalgo Carrió
2014-05-23 13:32:23 UTC
Permalink
Post by Janosch Machowinski
Sorry Guys,
but I don't get your source in target thing.
All our transformations are simply a transformation from a frame
A to a frame B. This corresponds with the naming scheme of source and
target and 'body2Odometry'
Also
Point_b = a2b * Point_a
is for me a completely logical way of writing this down.
Just for the small difference that in reality (in a mathematical
meaning) is
point_b = (a2b)^-1 * point_a

What you are calling a2b in reality is b2a in terms of transforming
frames (b2a = (a2b)^-1 )
In your case you are not transforming frames you are transforming points
expressed in frames. This is what Alex called as "Source in target"
thing. It is not more than "a expressed with respect to b" which is b2a.

I hope it helps

Javier.
Post by Janosch Machowinski
Greetings
Janosch
Post by Javier Hidalgo Carrió
Hi Alex,
Thanks for taking the initiative. It is clear to me and there is not
doubt when using static transformations.
However, I added the case when using dynamic transformations. Please
fill free to edit as well.
Javier.
Post by Alexander Duda
https://rock.opendfki.de/wiki/WikiStart/Standards/RG10
Feel free to edit it.
Alex
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140523/c057bc64/attachment.htm
Jakob Schwendner
2014-05-21 10:10:59 UTC
Permalink
Post by Alexander Duda
Hi,
there is a change on master how vizkit3d interprets the transformer
configuration. The change is necessary because vizkit3d and
* All transformations are defined as SOURCE_IN_TARGET frame.
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
=> "world")
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
At the same time the transformation T also describes the translation and
body = world*T = world*world_to_body = world*body_in_world
world_to_body = body_to_world^(-1) = body_in_world
in all our code we use framea TO frameb as a convention. Changing it to
something which uses @in@ is confusing (at least to me) and imho at least
requires a discussion before introducing something like that.

cheers,

Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140521/7c55ef4a/attachment.htm
Alexander Duda
2014-05-21 10:29:43 UTC
Permalink
Post by Alexander Duda
Post by Alexander Duda
Hi,
there is a change on master how vizkit3d interprets the transformer
configuration. The change is necessary because vizkit3d and
* All transformations are defined as SOURCE_IN_TARGET frame.
static_transform(Eigen::Vector3.new(0.0,0.0,3.0),
Eigen::Quaternion.from_euler(Eigen::Vector3.new(Math::PI,0,0),2,1,0),"body"
Post by Alexander Duda
=> "world")
The defined transformation T describes the transformation to convert
samples taken in a body coordinate system to a world coordinate system.
points_in_body*body_in_world=points_in_world
At the same time the transformation T also describes the translation
and
Post by Alexander Duda
rotation to convert a world coordinate system to a body coordinate
body = world*T = world*world_to_body = world*body_in_world
world_to_body = body_to_world^(-1) = body_in_world
in all our code we use framea TO frameb as a convention. Changing it
least requires a discussion before introducing something like that.
This wording is only used for explanation. All our code stays the same.
But unfortunately the wording framea TO frameb is ambiguous in this context.

Alex
Post by Alexander Duda
cheers,
Jakob
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140521/ecc040fd/attachment.htm
Loading...