Thanks for this. Are the tf frames generated by the new URDF different to those in the existing version?

Good point, I made sure to change the joint names such that they stay the same, but not the links.
So the frames in this will be of different convention, e.g. arm_link_sh0 for the first part of the shoulder, instead of link1

I think it is probably good to match names with the ros2 repo but it might mean that people using this one will have to change stuff in their code, which is why I ask.

I understand. I leave this up to you guys entirely, I mostly made this because I wanted to see if other people had issues with this urdf for the arm, such as the one in the images I've attached.

It definitely makes sense to make the switch, since clearly there is an issue with the previous version, but I will need to make an announcement to make sure people know what frames have changed. I think synchronising the frame names with the ros2 version makes sense since people will need to switch over to that eventually and making sure the urdf is the same would likely make things easier.

I've updated the joint names to correspond to the spot_ros2 names (which come from the BD names), and updated the "friendly joint names" to convert to these values.

@EceChaik could you please check that the live joint update works correctly with these changes?

Will check, though it might be next week, due to travelling for IROS

I just had to do the above commit, cause the wr0 name was written as wr1.
I can confirm it works fine on the spot robot.

P.S. The only reason I had changed the mass value of the virtual fixed joint 'hr0' to 1e-3 from 1e-6, was for people who might wanna use it for simulation in Gazebo. There, a link of mass as low as 1e-6 will be skipped.

Great, thank you for confirming. I don't use gazebo so wasn't aware of that requirement. Did you need to use the virtual joint for anything that you were doing? If so I should probably change the mass back.

This repo is not made for simulation so I don't think it matters. On the other hand, the mass value won't affect anything people do with the real robot using this repo, so I guess reverting to 1e-3 is the solution that covers all users.

Could this be merged into master at this point @heuristicus? The improved arm simulation would be very beneficial to my groups research

I can merge this but any existing code that relied on specific frames being related to the arm will not function, as per the table above.

Have you tested this for your purposes?

After some more testing, I've noticed that when using arm ROS service calls with this version of the code, the calls involving the gripper have success False and some error exception printed.

$ rosservice call /spot/gripper_close
success: False
message: "Exception occured while gripper was moving: gripper_command_feedback"

Interestingly, at least some of the commands actually do get executed by the arm and work. The gripper does open and close when these are called.

Additionally arm stow, unstow, and carry seem to be working

$ rosservice call /spot/arm_unstow
success: True
message: "Unstow arm success"

Is this due to the change in the arm frames?

I can't say whether the arm frame change is the cause. I don't think there is anything that specifically references the arm frames in the gripper command. It's possible that this is related to the spot wrapper in this repo being behind. I've never had access to a robot with an arm so haven't been able to verify the functionality myself.