Arm System - Uvic-Robotics-Club/uvic-rover-2027 GitHub Wiki

This subsystem covers the robotic arm's mechanical and electrical hardware, low level actuator control, communication interfaces, and high-level robotics software.

The arm uses integrated joint actuators containing the motor, gearbox, encoder, and driver in a single unit. A Raspberry Pi is responsible for low-level actuator communication and control, while the Jetson runs the higher-level ROS software responsible for processing commands and implementing robotics functionality.

Hardware

The robotic arm has 6 degrees of freedom (DOF), corresponding to six independently controllable joint variables.

The following CAD model shows the arm assembly and its actuators.

Note: All joints have it's own coordinate frame. And for each joint, the rotation is on its x-axis.

Based on the URDF and code for the arm system, I have settled on the following names for each joint:

Joint Name Index
turret_joint 0
shoulder_joint 1
elbow_joint 2
wrist_pitch_joint 3
wrist_roll_joint 4
hand_joint 5

Note: Joint indices are used by the software, whereas CAN node IDs identify individual actuators on the CAN network. These are separate identifiers.

Motor Specifications

The following table summarizes the actuators currently documented.

Node ID Joint Model Gear Ratio
1 Turret M5730 100:1
NA Shoulder NA NA
NA Elbow NA NA
4 Wrist Roll M4210 50:1
5 Wrist Pitch M4210 50:1
6 Hand/Gripper Roll M4210 50:1

For detailed motor specifications, operating principles and actuator-specific information, refer to Motors.

Communication & CAN

The arm uses two different kinds of actuators with different communication interfaces: The Avatar Robotics Actuators which uses CANopen and the CubeMars Actuators which use a manufacturer-specific CAN protocol.

Although the two kinds of actuators use different software interfaces, they can share the same physical CAN bus when their electrical requirements (bit rate, message identifiers, and other bus configurations) are compatible.

The CAN bus operates at 1Mbps.

For more detailed information, refer to the following pages:

Raspberry Pi Controller

The Raspberry Pi is responsible for low-level actuator communication and control. It interfaces with the CAN bus, sends commands to the actuators, monitors their communication and status, and coordinates joint movements.

The controller is also responsible for relevant safety and fault-handling mechanisms, such as communication timeouts or watchdog functionality.

For more detailed information, refer to the following pages:

Jetson & ROS

The Jetson runs the higher-level robotics software using ROS. It is responsible for processing incoming commands, validating them, and coordinating higher-level arm functionality before passing appropriate commands to the Raspberry Pi.

The intended architecture separates high-level robotics functionality from low-level actuator control. The Jetson handles functionality such as kinematics and ROS integration, while the Raspberry Pi handles communication with the physical actuators.

The exact responsibilities and implemented features are documented in the following pages:

Motion Planning and Kinematics

The arm system is being developed toward higher-level motion control, allowing operators to command the arm using more intuitive targets rather than manually specifying each joint's movement.

Inverse kinematics (IK) maps a desired end-effector pose to a suitable set of joint positions. Motion planning and trajectory generation must also account for joint limits, actuator constraints, and coordinated movement across multiple joints.

This functionality must integrate with the low-level Raspberry Pi controller while maintaining a clear separation between motion planning and actuator execution.

Setup, Testing & Troubleshooting

Operating the arm involves several interconnected components, including the physical CAN bus, actuator communication interfaces, Raspberry Pi controller, Jetson ROS software, and launch/configuration files.

This section documents the procedures required to configure, test, and debug these components. It should also record known issues and verified solutions to help future team members reproduce results and diagnose problems.

Avatar Motor Commissioning

Engineering Notes & Decisions

This section records engineering investigations and decisions made during development.