bdaiinstitute/spatialmath-python

Fixed a bug in transforms3d.py

Closed this issue · 3 comments

First of all, let me express my deep appreciation for your work and thank you for sharing your experience and knowledge with the world in this way.
I hope I'am not wrong in assuming that a mistake has crept in the transforms3d.py in lines 1772-1775.

I think that for the trplot function to work properly the following changes need to be made:

o = T @ np.array([0, 0, 0, 1])
x = T @ np.array([length, 0, 0, 1])
y = T @ np.array([0, length, 0, 1])
z = T @ np.array([0, 0, length, 1])

Best regards,
Christian

drgsr commented

I second that observation.
If the Transform to be displayed is not in the origin, the "length" parameter different to "1" lead to a non-orthogonal coordinate system displayed --- and the coordinate system arrows are misaligned w.r.t. to the "length=1" arrows.

See the following pyhton code to provoke the misbehaviour:

##########################################################
from spatialmath import SE3
#Plot works as expected - since the coosys is located in the origin
tP1=SE3( 0+ 0.0, 0.0, 0)
tP1.plot(block=False,length=0.1)
tP1.plot(block=False,length=1)
# Now - move it out from origin
tP1=SE3( 0.5+ 0.0, 0.0, 0)
tP1.plot(block=False,length=1)
tP1.plot(block=False**,length=0.1**)
# Expectation: The coordinate system is displayed with "just shorter" arrows, but the arrows are pointing in total strange directions.

The reason is already described in the predeccessing message.

Best regards,
DrG
PS: I appreciate working with the robotics toolbox@python

Both, thanks for your interest. Am pretty sure this was fixed in a recent PR. Most uptodate code in on GH not PyPI. The line numbers you mention don't match the code.

drgsr commented

Thanks,
I can conform, that an update/upgrade on the recent GitHub Version did the job.