I was hoping someone had some clues about getting AR3 working with one of the ROS2/MoveIt2 integrations out there. The most promising integrations seem to be Kevin DeMarco's, https://github.com/RIF-Robotics/ar3_ros , and Yifei Cheng's, https://github.com/ycheng517/ar4_ros_driver , I think Yifei's repository has been more active so I am using that one, but I tried both.
In any case, I was able to put together a computer running Ubuntu and ROS2/MoveIt2 Jazzy, and cloned Yifei's repository and got it compiled, and uploaded the AR4_teensy sketch (annin_ar4_firmware/AR4_teensy/AR4_teensy.ino) to my Teensy 3.5.
For interacting with the arm, using ar_model:=mk1 is essential in the launch command,
ros2 launch annin_ar4_driver driver.launch.py calibrate:=True ar_model:=mk1
I've tried the AR4_teensy sketch as-is, and also with some modifications based on Chris's "AR4_teensy41_CUI_sketch_v3.0.ino" file. In both cases the arm will go through the limit switch calibration properly (make sure it starts out vertical or in an otherwise good position, or it smashes into itself..). So it moves all axes to hit the switches, pauses, then opens up a bit off of the limit switches, and pauses again. Here's where I am stuck. After calibration the arm wants to return to a resting state, but to do so it suddenly turns around wildly, reaching below the platform towards somewhere it can't go, and I have to hit the E-stop. It is frustratingly close to working, and I can't figure out where this rest position is defined to fix it - is it in the Teensy sketch, or the ROS arm definitions?
In the AR4_teensy.ino code, the main changes I tried were just hard-coding it to use model 'mk1' (not really necessary if ar_model:=mk1 is always used), and then changing the encoder multiplier based on what I see in Chris's AR4 CUI file,
// const float ENC_MULT[] = {10, 10, 10, 10, 5, 10};
const float ENC_MULT[] = {5.12, 5.12, 5.12, 5.12, 2.56, 5.12};
...but that doesn't have seem to have much effect.
I also changed around the REST_MOTOR_STEPS values,
const int REST_MOTOR_STEPS_MK1[] = {7555, 2333, 4944, 7049, 2295, 3431};
For that, I tried various values for all the joints, but J2 and J3 specifically. These don't seem to have change the behavior and the robot still flails into the ready/resting position.
I've looked all over in the code base (thanks Yifei and others for putting it together!), but I'm quite stuck in solving this.