Issue overview

Since the following commit, Camera device cannot get image properly in SImpleController.
9d70912
(This issue was confirmed in the latest commit 2fe1349 as well.)

How to reproduce the issue

I added the following code to and tested the issue using sample/tutorial/Tank/step6.cnoid.

sample/tutorial/CMakeLists.txt

24 + add_subdirectory(tutorial/Tank)

sample/tutorial/Tank/CameraController.cpp

24    virtual bool control() override
25    {
26        printf("Camera name [%s] empty: %d, width: %d, height: %d\n",
27            camera->name().c_str(), camera->constImage().empty(), camera->constImage().width(), camera->constImage().height());
...

The console output after the simulation starts is as follows.

Camera name [Kinect] empty: 1, width: 0, height: 0
Camera name [Kinect] empty: 1, width: 0, height: 0
Camera name [Kinect] empty: 1, width: 0, height: 0
Camera name [Kinect] empty: 1, width: 0, height: 0
...

Issue analysis

After investigating from the commit diffs, I guessed that the problem is related to the "copyStateFrom" function in src/Body/Camera.cpp, which used to copy the image.
9d70912#diff-8966906dbbf119146333a766406604c2583e8b6d22b8071b6e1b2da14c8a3be3L69

This image copying process is done after copyCameraStateFrom, but within copyCameraStateFrom, the decision to copy an image is made based on the boolean value of isImageStateClonable.
9d70912#diff-8966906dbbf119146333a766406604c2583e8b6d22b8071b6e1b2da14c8a3be3L86-L90

Debugging shows that the value of isImageStateClonable is always False in the default configuration of Tank/step6 .cnoid.
Therefore, the image is not copied in copyCameraStateFrom above, but in the previous commit code, the image was then copied in copyStateFrom and SimpleController was able to properly get the image.

Further debugging shows that by changing the value of "Record vision data" in GLVisionSimulatorItem from False to True in the configuration of Tank/step6.cnoid, SimpleController can get image from the camera device even in the latest commit.

The following is the console output when the image is successfully acquired.

Camera name [Kinect] empty: 0, width: 320, height: 240
Camera name [Kinect] empty: 0, width: 320, height: 240
Camera name [Kinect] empty: 0, width: 320, height: 240
Camera name [Kinect] empty: 0, width: 320, height: 240
...

Question

I'm not sure what the proper behavior to assume is, should we be able to get images from SimpleController only if "Record vision data" is True, as it was after commit 9d70912 ?
Or should we be able to get the image regardless of the value of "Record vision data" as was the case prior to the above commit?

I have to place more than 20 Kinect cameras to simulate my project.
But when it exceeds more than 10 cameras Choreonoid crashes.
The error message in the terminal is "Segmentation fault (core dumped)". I couldn't get the proper cause of the error.
My system:
Core i7-4th gen, Memory 24 GB, Graphics: GeForce GTX 760

Hi,

When loading a .cnoid project, the current behaviour seems to be to keep on loading no-matter-what, even if essential components failed to load. This creates many issues down the line, sometimes hard to debug such as other components failing to load too as a result, or worse the simulation not behaving as expected.

A better behavior would be to stop loading as soon as an "essential" component failed to load, and prevent the simulation from starting. Here is an example with the choreonoid-openrtm plugin, attempting to load PDcontroller.

Restoring BodyRTCItem "BodyRTC"
Config File "/home/arnaud/openrtp/bin/../lib/choreonoid-1.8/rtc/Virtual-JVRC1-RTC.conf" has been loaded.
RTC "PDcontroller" cannot be created by the RTC manager.
 RTC module file: "/home/arnaud/openrtp/bin/../lib/choreonoid-1.8/rtc/PDcontroller.so"
 Init function: PDcontrollerInit
 option: ?exec_cxt.periodic.rate=1000000&exec_cxt.periodic.type=ChoreonoidExecutionContext

Error: RTC "PDcontroller" cannot be created.

RTC "JVRC1Controller(Robot)0" has been created.
Restoring SensorVisualizer "SensorVisualizer"
Restoring BodyItem "longfloor"
Loading Body "/home/arnaud/openrtp/share/OpenHRP-3.1/sample/model/longfloor.wrl"
 -> ok!
Restoring AISTSimulatorItem "AISTSimulator"
Restoring PythonSimScriptItem "sim_mc.py"
Loading Python Script for Simulation "/home/arnaud/openrtp/share/hrpsys/samples/JVRC1/sim_mc.py"
 -> ok!
8 / 8 item(s) have been loaded.
Project "sim_mc.cnoid" has been completely loaded.

Here the error Error: RTC "PDcontroller" cannot be created. should be fatal: the plugin obviously knows that it could not be loaded, and in that case if PDcontroller does not exist, the simulation will not work (the robot will collapse on the ground). However, instead of stopping loading here, displaying the error message, and further preventing from running the simulation, it keeps on loading as if nothing happened, and allows the simulation to run and fail (in this case in a very obvious way, but we can easily imagine scenarios were it would fail more discretely, or where the actual failure message gets buried in the message log).

Is there a way that I don't know of to achieve such a behavior? If not, would you be willing to implement something like that?

The current version on master is 1.8.0. However it has significantly diverged from the one we typically use here: https://github.com/isri-aist/choreonoid, that also happens to be version 1.8.0.

I'd like to have both on my machine, so that I can gradually upgrade our environment to stay up to date with master, and having the same version number makes it quite tricky. I actually got most of it working, at least for mc_rtc requirements. I still have a few lingering python issues for using this version to run on the real robots (related to CORBA). But stuff like https://github.com/isri-aist/hrpcnoid is much further from running ;)

Would you mind bumping the version number (say 1.9.0 or whatever you deem appropriate), and have the packages that depend on it explicitly require a version greater than that? I'm thinking choreonoid_ros for instance since it's not compatible with the isri-aist fork:

<depend version_gte="1.9">choreonoid</depend>

Hi,

In the mass matrix computation, rotor inertia seems added twice.
Firstly, as a part of computing mass matrix, the inverse dynamics computation to obtain A_G * delta_i + b_G considers rotor inertia, as seen at https://github.com/choreonoid/choreonoid/blob/master/src/Body/InverseDynamics.cpp#L66.
Secondly, rotor inertia is also added at https://github.com/choreonoid/choreonoid/blob/master/src/Body/MassMatrix.cpp#L93.

typo comment?: motor inertia -> rotor inertia at https://github.com/choreonoid/choreonoid/blob/master/src/Body/MassMatrix.cpp#L93.

Currently URDF format is widely used around the world (including ROS community), and Choreonoid should support it as soon as possible.

On the other hand, as I discussed this issue with @s-nakaoka previousely, Choreonoid does not depend on ROS libraries. It is because Choreonoid is not a ROS-dependent application, and URDF is also used in non-ROS tools.

as of commit 243f3d6

The three kinematics mode buttons in the Kinematics Bar (FK, preset and IK buttons) are not toggled exclusively.

The "Kinematics Bar" section in the operation manual says:

These buttons are designed in such a way that only one of them is turned on, and used to switch the “kinematics mode”

However, all the three buttons are ON by default and they can be toggled independently.
It had worked correctly at v1.7.0.

Hi,

Building choreonoid with pybind11 support fails with clang-9 and c++17 (I use clang by default, and choreonoid automatically selected c++17 since I didn't specify CMAKE_CXX_STANDARD explicitely), there is an error:

In file included from /home/arnaud/src/catkin_ws_choreonoid/src/choreonoid/src/Base/pybind11/PyQtGui.cpp:5:
In file included from /home/arnaud/src/catkin_ws_choreonoid/src/choreonoid/src/Base/pybind11/PyQString.h:9:     
/home/arnaud/src/catkin_ws_choreonoid/src/choreonoid/thirdparty/pybind11-2.4.3/include/pybind11/pybind11.h:1008:9: error: no matching function for call to 'operator delete'
        ::operator delete(p, s, std::align_val_t(a));                                                                                                                                                          
        ^~~~~~~~~~~~~~~~~                                                                   
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/new:149:6: note: candidate function not viable: no known conversion from 'pybind11::size_t' (aka 'unsigned long') to 'std::align_val_t' for 2nd argument
void operator delete(void*, std::align_val_t, const std::nothrow_t&)                                                                                                                               
     ^                                                                                          
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/new:147:6: note: candidate function not viable: requires 2 arguments, but 3 were provided                                                               
void operator delete(void*, std::align_val_t)                                                                                                                                                               
     ^                                                                                                                                                                                                            
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/new:138:6: note: candidate function not viable: requires 2 arguments, but 3 were provided
void operator delete(void*, const std::nothrow_t&) _GLIBCXX_USE_NOEXCEPT                                             
     ^                                                                                                                        
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/new:174:13: note: candidate function not viable: requires 2 arguments, but 3 were provided
inline void operator delete  (void*, void*) _GLIBCXX_USE_NOEXCEPT { }                                             
            ^                                                                                                                                                                                               
/usr/bin/../lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/new:124:6: note: candidate function not viable: requires 1 argument, but 3 were provided                                                      
void operator delete(void*) _GLIBCXX_USE_NOEXCEPT           

As reported in pybind/pybind11#1604, this problem can be solved by enabling sized deallocation under Clang (-fsized-deallocation). A fix for it was pushed upstream on pybind11 side (pybind/pybind11@759221f). However you are building against version 2.4.3 of pybind11 from the thirdparty folder which does not have this patch.

What's the reason behind not using the system's version of pybind11? Can you look into fixing this particular issue?

On a more general note, do you have continuous integration set-up for choreonoid? If not, that would greatly help in catching this kind of issues in the future ;)

windows10にて、最新のchoreonoid開発版にOpenRTMプラグイン導入を考えています。
開発版のドキュメント(https://choreonoid.org/ja/documents/latest/install/build-windows.html#id8)やopenRTMプラグイン(https://github.com/OpenRTM/choreonoid-openrtm)を参照してインストール作業を行いました。
choreonoidにcmakeを行う段階で「ENABLE_CORBA」を追加できず、openRTMプラグイン導入がうまくいきいません。
最新のchoreonoid開発版では、openRTMプラグインの導入はできなくなってしまったのでしょうか。
またプラグイン側にはfor OpenRTM-aist 1.1.2とありますが、最新バージョンのOpenRTM-aist 1.2.2に対応していますか。

Recently, our lab started using the master branch of https://github.com/choreonoid/choreonoid from https://github.com/isri-aist/choreonoid (fixed at the version of November 2019). The change caused the realtime ratio (compute time / simulation time) to slow down by about 1.3x. We are using AISTSimulator and the project file for the sample is https://github.com/jrl-umi3218/mc_openrtm/blob/master/projects/JVRC1/cnoid/sim_mc.in.cnoid

We would appreciate any ideas on how to achieve the same simulation speed as before.

The RPY angles in PoseSeqPlugin are interpolated using a standard interpolation method

without considering the issue of singularity. This can cause errors in the interpolated output angles. I recommend using quaternion slerp interpolation, with a reference implementation as follows:

double r = (x - s0.x) / (s1.x - s0.x);
if constexpr (std::is_same_v<SampleType, LinkSample>) {
    Eigen::Quaterniond q0 = 
        Eigen::AngleAxisd(s0.c[5].y, Eigen::Vector3d::UnitZ()) *
        Eigen::AngleAxisd(s0.c[4].y, Eigen::Vector3d::UnitY()) *
        Eigen::AngleAxisd(s0.c[3].y, Eigen::Vector3d::UnitX());
    Eigen::Quaterniond q1 =
        Eigen::AngleAxisd(s1.c[5].y, Eigen::Vector3d::UnitZ()) *
        Eigen::AngleAxisd(s1.c[4].y, Eigen::Vector3d::UnitY()) *
        Eigen::AngleAxisd(s1.c[3].y, Eigen::Vector3d::UnitX());
    Eigen::Quaterniond q_interp = q0.slerp(r, q1);
    Eigen::VectorXd RPY = Eigen::EulerAngles<double, Eigen::EulerSystemZYX>(q_interp.normalized().toRotationMatrix()).angles().reverse();
    out_result[3] = RPY[0];
    out_result[4] = RPY[1];
    out_result[5] = RPY[2];
}

Thank you for your contribution.

hello everyone, i am one of people who has nothing idea how to comply the software by themselves.

i searched the post there is .exe for windows user, but the lastest one is 1.5 ver. only.

since the 1.7 has been released for 3yrs already, will it be possible to provide 1.7.exe so more newbie can try this software with ease ?

thx everyone in advance.

Hi,
In bb6c045 you removed the Hrpsys31Plugin and RemoteAccessPlugin from the main source tree. I however couldn't find where they have been moved to, could you point it out?

It would be great if the NEWS file could indicate these new repositories when you split them.