GSoC 2015: PyDy Viz Improvements (Interactive Generation of a System)

[Sahil Shekhawat]

Hi,
i am Sahil Shekhawat and want to improve PyDy Viz. I have some doubts regarding the roadmap.

1. It is mentioned in the roadmap about a Generic browser based viewer for dynamic engines(MG, pydy, etc.). So, Do you guys plan to write a generic browser on your own and still use WebGL or you guys plan to build a GUI tool that uses OpenGL? Currently, there are some bugs and some of the browser are not supported. We can also fix those bugs and create a browser based tool.

2. In the project "Interactive Generation of a System" We need to create a tool to create a system by just drag and drop BUT before that we must first decide on the base implementation like do we wish to shift to "PyThreeJs" as mentioned in one of the issues? or we will just use our own API which we currently have.?

If we wish to use our own GUI then we must start from scratch (i.e a new approach) and we can have both things supported. (i.e. browser and native gui).
I am thinking of have a blender like gui in which we can create a system and apply contraints which solves issues like cross browser/platform support, speed (OpenGL vs WebGL) and we can add tons of features in it like realtime simulation.

Can someone please provide feedback so that we can discuss further details about the working of project.
Thanks you

[Sahil Shekhawat]

To support my argument here is an example http://vispy.org/
It supports native OpenGL viz and also supports WebGL widgets. We can have something similar.

[Jason Moore]

HI Sahil,

Glad you are interested in the project.

1. It is mentioned in the roadmap about a Generic browser based viewer for dynamic engines(MG, pydy, etc.). So, Do you guys plan to write a generic browser on your own and still use WebGL or you guys plan to build a GUI tool that uses OpenGL? Currently, there are some bugs and some of the browser are not supported. We can also fix those bugs and create a browser based tool.

We want to stick with a browser based visualization tool as the main target. We've toyed with the idea of working with Adam Leeper to create a generic visualization tool that works with both PyDy and MotionGenesis (a proprietary tool out of Stanford). This is still a possibiity if someone wants to put in the time to generalize the code base.

We do not have plans to make an OpenGL based visualizer. It could be done but is not a priority. We think the future is the web and we want to be able to share our simulations on the web, especially through the IPython notebook platform.

2. In the project "Interactive Generation of a System" We need to create a tool to create a system by just drag and drop BUT before that we must first decide on the base implementation like do we wish to shift to "PyThreeJs" as mentioned in one of the issues? or we will just use our own API which we currently have.?

You are correct. We need to make our current visualizer much better before trying to tackle the "interactive generation of a system". That problem has soem similarities to the visualizer but the majority of the work in that project would be developing an api on the Python side that allows people to build systems in a high level way. Then you need to build the JS wrappers the connect that api to objects in the 3D visualization. This is huge project to tackle.

I would personally favor switching to PyThreeJS. If we work with the SAGE guys on pythreejs then we have mutliple people working on a better generic tool that we all can use. Our current code is a crude interface to threejs from python.

If we wish to use our own GUI then we must start from scratch (i.e a new approach) and we can have both things supported. (i.e. browser and native gui).

I personally see no need for a native GUI. But feel free to convince us otherwise.

I am thinking of have a blender like gui in which we can create a system and apply contraints which solves issues like cross browser/platform support, speed (OpenGL vs WebGL) and we can add tons of features in it like realtime simulation.

This is a huge undertaking and unlikely to be completed in a summer project, even working full time. We really need to improve what we have. Picking a small scope of improvements to the current system is a better idea.

To support my argument here is an example http://vispy.org/
It supports native OpenGL viz and also supports WebGL widgets. We can have something similar.

vispy is neat project. Actually our very first visualizer was http://vpython.org/ but we've moved away from tools like that (mayavi is another) and are focusing on webgl through threejs with IPython notebook integration.

If we design our code in modular way we could theoretically support other backends, like vispy, in the future. But that is not the primary target now. We just need a small feature set that works consistently and is pretty bug free.

Jason
moorepants.info
+01 530-601-9791

--
You received this message because you are subscribed to the Google Groups "PyDy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pydy+uns...@googlegroups.com.
To post to this group, send email to py...@googlegroups.com.
Visit this group at http://groups.google.com/group/pydy.
For more options, visit https://groups.google.com/d/optout.

[Sahil Shekhawat]

Please provide some feedback on this.
I have been playing for MapleSim for a while now. I am thinking of including all the basic stuff from MapleSim into this project which includes:

1. Dragging, dropping and connecting.
2. Using multibody components.
3. Creating subsystems
4. using sensors to get values like force at a particular point (Have not looked into this yet).
5. Something similar to "Probe" in MapleSim.

As you said earlier, this project will be divided into two parts:
1. Frontend: For gestures like dragging, dropping and connecting I will use interact.js. It will have tools to:

  1. View Panes based on type of view.
    a. 2-D View
    b. 3-D View
    c. 2-D and 3-D View (in two panes)
 
  2. View Panes based on type of display.
    a. Diagram
    b. Parameters
    c. Source Code  of system
 
  3. Tools
    a. Display documentation for a selected component.
    b. Display message console.
        1. Clear message console.
        2. Level of message console (debug, Normal, Quiet and Verbose)

2. Backend: It will generate the code based on the kinematic contraints and arrangement of bodies in GUI. It will be divided into several parts like:

• Reference Frames
• Various Basic Objects
• Forces
• EoMs
• System using Kanes Method.

Each of these parts  will have different classes which will generate codes. The generated code from all of these parts will be used to generate EoMs and Systems. There will be some predefined constraints also, which user can changed under settings.
GUI will send values of all constraints and interconnection of objects using arrays to the API via IPython module, mainly its Display capabilities for JavaScripts and HTML, in IPython Notebooks.(similar to the current working of pydy-viz). API will use these values and generate code using different classes.

This is a crude implementational details. I am working on a demo too.

On Monday, March 9, 2015 at 12:33:20 AM UTC+5:30, Sahil Shekhawat wrote:

[Sahil Shekhawat]

Can someone please confirm that I am going in right direction?

On Monday, March 9, 2015 at 12:33:20 AM UTC+5:30, Sahil Shekhawat wrote:

[Jason Moore]

Sahil,

This seems on track in general. Maplesim is likely a good thing to get ideas from. I don't know how it works and I don't think we really want to implement the "Simulink" style 2D layouts they seem to have. But the rest is likely very similar to something we'd want.

One thing I would like to stress is that your part 2, the backend, should come first because the front is useless without the backend. Also, I have the feeling that you may underestimate the difficulty of creating the backend. It isn't a trivial problem. I think you should start by running different PyDy examples to get a feel of the API to construct models. We probably should set the scope of the backend to deal with un-constrained problems at first. Chris did some ideation a while back on this: https://github.com/chrisdembia/pydy-linkage and I think Jim has some ideas on it too.

You need to flesh out some ideas in your application about this backend as I think it is the most important part. Once the backend idea is solid, the GUI code is effectively a light wrapper around calling the API. For example, adding a rigidbody to a system in a 3D gui may simply call "system.add_body()" and then connecting two bodies "system.body[0].connect(system.body[1])". The backend will have to manage funny things like disconnecting bodies (i.e removing joints) and prevent kinematic loops (or supporting them!).

The measurement idea in Maplesim is great, but we don't even have a good way to support output equations yet. So that is also a prerequsite. See: https://github.com/pydy/pydy/issues/136

My suggestion is to pick a very simple dynamics example and make a demo Python API that allows you to "build" that system in a high level way.

The backend can easily take the entire summer if we want to do it correctly, robustly, and have a strong feature set. But it will be worth thinking about what actions and features you may want in a graphical GUI to help define the features needed in the backend.

Jason
moorepants.info
+01 530-601-9791

--

[Sahil Shekhawat]

I have created a demo which is creating double_pendulum at https://github.com/sahilshekhawat/pydy-ingen
Chris, I would love to get your feedback on this.
This solves it as:
"""
from pydyingen import PyDyParticle, MultiBodySystem

sys = MultiBodySystem('sys')
sys.gravity_vector = sys.root_frame.x

par1 = PyDyParticle('par1', sys.root_frame, 'q1', sys.root_frame.z)
par2 = PyDyParticle('par2', sys.root_frame, 'q2', sys.root_frame.z)


sys.add_body(par1)
sys.add_body(par2)

par1.set_point('l', sys.origin, par1.frame.x)
par2.set_point('l', par1.point, par2.frame.x)

par1.set_ang_vel('u1', sys.root_frame, sys.root_frame.z, dynamic=True)
par2.set_ang_vel('u2', sys.root_frame, sys.root_frame.z, dynamic=True)

kanes_equations = sys.evaluate()
"""

There might be some bugs but overall this is capable of solving particle systems. Although it is not at all robust but I just wanted to show a demo of how it will look.
There is a main class "MultiBodySystem" which maintains root frame and all lists required for kanes method.
"PyDyParticle" is a wrapper on Particle class and provides high level features over it.

[Sahil Shekhawat]

I forgot to add bodies in the above example. It will look like this:

sys = MultiBodySystem('sys')
sys.gravity_vector = sys.root_frame.x

par1 = PyDyParticle('par1', sys.root_frame, 'q1', sys.root_frame.z)
par2 = PyDyParticle('par2', sys.root_frame, 'q2', sys.root_frame.z)

sys.add_body(par1)
sys.add_body(par2)

par1.set_point('l', sys.root_body.point, par1.frame.x)

par2.set_point('l', par1.point, par2.frame.x)

par1.set_ang_vel('u1', sys.root_frame, sys.root_frame.z, dynamic=True)
par2.set_ang_vel('u2', sys.root_frame, sys.root_frame.z, dynamic=True)

sys.root_body.connect_body(par1, sys)
par1.connect_body(par2)

kanes_equations = sys.evaluate()

[Jason Moore]

Sahil,

This demo looks like a great start. You've created a system builder that can build chains of particles that are fixed in chains of rotating reference frames. This is along the lines of what you'd need. It'd probably best to start like this and generalize building chains of bodies without constraints. This can covers a lot of systems.

Jason
moorepants.info
+01 530-601-9791

[Chris Dembia]

+1. I like it. I want whatever we develop to also support specification of joints instead of position and angular velocity. This might be one of the more challenging things to tackle: an interface that allows joints OR the more general specification that Sahil has above. One option is a "custom joint" that allows completely general specification of position and angular velocity.

[Chris Dembia]

Sahil, I know that was a mockup but I think it would be bad to have a Particle class and then a separate PyDyParticle class. Ideally, Particle would just have the necessary functionality. OR, Just have a Particle class within a separate module. (e.g., sympy.physics.mechanics.Particle vs pydy.Particle).

[Sahil Shekhawat]

Thanks Chris, I am working on the interface. It will include joints by restricting the motion of both the bodies. Also,  I am including more specific classes for more quick construction of solids like specific joints and forces.
Is this package supposed to be in SymPy or PyDy. I thought that it will remain in PyDy?

[Chris Dembia]

Sounds great. I haven't been paying too much attention to the discussion so I don't know where the code is supposed to go.

[Jason Moore]

Sahil,

This code could possibly be in SymPy or PyDy. I'd suggest just putting it in PyDy for now. But if you want to submit apps to SymPy also, then you could. But you'd need to keep the project primarily symbolic.

Jason
moorepants.info
+01 530-601-9791

[Sahil Shekhawat]

Thanks Jason,
Yes, it will be purely symbolic.

[Jason Moore]

I thought you also had the goal of making the JS GUI tool?

Jason
moorepants.info
+01 530-601-9791

[Sahil Shekhawat]

Sorry, I misunderstood that, I am writing my proposal and a lot of other things are going on.

I am applying under PyDy only and the code base will be in PyDy and About the JS GUI tool. I have included that in "If I have time and after gsoc" sections. But If you think that I will be able to complete both of them in summer then I can update it.

Sorry again, I haven't slept :)

[Sahil Shekhawat]

I have update my proposal, Please review it https://github.com/pydy/pydy/wiki/GSOC-2015-Application:-Sahil-Shekhawat-%28Interactive-Generation-of-a-System%29

[Sahil Shekhawat]

I have submitted my application to PSF. Anything you want that my proposal should have? You can access it, right?

[Jason Moore]

If anything else is needed we will ask you during the proposal review weeks. Thanks Sahil and good luck!

Jason
moorepants.info
+01 530-601-9791