Refactor subsystems to single use_sim launch argument

[dwarakeshbaraneetharan]

Replaces per-subsystem can_interface arguments with a single use_sim toggle across arm, drive, and science. When use_sim is true:
CAN interface switches to vcan0 (otherwise can0)
use_mock_hardware and mock_sensor_commands are auto-enabled
CAN setup/teardown runs directly from launch files (virtual or real)
Arm: MoveIt and JTC activate on startup; JTC remains available but inactive on real hardware
Also parameterizes use_sim_time in navigation, renames the old use_sim (RViz toggle) to use_rviz, fixes ODrive parameter key (can → can_interface), and corrects virtual_can_setup.sh to use vcan0

[mdurrani808]

Can we leave the nav stuff as-is for now? I'll / someone will take care of the changes, if we need them on the nav side

[IshanDutta11]

Here are a few things I'm thinking:

1. I am noticing that ros2_control's joint_state_broadcaster doesn't shutdown when there are no interfaces assigned to it to publish, it will just publish whatever state interfaces are available. I would like you to replicate this behavior in the motor_status_broadcaster. Make it so it will publish any motor_temperature or torque_current state interface it can find. If it can't find any, just print out that this is the case. Effectively, you should be able to remove lines 127-135 in arm_bringup/config/athena_arm_controllers.yaml and it will still work the same way joint_state_broadcaster does (no errors on launch).
2. For some reason we have the arm mock components xacro file in description/config. I want you to:

• Move this into ros2_control/arm
• Rename it to arm.mock.ros2_control.xacro
• Add motor_temperature and torque_current state interfaces
• Cleanup: We don't need the param stuff on the position state interfaces
• Modify athena_arm.urdf.xacro to include it at its new location
• Do all of this for science and drive as well

3. I am realizing that this use_sim param makes it impossible to test the real hardware without the real hardware. This was the intention, but it hard blocks any remote development for the real hardware which kinda sucks. The easiest bypass I found was replicating the virtual_can_setup.sh but replace vcan0 with can0. Make a file called dev_can_setup.sh and make it do just that. A bit of a jank solution, but I think its the easiest thing we can do for now.
4. For the issue regarding "deleting" can functionality upon killing the launch file, try to fix it, if nothing works, just remove it. I have tried to get this to work myself before but couldn't really find a great solution.

[IshanDutta11]

I am getting a launch error. I believe the reason is because you are trying to launch both manual_joint_by_joint and jtc are being activated on startup. When use_sim is true, jtc should activate, joint by joint should be off and vise versa, otherwise they will clash when trying to claim command interfaces

[IshanDutta11]

Does not seem to be working. vcan0 is still up.

[IshanDutta11]

Also, when i tried starting with use_sim:=false when vcan0 was still active, this happened:

[ERROR] [bash-1]: process has died [pid 15576, exit code 1, cmd 'bash -c sudo killall slcand 2>/dev/null; sleep 1; if [ -e /dev/ttyACM0 ]; then sudo slcand -o -c -s8 /dev/ttyACM0 can0; elif [ -e /dev/ttyACM1 ]; then sudo slcand -o -c -s8 /dev/ttyACM1 can0; else echo "No CANable device found"; exit 1; fi && sudo ip link set can0 up && sudo ip link set can0 txqueuelen 1000'].