Fix move the linkFrames in case of the axis of the joint does not pass through the csys

[Nicogene]

This functionality was added in #106, but it was not coherent with the check made by idintree on the validity of the joint to be exported: https://github.com/robotology/idyntree/blob/9c2792790ca65ece633e8f8aed4d68716c65af09/src/model_io/codecs/src/URDFModelExport.cpp#L362-L371

[gemini-code-assist]

Summary of Changes

Hello @Nicogene, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a critical inconsistency in how joint axes are handled during URDF model export, particularly when the joint's coordinate system does not align with the parent link's frame. The changes ensure that the exported URDF models are compatible with idyntree's validation requirements, preventing potential issues with downstream processing of the generated URDF files.

Highlights

• Joint Axis Logic Correction: I've corrected the initialization and validation logic for iDynTree::Axis within Creo2Urdf.cpp. Previously, the axis was initialized with parentLink_H_childLink.getPosition() and then checked against axis_mid_point_pos_in_parent. This has been reversed: the axis is now initialized with axis_mid_point_pos_in_parent, and its alignment is checked against parentLink_H_childLink.getPosition().
• URDF Export Coherence: This change ensures that the Creo2Urdf export process is coherent with the joint validity checks performed by idyntree, specifically addressing the scenario where the joint axis does not pass through the coordinate system (CSYS) origin. This resolves an inconsistency introduced in a previous pull request (#106).

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request modifies the logic for handling joint axes alignment in URDF generation. The changes involve adjusting the axis origin based on certain conditions. The review suggests ensuring consistency in position usage and handling different parent link frame values to avoid potential issues with URDF generation.

[gemini-code-assist]

The iDynTree::Axis is initialized with axis_mid_point_pos_in_parent, but the condition on line 304 checks the distance using parentLink_H_childLink.getPosition(). This seems inconsistent and could lead to the axis being incorrectly adjusted or not adjusted when it should be. Consider using the same position for both the initialization and the distance check to ensure consistency.

Suggested change

	iDynTree::Axis idyn_axis{ direction, axis_mid_point_pos_in_parent };
	iDynTree::Axis idyn_axis{ direction, parentLink_H_childLink.getPosition() };

[gemini-code-assist]

The code modifies the idyn_axis origin if the parent link frame is "CSYS" and the axis is not aligned. However, it doesn't account for cases where parent_link_frame might have other values, potentially leading to unaligned axes in the URDF. Consider adding an else condition or additional checks to handle different parent_link_frame values appropriately, or ensure that the logic is correct regardless of the parent_link_frame value.

Suggested change

	if (parent_link_frame == "CSYS" && idyn_axis.getDistanceBetweenAxisAndPoint(parentLink_H_childLink.getPosition()) > 1e-7 ) {
	idyn_axis.setOrigin(parentLink_H_childLink.getPosition());
	if (parent_link_frame == "CSYS" && idyn_axis.getDistanceBetweenAxisAndPoint(parentLink_H_childLink.getPosition()) > 1e-7 ) {
	idyn_axis.setOrigin(parentLink_H_childLink.getPosition());
	m_need_to_move_link_frames_to_be_compatible_with_URDF = true;
	} else {
	// Handle other parent_link_frame values or do nothing
	}

[Nicogene]

Before merging it I would like to test it with the iCub asm, even if the complicated example it works fine:

• Add more and more complex asm examples #148

[Nicogene]

Unfortunately this change breaks the exportation of iCub urdf, then there is something wrong