Unnecessary warning message is printed when starting Simulink controller

[gabrielenava]

I noticed that when running the Simulink torque balancing controller, a warning message related to FT sensors (that seems to come from here) is printed in the command line:

[WARNING]  :: createReducedModelAndSensors : The joint r_leg_ft_sensor is not in the reduced model, the associated joint sensor won't be present

it seems this warning is unnecessary, at least for Simulink. Is it possible to remove it?

[traversaro]

Related to #325 .

[traversaro]

Rationale: it is perfectly fine to create a reduced model without the joint that contains a F/T sensor (it is actually what we always do in the controllers, that don't care about the F/T sensor fixed joint at all!). @diegoferigo can you look into this? Thanks!

[gabrielenava]

ping

[gabrielenava]

@traversaro in a project, we are performing a KPI analysis of a Simulink controller. The controller runs several times in a raw and therefore the warning messages are printed a lot of times in the command window.

These warnings are also making less visible some useful messages we print on MATLAB command window to understand how the KPI analysis is proceeding.

I would like to get rid of these warnings, but I have no idea how to proceed. Is this an easy problem to fix? How can I get rid of it?

cc @nunoguedelha @CarlottaSartore @S-Dafarra @fjandrad

[traversaro]

As mentioned in #408 (comment), it is perfectly fine to create a reduced model without including a joint that contains a joint sensor. so I guess we just need to find where the warning is emitted (i.e. https://github.com/robotology/idyntree/search?q=the+associated+joint+sensor+won%27t+be+present&unscoped_q=the+associated+joint+sensor+won%27t+be+present ) and then remove it.

[gabrielenava]

In the case of my project, these are the messages printed on the Matlab command window:

[WARNING] :: addSensorFramesAsAdditionalFramesToModel : addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor sensor_force_l as there is already a frame with that name

[WARNING] :: createReducedModelAndSensors : The joint sensor_force_l_heel_left is not in the reduced model, the associated joint sensor won't be present

[WARNING] JointElement :: : Joint TR_Y misses the limit tag.

So besides the createReducedModelAndSensors there are other two warnings printed. The problem is that the other two warnings seem more important. However I don't know if I have margin to modify the urdf model.

[gabrielenava]

Here are the associated lines of code:

idyntree/src/model_io/urdf/src/JointElement.cpp

Line 172 in 114671f

std::string errStr = "Joint " + m_jointName + " misses the limit tag.";

idyntree/src/sensors/src/ModelSensorsTransformers.cpp

Line 161 in 114671f

ss << "The joint " << parentJointName << " is not in the reduced model, the associated joint sensor won't be present" << std::endl;

idyntree/src/model_io/urdf/src/URDFDocument.cpp

Lines 265 to 307 in d5bbcea

	std::string err = "addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor " + linkSensor->getName() + " as there is already a frame with that name";
	reportWarning("", "addSensorFramesAsAdditionalFramesToModel", err.c_str());
	}
	else
	{
	// std::cerr << "Adding sensor " << linkSensor->getName() << " to link " << linkToWhichTheSensorIsAttachedName << " as additional frame"<< std::endl;
	bool ok = model.addAdditionalFrameToLink(linkToWhichTheSensorIsAttachedName,linkSensor->getName(),linkSensor->getLinkSensorTransform());
	if (!ok)
	{
	std::string err = "addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor " + linkSensor->getName() + " for unknown reasons";
	reportError("", "addSensorFramesAsAdditionalFramesToModel", err.c_str());
	ret = false;
	}
	}
	}
	}
	// Explictly address the case of F/T sensors
	if (type == SIX_AXIS_FORCE_TORQUE)
	{
	// We add the sensor frame as an additional frame of the **child** link
	// (as tipically for URDF sensors the child link frame is coincident with the F/T sensor frame
	for (size_t sensIdx = 0; sensIdx < sensors.getNrOfSensors(type); ++sensIdx)
	{
	SixAxisForceTorqueSensor * ftSensor = dynamic_cast<SixAxisForceTorqueSensor*>(sensors.getSensor(type,sensIdx));
	std::string linkToWhichTheSensorIsAttachedName = ftSensor->getSecondLinkName();
	if (model.isFrameNameUsed(ftSensor->getName()))
	{
	std::string err = "addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor " + ftSensor->getName() + " as there is already a frame with that name";
	reportWarning("", "addSensorFramesAsAdditionalFramesToModel", err.c_str());
	}
	else
	{
	Transform link_H_sensor;
	bool ok = ftSensor->getLinkSensorTransform(ftSensor->getSecondLinkIndex(),link_H_sensor);
	ok = ok && model.addAdditionalFrameToLink(linkToWhichTheSensorIsAttachedName,ftSensor->getName(),link_H_sensor);
	if (!ok)
	{
	std::string err = "addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor " + ftSensor->getName() + " for unknown reasons";

[traversaro]

[WARNING] :: addSensorFramesAsAdditionalFramesToModel : addSensorFramesAsAdditionalFrames is specified as an option, but it is impossible to add the frame of sensor sensor_force_l as there is already a frame with that name

Also this is a warning that is due to the iCub model, that defines both a frame (in the URDF sense, so a fixed link with no mass) and a sensor with the same name. As long as the two corresponds the warning can ignored, so as in the other case discussed in this issue any volunteer is welcome to open a PR to remove it.

[WARNING] JointElement :: : Joint TR_Y misses the limit tag.

This warning is more critical: according to the URDF spec both prismatic and revolute joint must have a limit element (see http://wiki.ros.org/urdf/XML/joint#Attributes), so what you are loading is probably not scrictly a URDF file http://wiki.ros.org/urdf/XML/joint#Attributes . However, in reality as long as you don't access the limits everything will work fine, so also this warning can be ignored.

More in general probably it would make sense to have an option to silence this warning, so anyone is welcome to also open a PR for such an option, but to have it available in WB-Toolbox then it needs to be exposed also at that level.

[gabrielenava]

I commented out the lines of code pointed here locally on my pc. I was able to compile iDynTree with no issues and the warning messages disappeared from Matlab.

I can open a PR for permanently removing 2 out of 3 warnings, while for the remaining one I was thinking that a simple option may be to remove it only for the users of a specific iDynTree tag related to the project I was referring to in the previous comments. However I don't know which is the current tag used by this project @nunoguedelha.

cc @S-Dafarra @CarlottaSartore @fjandrad

[nunoguedelha]

Sorry @gabrielenava for the late reply. So we excluded the following two approaches?

• Having a build option in iDynTree to deactivate all the warnings?
• blocking any warning generated by any external library to be displayed in the Matlab command line.

[traversaro]

Having a build option in iDynTree to deactivate all the warnings?

I would personally prefer a runtime option of the ModelLoader class, as build options are tricky to manage.

[nunoguedelha]

You're right, tricky and slow, since you have to rebuild.

[nunoguedelha]

I can open a PR for permanently removing 2 out of 3 warnings, while for the remaining one I was thinking that a simple option may be to remove it only for the users of a specific iDynTree tag related to the project I was referring to in the previous comments. However I don't know which is the current tag used by this project @nunoguedelha.

@gabrielenava , the specific project has a ProjectTags.cmake file selecting the used iDynTree commit or tag. That selection is
likely to move from time to time, so we can't rely on that to conditionally remove the warnings. So, joining @traversaro point of view, I think the best would be to go for a runtime option. I couldn't find any simple solution on Matlab/Simulink so far, for deactivating all messages coming from Mex functions, which would be an acceptable quick fix. Probably the change will have to start on iDynTree code itself.

[nunoguedelha]

I just tried a way to capture all the warnings on Matlab, wrapping the normal sim(<model>) command inside a evalc, then writing them to a text file. The syntax is typically:

[commandLineOutput,simulationOutput] = evalc("sim(modelName,'FastRestart','off')");

and we get in commandLineOutput all the output usually displayed in the Matlab command line due to the execution of sim(modelName,'FastRestart','off'), in this case the warnings. I'm pushing a fix on the other project. It might still make sense to remove the warnings createReducedModelAndSensors and addSensorFramesAsAdditionalFramesToModel from iDynTree, if they become useless in general (not just for Simulink).

[gabrielenava]

I've opened a PR to remove two of the three warnings pointed out in this comment.

[gabrielenava]

I think that #718 closes this issue.