Discussion of future Bullet Example contributions (Join us!)

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Discussion of future contributions and roadmap

Post by Erwin Coumans » Mon May 09, 2016 2:14 pm

Basroil wrote:
Erwin Coumans wrote:There are various examples in the Example Browser that allow motorized robots, loading the robot from a .urdf file, using btMultiBody (or btRigidBody+btTypedConstraint.
Yes, I'm aware of the examples. However, I have had some complaints from graduate students complaining that those are difficult to understand in a short time. Mixing urdf, multibody, and inverse dynamics all in one may be a bit much to spring on people, especially if they aren't looking for perfect robot control and an all-in-one solution. I'm currently suggesting people try the old motor control demo, but that one again lacks a full explanation of how motors work.

I was thinking something on the lines of a simple RRR or RRP (we can call them "backhoes" to match the forklift demo if calling it a "robot" is the issue) configuration to explain the relationship between max torque and desired velocity in standard (non-multibody) constraints, and likely how to have offsets (start at joint angle != 0). Not everyone needs purely torque based control after all, and in some cases it's actually a detriment to understanding the device ("smart servo" based toys/robots/etc especially, since they don't actually have torque input).
That is a pity to hear. I would expect the URDF loader to be easy to use to create a btMultiBody. Can't student just use the URDF importer as-is? Why do students need to know how the URDF loader internals are working?

Furthermore, you don't need to use inverse dynamics computed torque control, the ImportURDF examples use simple velocity control (and/or position control using PID), using a LCP constraint on a btMultiBody. That should be superior to using maximal coordinates btRigidBody for robotics.

How about re-creating the MotorControl demo using btMultiBody + URDF, or btMultiBody programmatically?

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Discussion of future contributions and roadmap

Post by Erwin Coumans » Mon May 09, 2016 2:24 pm

benelot wrote:I would love to see some programmatic setups of more complex robots as well.
There are various examples in the Example Browser. In API there is the Motor Control demo for btRigidBody+btTypedConstraint, and in InverseDynamics there is an InverseDynamics prog demo, not using URDF.
What do I have to do about this? I am working on Linux. Shouldn't there be any standard URDF to load? Or even multiples, which can be changed using a dropdown box? Currently, it is not really showing off in any way.
Are you using cmake or premake? Are you generating Makefiles (gmake) or use some IDE?
Can you please following those steps and the load a URDF? They should work!

Code: Select all

 git clone https://github.com/bulletphysics/bullet3
 cd bullet3/
 cd build3/
 ./premake4_linux64  gmake
 ./premake4_osx  gmake
 cd gmake/
 make -j8
 ../../bin/App_BulletExampleBrowser_xcode4_x64_debug 

If you use unmodified Bullet SDK, it should find the executable just fine, as long as you build in-source, because it finds the URDF files in the data directory.
benelot wrote: Additionally, I get a memory corruption crash when I switch back and forth from Inverse Dynamics URDF and Inverse Dynamics Prog. Not sure what is going on...
Is that after loading a URDF succesfully? If you can reproduce such crash, please provide callstack and repro steps, preferably from the console.
benelot wrote: Basroil, we could also port the old motor control demo
I am baffled that you didn't see the old motor control demo in the Example Browser: the Motor Control demo has been ported for a long while, it is example 7 under API. Have you tried running all examples in the Example Browser and reading the description what each example is about?

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Discussion of future contributions and roadmap

Post by Basroil » Mon May 09, 2016 4:16 pm

Erwin Coumans wrote:That is a pity to hear. I would expect the URDF loader to be easy to use to create a btMultiBody. Can't student just use the URDF importer as-is? Why do students need to know how the URDF loader internals are working?

Furthermore, you don't need to use inverse dynamics computed torque control, the ImportURDF examples use simple velocity control (and/or position control using PID), using a LCP constraint on a btMultiBody. That should be superior to using maximal coordinates btRigidBody for robotics.

How about re-creating the MotorControl demo using btMultiBody + URDF, or btMultiBody programmatically?
Well, for one the framework we have is built on what was originally 2.81, so no URDF or even multibody (all our robots are already simulated to within the encoder resolution with SI/MLCP, and would need to be tested again on multibody), so the URDF importer would also need to be added to our framework for that to work. More importantly though, those "students" (closer to researchers) are mechanical/electrical engineers, with basically no programming experience outside very simple Matlab code. I would love to redo half the framework again to allow for multibody and URDF, but it's pretty hard to do it alone and still do everything else I need to do (publish two more papers, dissertation defense, getting a job, etc :( ). Finally got a Master's student that is decent with C++, so URDF is likely to be added before I leave. That's a bit off topic though :arrow:

While URDF is easy to use once you know what it does, teaching them how to make an URDF (and XML in general) model of their particular robot before teaching them the basics like how joints work is a bit more difficult than simply showing them how each piece works at a basic level. I'm sure that a majority of users (and definitely your current target audience) can make sense of the current URDF examples (they aren't too difficult to use), but there are still some users that are not primarily CompSci and need a bit more hand holding when it comes to examples.

As I said before though, it's not really about "robots", rather explaining more on motorized constraints with as few pieces as needed. It's probably easier to just see it and critique then. I'll make a new thread for that topic in particular so this one is kept a bit more streamlined.

I'll see about adding in a multibody spider (last I remember multibody could be mixed with SI) to the motor control demo, but that is a bit different of a goal. It would definitely be useful as a test of how multibody and SI are different though, especially with higher mass ratios. I'll throw in that into the new thread too. Hopefully I can get started on that in two days, I have something to take care of tomorrow and want to make sure there's a decent amount of actual tutorial to go with the examples (hard to judge the point and effectiveness of the example without the documentation after all).

On a side note, you'll be surprised how well you can simulate modularized robots without using multibody or even non-physical damping (no ERP/CFM manipulation, just a single hinge with default parameters and body damping set to a very low number). Sure multibody is likely faster, more stable, and more precise, but you can get away with fairly good results without it :wink: ( even the DARPA challenge sim ended up skipping multibody this time around).

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Discussion of future contributions and roadmap

Post by Erwin Coumans » Mon May 09, 2016 5:48 pm

Basroil wrote:I would love to redo half the framework again to allow for multibody and URDF,
You could consider using the Example Browser framework instead of writing yet another framework ;-) ?
I plan to add parameter estimation as well, matching parameters a simulated robot with a real robot. Then you get a new URDF file (or SDF file etc) that makes it easier to transfer results from real robot to simulated. That is also needed for transfer learning, for example using Tensor Flow.

For Bullet, I created a new API, specifically for robotics. It is a single C header file. See Bullet/examples/SharedMemory/PhysicsClientC_API.h
I put a lot of focus on this API and create Python bindings to make it really easy to use. You could also play with this API, and use it in your own code. It is a server-client API, sending commands and receiving status. It can be used using shared memory, but also in-process using the same thread or separate thread. Extending it over GRPC or network is possible too.
Sure multibody is likely faster, more stable, and more precise, but you can get away with fairly good results without it :wink: ( even the DARPA challenge sim ended up skipping multibody this time around).
That was one of the failures of the Darpa challenge, their simulation failed in many ways and they had to keep on editing the URDF file, adding hacks to deal with mass ratios etc, because they didn't use reduced coordinate multi-body. I know the people behind the project very well, I visit the OSRF/Gazebo folks regularly.

Cheers,
Erwin

Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Discussion of future contributions and roadmap

Post by Basroil » Tue May 10, 2016 4:42 am

Erwin Coumans wrote: You could consider using the Example Browser framework instead of writing yet another framework ;-) ?
I plan to add parameter estimation as well, matching parameters a simulated robot with a real robot. Then you get a new URDF file (or SDF file etc) that makes it easier to transfer results from real robot to simulated. That is also needed for transfer learning, for example using Tensor Flow.

For Bullet, I created a new API, specifically for robotics. It is a single C header file. See Bullet/examples/SharedMemory/PhysicsClientC_API.h
I put a lot of focus on this API and create Python bindings to make it really easy to use. You could also play with this API, and use it in your own code. It is a server-client API, sending commands and receiving status. It can be used using shared memory, but also in-process using the same thread or separate thread. Extending it over GRPC or network is possible too.

That was one of the failures of the Darpa challenge, their simulation failed in many ways and they had to keep on editing the URDF file, adding hacks to deal with mass ratios etc, because they didn't use reduced coordinate multi-body.
It's more of a hardware control framework (rather than visualization), with simulation connected to the hardware control and communications rather than separate from the hardware, limited to modularized designs but a bit easier to add devices to in exchange. So it's well beyond the scope of the example browser :wink: . After all, the primary users in my case are ones with limited programming experience and no formal programming education. The system is not pretty, nor as generalized as something like ROS, but it's doing it's job pretty well for low-cost robots without being too difficult to use.

The physics client/server is something I've been looking into though, the shared memory idea is intriguing, though I need to look into simulation state copying. I've only started checking the stuff now, so a decision on integration is likely going to be very far down the line. Are there any plans for an example that shows full simulation state copies outside serialization and re-initialization? I've seen a few threads on "simulation rewind" that normally get referred to the serializer, perhaps there's a more automated way with the server/client?

And yes, it might have been one failure, though definitely not the only one :wink: ATLAS wasn't really made to be easy to simulate and control, which definitely didn't help, nor did the disjointed nature of the tasks (too many different tasks to optimize any single aspect of the robot, most couldn't even walk and move their arms at the same time).


On a more pertinent note, I've noticed that examples with an output window and controls (like InverseDynamics) tend to increase memory consumption by ~500kb (debug, VS2015) each time they are run, while ones without (like MultiDofCreateFunc) don't show such a memory increase. The memory increase is likely unrelated to benelot's crashes if his issue was only inversedynamics, and I'll see tomorrow night if it's actually the output window, the buttons/sliders, or just something on my end. Hopefully it's just something on my end, but I'm just throwing out the info just in case anyone else is seeing the issue.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Tue May 10, 2016 7:39 am

Erwin Coumans wrote: Are you using cmake or premake? Are you generating Makefiles (gmake) or use some IDE?
Can you please following those steps and the load a URDF? They should work!

Code: Select all

 git clone https://github.com/bulletphysics/bullet3
 cd bullet3/
 cd build3/
 ./premake4_linux64  gmake
 ./premake4_osx  gmake
 cd gmake/
 make -j8
 ../../bin/App_BulletExampleBrowser_xcode4_x64_debug 

If you use unmodified Bullet SDK, it should find the executable just fine, as long as you build in-source, because it finds the URDF files in the data directory.
I use the newest revision of your repository and do an out-of-source build with console CMake and then open it with eclipse, I am aware of the fact that premake is recommended, and now I probably see why. Why is an in-source build supported? That is not good practice I thought...
Erwin Coumans wrote: Is that after loading a URDF succesfully? If you can reproduce such crash, please provide callstack and repro steps, preferably from the console.
No, after it could not load it in my case. I just click between the examples back and forth and then it runs into a memory corruption. Interestingly, it even crashed again when starting again, I could only solve it by deleting the Bullet.txt file which saves the state. If we are already talking, I also have bad experiences with the multithreading example. It starts to run instantly when clicked and it is impossible to interrupt and the browser does not react to switching the example until it finishes. We could probably add some buttons to start and interrupt and warn the user about this. Or is this just my experience?
Erwin Coumans wrote: I am baffled that you didn't see the old motor control demo in the Example Browser: the Motor Control demo has been ported for a long while, it is example 7 under API. Have you tried running all examples in the Example Browser and reading the description what each example is about?
Oh, I saw it and I do not know the old examples that well, so I was confused by Basroil when he mentioned the old motor demo to be much better in another thread. Therefore, I thought we should maybe port it. I looked at every single example that is there and read the descriptions. Probably some of them did not work for me because of the Cmake issue and therefore I should switch to premake. I will write back how it worked.

User avatar
Erwin Coumans
Site Admin
Posts: 4193
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Discussion of future contributions and roadmap

Post by Erwin Coumans » Tue May 10, 2016 8:02 am

benelot wrote:out-of-source build with console CMake
I fixed this earlier today, now CMake will copy the 'data' resources in the right location. Please update try it again.
basroil wrote: example that shows full simulation state copies outside serialization and re-initialization?
Can you describe more in detail what you mean by state copies, why you need it, and why in-memory serialization is not a solution?
basroil wrote: tend to increase memory consumption by ~500kb
There are various (known) memory leaks in the examples, we need to fixed them before next release. This is unlikely the cause of a crash though, unless you run this on a commodore 64 ;-)

Thanks for the feedback!

mobeen
Posts: 122
Joined: Thu May 05, 2011 11:47 am

Re: Discussion of future contributions and roadmap

Post by mobeen » Tue May 10, 2016 8:55 am

Guys,
Sorry for interfering in. I am just keeping track of my own progress. I am done with the following tutorials.

http://bulletphysics.org/mediawiki-1.5. ... /Tutorials

Getting Started with Bullet
Understanding the Bullet ExampleBrowser framework
Simple Box
Multiple Boxes
Simple Distance Joint
Picking

I have also written a tutorial template which could be used by others to quickly create a tutorial article. I am still waiting for feedback on these.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Tue May 10, 2016 12:41 pm

mobeen wrote:Guys,
Sorry for interfering in. I am just keeping track of my own progress. I am done with the following tutorials.

http://bulletphysics.org/mediawiki-1.5. ... /Tutorials

Getting Started with Bullet
Understanding the Bullet ExampleBrowser framework
Simple Box
Multiple Boxes
Simple Distance Joint
Picking

I have also written a tutorial template which could be used by others to quickly create a tutorial article. I am still waiting for feedback on these.
I looked into your tutorials briefly. Over all, I think they are very good, however, they somehow read themselves like a code documentation. This is truly related to one's own style and preference, but I would love to make the tutorials as beautiful as for instance those on the Ogre3D page. I really enjoyed those tutorials because they provide a lot of background information for most things which are done.
Here is an example:
http://www.ogre3d.org/tikiwiki/tiki-ind ... =Tutorials

This could come handy for us later, because we will need to add background information when we provide content for the Bullet Manual. I think for a first iteration of tutorial, you did an amazing job, thanks Mobeen! I hope I find time to finish my parts quickly.

Edit: Also I think we should put the snapshot somewhere to the beginning, more like a teaser for the tutorial reader. Using images, you can easily see what you will get in the end.

mobeen
Posts: 122
Joined: Thu May 05, 2011 11:47 am

Re: Discussion of future contributions and roadmap

Post by mobeen » Tue May 10, 2016 5:54 pm

Thanks benelot for the feedback. I am currently trying to get the bare minimum that is required to understand the tutorial. The main idea of putting on the wiki was to have a shared place where the content could be edited on the fly as required.

I would suggest everyone reading the new tutorials on the wiki to please place [TODO] markers at all the places/headings where you think it would help to add more background information and a few pointers on what do you think should be added in it. That will clearly help me in refining the content.

As for the UserGuide, I would suggest we keep it as a shared google doc. Then all of us working on the userguide could read, review and refine content as necessary and once its contents are finalized, we can then do a latex version integrated in Bullet. But first lets finish the tutorials.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Tue May 10, 2016 6:42 pm

mobeen wrote:Thanks benelot for the feedback. I am currently trying to get the bare minimum that is required to understand the tutorial. The main idea of putting on the wiki was to have a shared place where the content could be edited on the fly as required.

I would suggest everyone reading the new tutorials on the wiki to please place [TODO] markers at all the places/headings where you think it would help to add more background information and a few pointers on what do you think should be added in it. That will clearly help me in refining the content.

As for the UserGuide, I would suggest we keep it as a shared google doc. Then all of us working on the userguide could read, review and refine content as necessary and once its contents are finalized, we can then do a latex version integrated in Bullet. But first lets finish the tutorials.
I agree on everything.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Wed May 11, 2016 1:20 am

I just finished the Inclined plane and newtonian pendulum example. I appended them as a zip and would like to get some feedback on them. If you like them, I make a pull request for them to be added.

The newtonian pendula length can be increased/decreased with keys 1 and 2, with 3 they can be pushed.

Good night!
Attachments
ExtendedTutorials.zip
(7 KiB) Downloaded 138 times

mobeen
Posts: 122
Joined: Thu May 05, 2011 11:47 am

Re: Discussion of future contributions and roadmap

Post by mobeen » Wed May 11, 2016 7:24 am

Hi Benelot,
Just tried your demos they are cool.

I was getting two compilation errors one for M_PI and other for assert.

My suggestions on these
1) Use SIMD_PI instead of M_PI and SIMD_HALF_PI for M_PI/2.0
2) Use btAssert instead of assert
3) In the initPhysics setup call, dont call these

Code: Select all

bool isDynamic = (mass != 0.f);

btVector3 localInertia(0,0,0);
if (isDynamic)
   colShape->calculateLocalInertia(mass,localInertia);
because createRigidBody is already doing it. I have already changed my local sources but I am yet to update my fork.

Other than that its a lot of fun :) Thanks for sharing.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Wed May 11, 2016 8:49 am

Hi Mobeen,

Thanks for mentioning, no idea why the other two worked, I must have some linux default includes in my IDE which should not be there. I will fix it with your suggestions and properly document it, then make a pull request.

benelot
Posts: 350
Joined: Sat Jul 04, 2015 10:33 am
Location: Bern, Switzerland
Contact:

Re: Discussion of future contributions and roadmap

Post by benelot » Sun May 15, 2016 9:32 am

Hello all! Sorry for being very busy, I could not yet contribute, since I am finishing my master's presentation this week. After that, I will finish my tutorial parts. What is next on our roadmap? Should we discuss the tutorials written so far as soon as I am done?

Post Reply