ROS 2 Upgrade

[PeterMitrano]

• [x] upgrade launch files to ROS 2 syntax
• [x] Get joint states for gripper links to show up correctly
• [x] upgrade robotiq_grippers_joystick_node.py
• [x] get listener.py and joy_to_xbox .py and other arm_utilities code needed by victor_hardware scripts upgraded to rclpy
• [x] Confirm that the left_arm/wrench axes are aligned correctly
• [x] Test cartesian motion commands
• [x] Kuka control computer time mismatch
• [x] Try out MoveIt Servo
  • [x] Try out v2.9.0 which may improve the smoothness of servoing
    • Didn't work, move_group node segfaults with no information to debug
• [x] Upgrade and test manual_motion.py
• [ ] Measure and document the latency of the system
  • [ ] what frequency is the LCM published at?
  • [ ] How much delay is there between when the LCM message is created in Java to when the LCM message is received in C++? What about to when the ROS message is published? What about to when a subscriber gets the message?
  • [ ] Same as above but for sending commands. How much delay until the command is actually executed?
• [ ] fix build warnings in LCM
• [x] ~upgrade grasp_status_node.py~ deleted instead

[PeterMitrano]

@Yating05 @zxhuang97

[PeterMitrano]

ros2 control conversion:

• [x] Basic planning and execution from RViz working
• [x] Get finger state to publish by adding them to the ros2 control XML
  • [x] Have the hardware interface also fill out joint positions for fingers using the transmission to go from actuator state
  • [x] Make the hw iface also subscribe to the LCM messages for the gripper

[PeterMitrano]

From my testing of the cartesian pose commands, in cartesian impedance mode, the only parameter that affects the speed of the motion is cartesian_path_execution_params.max_velocity. Interestingly, the values of cartesian_path_execution_params.max_acceleration in victor_utils are orders of magnitude too high! This is partly why the motion is so jerky when the robot is given very small delta position commands. I wonder if this is true for joint commands too?

[PeterMitrano]

Bug fixes for victor_command_gui.py

• [x] sending commands after changing control mode seems to make sending commands stop work
• [x] doesn't open or run on Loki???
• [x] add a button to re-get the current control mode parameters

[PeterMitrano]

I tried implementing VR teleop for Victor using Cartesian control, but the downside was that the Cartesian controller wasn't very well behaved and would whip through singularities. Someone could go try to rewrite it use use incremental IK and JointImpedance instead. That's how the one Brad wrote worked.

Todo:

• [x] sync the code between armnova and loki

[PeterMitrano]

@Yating05 is taking the approach of using ros2 control, instead of the ROS MotionCommand message, but keeping the SetControlMode service.

Todo:

• [ ] Figure out which controllers need to be deactivated and add those to the request in side.cpp SetControlMode callback
• [ ] Finish implementing the KukaCartesianController
• [ ] Delete MotionCommand message from ROS (do NOT delete from LCM!!!!)
  • [ ] delete the build / install folder for victor_hardware_interfaces
• [ ] update all the victor_python code to use the new new_controller_name field and to not send MotionCommand messages because they don’t exist anymore!!!!

[PeterMitrano]

I'm going to try another approach where we create additional ROS controllers (same type, but with different ROS parameters) to handle the fact that some controller/control mode combinations are invalid.