pydy_examples
pydy_examples copied to clipboard
pydy
Illustrative ex for viz
How about changing this example so that it imports the results of your three pendulum example and this would only have the code for the simulation and visualization. Right now you have the same code in both files and have to maintain them both.
I know that the essential.py is posted so that the example can work, but I would encourage you to use a more descriptive name in the future. The name essential doesn't really tell me what's in that file.
This has to do with illustrative_example.py:
I know I've said it before but I find it unnecessary for the user to make the visualization frames on their own. They could easily just forget to add one of the bodies in their multibody system. I imagine something like this:
scene = Scene('scene1', KanesMethod) # assuming Kane's Method knows about inertial frame.
# This will initialize a VisualizationFrame for each rigid body, with names <body_name>
print scene.vframe['link1']
scene.vframe['link1'].shape = shape1
scene.vframe['link2'].shape = shape2
scene.vframe['link3'].shape = shape3
I wish the pydy interface were a little different, so that this would ideally be:
sys = System('three_link_pendulum')
sys.add_rigid_body(RigidBody('link1', ...)
sys.add_rigid_body(RigidBody('link2', ...)
sys.add_rigid_body(RigidBody('link3', ...)
km = KanesMethod(sys)
# ...
scene = Scene('scene1', sys)
# as above
If we need to, we could resort to:
scene = Scene('scene1', body_list)
# as above
just as we pass a body list to KanesMethod. I think that this is better than doing the wiring between VFrames and RigidBody's ourselves. I'm happy to discuss this though.
So this is great because now I see how the visualization example would build directly off of a regular pydy example. Neat.
For my understanding: is the idea that when you serialize to a JSON file, that you'll print proper javascript code into the JSON file for fields like rotation_matrix, point/origin (using the code generation abilities)? Then, when the JSON file is deserialized into Javascript code/objects, and we also have access to integration results, we'll have the values of q1, etc. (the state) to plug into those expressions?
For the integration, how do we take care of having the user specify actual values for masses, lengths, inertia, etc? There should be a step that forces them to do this prior to integration. And that substitution needs to occur for the fields in VFrame (reference_frame, point/origin). Does that substitution occur before serialization to JSON or after deserialization into Javascript? Does the user provide just a single dict at some point containing all values to substitute?
@fitze to comment on your comment that starts with scene = Scene('scene1', KanesMethod)
I agree that having an interface to sympy mechanics that is more about adding bodies to a system is a good idea, but I don't think that you should remove or fundamentaly change what is there already. What is there already is the math side of things. The API handles the mathematics needed for rigid body dynamics. A layer of code can built built with this API that implements what you have in mind for a System class and adding bodies, but there are some tricky parts to getting that to work correctly for a generally complicated system.
Keep in mind that there may be many more viz frames than rigid bodies or vice versa. A visualization shouldn't be constrained by the rigid bodies present. I like keeping Scene un-(or less)aware of the rigid bodies in the system for this reason. Shapes that move around the scene in animation are often static attached to rigidbodies but they may be attached to particles and reference frames or just general points. Maybe I want to visualize a vector with an arrow that changes direction and length. All should be possible if we leave the VizFrames very general. This will allow us to specifically include which shapes we want in the animation.
@fitze
"So this is great because now I see how the visualization example would build directly off of a regular pydy example. Neat."
I imagined the json file (or string object) to have all of the numerical time series needed for the three.js animation + the metedata like shape type, color, size. So this json file would be a numerical data format that get's passed to Taruns's JS code. So if any system generates the json specification then our JS code can run it. It shouldn't have anything related to sympy mechanics in the file. Just the stuff that three.js needs for defining objects and their motions in a scene (and the camera).
@moorepants Thanks for your explanation about System. I definitely think that once the VizFrame's for the RigidBody's are added to the Scene (automatically), that the user should be able to continue to add VizFrame's and shapes to their will. This would still be easy to do I think. I didn't think about the case where you wouldn't want to visualize a rigid body.
And as for the contents of the JSON file, that helps me understand where the modularity comes in. I thought that we wanted the Python side to be modular too. But now I see; we want the JS code to be modular. This means that the JSON file will contain a 4x4 matrix for each step in the animation, for each body, correct?
I have the same confusion. say we have a 4by4 matrix from VFRame as .. [[sin(q1), cos(q2) ...], .... ] We get vals of q1 and q2 from Numerical integration. Then on substitution , we will get a transformation matrix, for each timestep, As each timestep would have its own val for q1,q2 on numerical integration.
Say on working on a problem for 100 timesteps, we would need to substitute and generate 100 4by4 matrices, save them in a JSON file, and then pass to the Javascript side. .. I am not sure about how it would affect the animation rendering performance.
Two ways :
-
pass only symbolics, and the substitution part occurs in javscript, will have rendering performance issues, as the animation frames would first do these calculations(substitution and simplification) and then render, not to mention the original three.js calculations that they do/require for basic static rendering.
-
pass all the calculated vals, (those 100 transformation matrices) to javascript. The animation would be smooth, but our JSON files tend to be bulky, considering we may have, say three rigidbodies and 100 timesteps, => 300 4by4 numerical matrices.
which can be the better approach?
Tarun,
Please git rm js/output.json because there are always conflicts when trying to switch branches and merging etc. It is a real nuisance. My modifications to the code allowed for much faster generation so it shouldn't be necessary to hang on to it. We can speed things up faster too once I figure out a few issues.
Remaining items before merge:
- [x] Fixed links in animation to have cylinders end at the joints.
- [x] Add spheres for the particles.
- [ ] Add a better figure.