V0 description

[maxpolzin]

This is our first pull request. I'll take it as an example how to make a pull request. Have you made pull requests before? Basically, in a pull request, I am requesting to merge some changes from a branch into another branch, here it is from v0_description to main.

The creator of the PR makes a description like this: """ This PR deletes all the mesh files of the fingers and just kept the dynamixel ones. (in case you actually did that)

Comments out the joint_state_publisher_node. This node is used to mux the states of the dynamixels with the joint_states published by the nonlinear model on the topic "helix_joint_state_publisher/joint_states". So in order to visulizae a potential arm, this will be needed again later and we uncomment it when needed. """

Then, the reviewer reviews the changes and approves them. Afterwards, the creator can merge the PR into the target branch.

This is the way to establish a four-eye principle and more people know about the changes made to the code.

[maxpolzin]

Now we chat in the conversations until we resolve them. Once resolved, the approver approves the PR, then the creator can merge the PR into the designated branch.

[sebtiburzio]

Hey, yeah sorry this is definitely not ready to be merged haha, i only committed/pushed it because i was still not 100% sure my local changes wouldn't evaporate when i shutdown the container or something, things are still a bit of a mess atm. I will be back looking at it tomorrow and will make sure it works at least for the dummy hardware before doing a PR. So maybe we just close this one, or i guess more changes can be integrated into it?

[maxpolzin]

Thx for your responses.

Please don't take the review too serious for now. I merely wanted to test a PR-based workflow. Feel free to push as many changes as you wish to this branch/PR and when you are happy with it, just go ahead approve the PR and merge them to production.

I think PRs are simply a good way to communicate to others that changes were made to the code. Good night. :)

[sebtiburzio]

This is now in a state that is ready to do some preliminary testing on the 'deployment' side.

The urdf files are set up to provide:

• position control through ros2_control to the 9 motor arrangement of the v0 Helix (ids 0-8)
• rough visualisation of the motor shaft axes positions in the 'motor head' part of the robot
• placeholders for the flexible arm part of the robot description. at the moment this contains an example of a rigid serial chain attached to the same origin frame.

This has been tested:

• Running from a host ubuntu PC connected to the motors, reading joint states and sending position commands over host PC native ROS, roslibpy and the foxglove browser interface
• Running from a RPi 4B, reading joint states and sending position commands through roslibpy and the foxglove browser interface

Known issues:

• Launching and connecting to the motors does not appear to be very stable. Generally requires several run/shutdown cycles of the container to establish the connection.
• Interacting with the Pi system using a connected Ubuntu PC with native ROS appears a bit unstable, to be investigated further
• URDF meshes don't appear to be loaded successfully in foxglove