5 ms·

Nice. Yeah, the GL graphics code is pretty easy to convert to C++ when performance matters. It's wonderful to quickly prototype graphics code in Python with f

by palish 18y ago

Nice. Yeah, the GL graphics code is pretty easy to convert to C++ when performance matters. It's wonderful to quickly prototype graphics code in Python with full error checking. Also, if you haven't used it yet, check out Py++. It takes a lot of the pain out of hand-authoring a Boost.Python code file. I'm using Py++ to automatically generate Boost.Python bindings for the C++ library FCollada. (FCollada is a library for accessing 3D modeling data exported into the .dae COLLADA format.) Thanks for the tip about Cairo. Also, glVertex3d, 3dv, 3f, etc are part of the standard GL API. The 'd' suffix indicates 'double', 'f' indicates 'float', 'i' indicates 'int', 's' indicates 'short', and the 'v' suffix indicates that the function accepts a pointer rather than 3 separate components passed by value. Of course, the glVertex* API has been deprecated because VBOs are far more efficient. Just curious again, why do you use OpenGL for Anybots? Do you create simulations before building new robot prototypes?

tlb 18y ago
My point was there's no single 'gl.Vertex3' call that takes native Lisp numbers. Thinking about double/float/int/short should be abstracted out below the Lisp level. We use OpenGL to show real-time renderings of the robot, derived from the gyros and joint angle sensors. We have an analysis tool that shows, either in real time or post-run analysis, renderings synchronized with high-speed video of the robot and scrolling strip charts of every important variable over time. I always see much more looking at slow-motion videos & renderings afterwards than looking at the real robot. OpenGL rendering also turned out to be useful for extracting data from CAD models. Our CAD software (SolidWorks) can export STL files (a list of polygons) and we need to extract center of mass and moment of inertia and such. Doing that without visualizing it is a nightmare. We have done dynamics simulations (using ODE), but they haven't had much predictive value.
- palish 18y ago
  Ah. Very cool. Are you computing center of mass / moment of inertia yourself, or using a 3rd party library to do it? PhysX is free, and I believe it can do those calculations for you fairly automatically. (In PhysX, a 'scene' is composed of 'actors', and each actor is described by a set of shape descriptors. A shape descriptor can represent a box, a sphere, a capsule, a convex hull, etc. So a laptop actor could crudely be approximated with two box shape descriptors (one for the screen, one for the body) connected by a joint. Given those shape descriptors, the library calculates the actor's center of mass / moment of inertia / etc. If your CAD software simply exports a list of polygons, you'll need to decompose those into a set of convex hulls using convex hull decomposition techniques: http://codesuppository.blogspot.com/2006/04/approximate-convex-decomposition.html http://codesuppository.blogspot.com/2006/04/approximate-conv... ) You also might have better luck running dynamics simulations with PhysX than with ODE. It comes with a large number of code examples to get you started: http://developer.nvidia.com/object/physx_downloads.html http://developer.nvidia.com/object/physx_downloads.html
  - tlb 18y ago
    I use a very simple and exact O(N) algorithm to calculate mass properties of polyhedrons without computing convex hulls or anything: http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html Maybe 80 LOC. I'm not sure why anything more complex is needed. PhysX does seem promising.
    - palish 18y ago
      Yeah, that works. I mentioned computing convex hulls because I wasn't sure whether your CAD program exports "manifold" meshes, that is, closed polygonal meshes where each edge is connected to exactly two faces. When a mesh is manifold, it is possible to compute whether a point in space lies within or outside of the mesh, for example. It is also possible to compute the mesh's mass properties. In the video game industry, artists create models with techniques that are much less precise than CAD techniques, and so non-manifold meshes are very common, which makes them difficult to analyze in physical ways. The solution to that problem is to decompose the mesh into a set of convex hulls, then analyze the convex hulls. The other reason I mentioned convex hull computation is because PhysX can only simulate dynamic actors that are composed of boxes, spheres, capsules, and convex hulls, IIRC. Arbitrary polygon meshes aren't supported for dynamic actors, because they are very difficult to simulate in realtime. So if you wanted to use PhysX for dynamics simulations, you would probably need to decompose your model into a set of convex hulls. Good luck -- if you need any assistance with PhysX, feel free to contact me at shawnpresser@gmail.com.
  - danbmil99 18y ago
    "You also might have better luck running dynamics simulations with PhysX than with ODE." I worked on the simulator at Anybots, and I'm pretty much convinced a different physics engine isn't going to magically make things better (in terms of using simulations to predict real robot behavior). The problem is more about getting every little physical detail of the actual robot -- and its interactions with the environment -- into the model. The particulars of how collision, joint constraints, and dynamics are numerically computed isn't what makes the problem really hard.

by palish 18y ago

tlb 18y ago

My point was there's no single 'gl.Vertex3' call that takes native Lisp numbers. Thinking about double/float/int/short should be abstracted out below the Lisp level. We use OpenGL to show real-time renderings of the robot, derived from the gyros and joint angle sensors. We have an analysis tool that shows, either in real time or post-run analysis, renderings synchronized with high-speed video of the robot and scrolling strip charts of every important variable over time. I always see much more looking at slow-motion videos & renderings afterwards than looking at the real robot. OpenGL rendering also turned out to be useful for extracting data from CAD models. Our CAD software (SolidWorks) can export STL files (a list of polygons) and we need to extract center of mass and moment of inertia and such. Doing that without visualizing it is a nightmare. We have done dynamics simulations (using ODE), but they haven't had much predictive value.

palish 18y ago
Ah. Very cool. Are you computing center of mass / moment of inertia yourself, or using a 3rd party library to do it? PhysX is free, and I believe it can do those calculations for you fairly automatically. (In PhysX, a 'scene' is composed of 'actors', and each actor is described by a set of shape descriptors. A shape descriptor can represent a box, a sphere, a capsule, a convex hull, etc. So a laptop actor could crudely be approximated with two box shape descriptors (one for the screen, one for the body) connected by a joint. Given those shape descriptors, the library calculates the actor's center of mass / moment of inertia / etc. If your CAD software simply exports a list of polygons, you'll need to decompose those into a set of convex hulls using convex hull decomposition techniques: http://codesuppository.blogspot.com/2006/04/approximate-convex-decomposition.html http://codesuppository.blogspot.com/2006/04/approximate-conv... ) You also might have better luck running dynamics simulations with PhysX than with ODE. It comes with a large number of code examples to get you started: http://developer.nvidia.com/object/physx_downloads.html http://developer.nvidia.com/object/physx_downloads.html
- tlb 18y ago
  I use a very simple and exact O(N) algorithm to calculate mass properties of polyhedrons without computing convex hulls or anything: http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html http://www.cs.berkeley.edu/~jfc/mirtich/massProps.html Maybe 80 LOC. I'm not sure why anything more complex is needed. PhysX does seem promising.
  - palish 18y ago
    Yeah, that works. I mentioned computing convex hulls because I wasn't sure whether your CAD program exports "manifold" meshes, that is, closed polygonal meshes where each edge is connected to exactly two faces. When a mesh is manifold, it is possible to compute whether a point in space lies within or outside of the mesh, for example. It is also possible to compute the mesh's mass properties. In the video game industry, artists create models with techniques that are much less precise than CAD techniques, and so non-manifold meshes are very common, which makes them difficult to analyze in physical ways. The solution to that problem is to decompose the mesh into a set of convex hulls, then analyze the convex hulls. The other reason I mentioned convex hull computation is because PhysX can only simulate dynamic actors that are composed of boxes, spheres, capsules, and convex hulls, IIRC. Arbitrary polygon meshes aren't supported for dynamic actors, because they are very difficult to simulate in realtime. So if you wanted to use PhysX for dynamics simulations, you would probably need to decompose your model into a set of convex hulls. Good luck -- if you need any assistance with PhysX, feel free to contact me at shawnpresser@gmail.com.
- danbmil99 18y ago
  "You also might have better luck running dynamics simulations with PhysX than with ODE." I worked on the simulator at Anybots, and I'm pretty much convinced a different physics engine isn't going to magically make things better (in terms of using simulations to predict real robot behavior). The problem is more about getting every little physical detail of the actual robot -- and its interactions with the environment -- into the model. The particulars of how collision, joint constraints, and dynamics are numerically computed isn't what makes the problem really hard.