s-nakaoka / choreonoid

An integrated graphical robotics application framework
http://choreonoid.org
Other
94 stars 58 forks source link

Use a default format when loading a body item #242

Closed gergondet closed 4 years ago

gergondet commented 4 years ago

This PR sets a default format when loading a body item that doesn't have a format entry.

It might be the wrong place to handle this but I'm not sure where/when the format entry is used within the BodyItem class

s-nakaoka commented 4 years ago

Thank you for the pull request. I'm sorry, I didn't quite understand why this fix was necessary. I wonder if model files saved by the older Choreonoid versions couldn't be loaded. In fact I had put a few bugs in loading a body from a project file. Now the bugs are fixed in the latest revisions, so could you test if the problem is fixed in the latest revision? Or please tell me more detailed information why this fix is necessary. Thank you for your cooperation in advance.

gergondet commented 4 years ago

Dear Nakaoka-san,

Sorry the initial issue should have been clearer.

I'm facing an issue when loading cnoid project that were generated with older Choreonoid versions. (For example: https://github.com/jrl-umi3218/mc_openrtm/blob/master/projects/JVRC1/cnoid/sim_mc.in.cnoid)

In particular, it has a Body/BodyItem entry that does not have a format entry in data.

It crashes when the simulation starts as it seems that the body is not correctly loaded when the entry is absent.

Crash stacktrace:

#1  0x00007fffc65d9762 in cnoid::VirtualRobotRTC::inputDataFromSimulator(cnoid::BodyRTCItem*) () at /usr/local/bin/../lib/choreonoid-1.8/libCnoidOpenRTMPlugin.so
#2  0x00007fffc611d1cb in cnoid::SimulatorItem::Impl::stepSimulationMain() () at /usr/local/bin/../lib/choreonoid-1.8/libCnoidBodyPlugin.so
#3  0x00007fffc611d8b8 in cnoid::SimulatorItem::Impl::run() () at /usr/local/bin/../lib/choreonoid-1.8/libCnoidBodyPlugin.so
#4  0x00007ffff71b217d in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007ffff53006db in start_thread (arg=0x7fffab6d1700) at pthread_create.c:463
#6  0x00007ffff689588f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
s-nakaoka commented 4 years ago

It crashes when the simulation starts as it seems that the body is not correctly loaded when the entry is absent.

OK, so you are able to load the model, but when you do a simulation with it, the simulation crashes. And when you explicitly specify the model file format as you fixed, the loaded model seems the same as the previous case, but you can do simulation without a crash. Is this right?

Sorry, still I'm not sure why the simulation crashes although the model can be loaded. If the model file format is omitted, the default file format is used. As a result, the model in a older project file may be unable to be loaded due to the difference of the file format, but if the model is successfully loaded, there should be no difference between the models. So I have to know what is different between the model loaded without the explicit format specification and the model with it. Do you have any idea about it?

gergondet commented 4 years ago

Actually if I load the file then the robot does appear but its position and initial configuration is wrong:

Screenshot 2020-06-24 13:30:17

As you can see in the screenshot it complains there's a missmatch between the stored joint size and the actual body joints size:

Warning: Mismatched size of the stored joint positions for JVRC1
Warning: Mismatched size of the stored initial joint positions for JVRC1

If I recall correctly from a previous debugging session the loaded body has indeed no joints.

If I specify format: CHOREONOID-BODY then everything is fine.

s-nakaoka commented 4 years ago

Thank you very much for the pertinent information. I was able to reproduce this problem in my environment. I'm sorry for the inconvenience. I will try to fix it now.

s-nakaoka commented 4 years ago

I have fixed the bug. 26d1fd93295c350fa07547d38a2e34e4463c63bb

This problem was caused by a bug in the code that determines the default file format. For BodyItem, there are two builtin loaders. One is for the model files including the YAML-based body file and the OpenHRP model file based on VRML, and the other is for loading a general mesh file as a rigid body that has the mesh shape. When a file with the wrl extension is loaded, the default format should be the former one to be able to load the OpenHRP model file, but the bug makes the default format the latter one. In this case, the wrl file is loaded as a usual VRML file, so the loaded model does not have the joints. By correcting the code to determine the format, the former format is selected even if the file format is not explicitly specified, and the model can be loaded correctly.

gergondet commented 4 years ago

Dear Nakaoka-san,

Thank you very much, this fixed the problem indeed!