Skip to content
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.

Sign up for GitHub

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

Jump to bottom

TypeError when visualizing external wrench #34

Closed
jarvisschultz opened this issue Mar 23, 2017 · 0 comments
Closed

TypeError when visualizing external wrench #34

jarvisschultz opened this issue Mar 23, 2017 · 0 comments
Labels
bug

Comments

@jarvisschultz
Copy link
Contributor

jarvisschultz commented Mar 23, 2017 •
edited
Loading

Below is MWE:

import trep
from trep import tx,ty,tz,rx,ry,rz
import trep.visual as visual

system = trep.System()
frames = [
    ty(3),
    rx("theta"), [ty(3, mass=1)]
    ]
system.import_frames(frames)
trep.forces.BodyWrench(system, system.frames[-1], (0, 0, "external", 0, 0, 0))
q = (0,)
visual.visualize_3d([ visual.VisualItem3D(system, [0, 1], [q, q]) ])

Running this on my system produces the following error:

Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/view3d.py", line 283, in paintGL
    item.draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 187, in draw
    self.auto_draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 223, in auto_draw
    part.opengl_draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/forces/bodywrench.py", line 104, in opengl_draw
    glVertex3f(float(self.wrench[0]), float(self.wrench[1]), float(self.wrench[2]))
TypeError: float() argument must be a string or a number
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/view3d.py", line 283, in paintGL
    item.draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 187, in draw
    self.auto_draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 210, in auto_draw
    glEnd()
  File "/usr/lib/python2.7/dist-packages/OpenGL/latebind.py", line 61, in __call__
    return self.wrapperFunction( self.baseFunction, *args, **named )
  File "/usr/lib/python2.7/dist-packages/OpenGL/GL/exceptional.py", line 57, in glEnd
    return baseFunction( )
  File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 208, in glCheckError
    baseOperation = baseOperation,
OpenGL.error.GLError: GLError(
        err = 1282,
        description = 'invalid operation',
        baseOperation = glEnd,
        cArguments = ()
)
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/view3d.py", line 283, in paintGL
    item.draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 187, in draw
    self.auto_draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/visual/visualitem.py", line 223, in auto_draw
    part.opengl_draw()
  File "/usr/local/lib/python2.7/dist-packages/trep-1.0.2-py2.7-linux-x86_64.egg/trep/forces/bodywrench.py", line 104, in opengl_draw
    glVertex3f(float(self.wrench[0]), float(self.wrench[1]), float(self.wrench[2]))
TypeError: float() argument must be a string or a number
jarvisschultz added a commit that referenced this issue Mar 23, 2017
@jarvisschultz
Fixing #34
8607039 
Small issues existed in both trep/forces/spatialwrench.py and
trep/forces/bodywrench.py when accessing the current values of the wrench. These
issues did not exist in trep/forces/hybridwrench.py, but I used the opportunity
to clean up some trailing whitespace.

While debugging this, I also discovered another small issue. When passing a list
of inputs to the VisualItem constructor, the user was previously expected to
pass a list that was one time index shorter than that used for the time and
configuration lists. This makes some sense because for a given time window
from (k) to (k+1), the solved VI will know (q(k), p(k)) and (q(k+1), p(k+1)),
and it will also know u(k) but not u(k+1). However, this was causing issues in
setTime() when the interpolation function for u was then asked to interpolate
outside of the range of times originally passed in. We could fix this with some
simple try-except blocks, or always handle the u interpolation slightly
differently than the q interpolation. Instead, I chose to require an equal
length u array. The user can always zero-pad. Would be better to more robustly
handle this in the future, but for now, this is fine.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
bug
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@jarvisschultz