Annin Robotics Community

Hello everyone. I am using a stepper motor with an encoder (https://www.oyostepper.com/category-36-b0-Stepper-Motor-w-Encoder.html). To improve noise immunity, I connected the shield of the encoder signal cable to the ground at both the encoder end and the driver end. However, this has caused occasional extra pulse counts during low-speed operation, leading to slight, jittery fluctuations in the coordinates displayed on the CNC screen.

Using an oscilloscope to examine the A/B signals, I observed low-frequency interference—around 50 Hz—superimposed on the waveforms.

According to the technical documentation I've consulted, grounding both ends creates a "ground loop." The potential difference between the two ground points causes a circulating current to flow through the shield, which then couples into the signal lines.

The interference disappeared after I switched to a single-ended ground connection. I would like to ask: should the encoder cable shield be grounded at one end or both ends? And if it should be grounded at only one end, which side is preferable—the encoder side or the driver side?

Thank you.

Hi Chris, Hi everyone

I am currently designing a robot that has bevel gear for j6, the issue is that the bevel gear creates a differential relationship between the joint angles (j5 and j6). When j5 moves, j6 will move also.

Can you please help with a modified code Chris. How difficult it is to modify the Arduino IDE code?

Thanks.

Hi everyone,

We are evaluating the current AR4 for a broaching machine tending application and would appreciate advice from Chris and anyone with experience using the robot with heavier payloads.

Our workpiece specifications are:

• Outer diameter: 82 mm

• Inner diameter: 72 mm

• Length: 285 mm

• Weight: 2.7 kg

• Approximate working area: 500 mm

We will also need a gripper, so the total payload at the robot flange will of course be higher than 2.7 kg. We intend to keep the gripper as light as reasonably possible.

Speed is not important for this application. The robot can move slowly and we can use low acceleration. Repeatability, reliability and long-term operation are much more important to us than cycle time.

Before we start modifying the design, we would like to understand what you would recommend for the current AR4 design.

In particular:

• Is this application realistic for the current AR4?

• What total payload would you consider reasonable for this type of slow operation?

• Which joints or components would become the limiting factors with a 2.7 kg workpiece plus gripper?

• Would you recommend any changes to the motors, gearboxes, belts, bearings, shafts or wrist assembly?

• Has anyone tested a similar payload repeatedly over a large number of cycles?

• Is there anything about the robot position or working envelope that we should consider when designing the cell?

We are seriously considering building the robot for this application, and we are also planning to purchase the STEP/SolidWorks CAD files so that we can review and, if necessary, modify the mechanical parts for our use case.

We are able to manufacture or modify mechanical parts if necessary, so we are also interested in any modifications that would make this application more reliable.

Thank you for any guidance or real-world experience.

I'm an ME student working on developing a 6 axis arm as my senior design project, and the AR4 has been an amazing source of inspiration. My team wants to use similar steppers and drivers as well as the teensy 4.1, however we noticed what seems to be an issue when looking at specs.

The encoder that comes with the steppers used in the AR4 says it outputs 5V high on the stepperonline product page, which to my understanding could damage the teensy since it's designed for 3.3V input. Also, the stepper driver user manual says it accepts 4-5V high input, whereas the teensy again uses 3.3V. The AR4 instructions and wiring schematic seem to show that these inputs and outputs are directly connected.

To the best of my knowledge this system shouldn't work, but clearly the AR4 does work using these parts. I was wondering if I'm missing something in the AR4 wiring/the hardware specs/my general electrical understanding, or if the parts can just handle a greater voltage range than what they're rated for, or if there's something else entirely going on?

Many thanks

Jacob

Hi Chris,

I've been developing the Teensy 4.1 firmware further and am currently working on a dynamics observer, with the longer-term goal of dynamic/gravity compensation.

I've already implemented numerical Jacobian/singularity monitoring and am now looking to populate a rigid-body dynamics model of the AR4 Mk1. Do you have any of the following mechanical/dynamic parameters available from the AR4 CAD or original design calculations?

For each moving link / joint assembly J1–J6:

• Mass of each link/assembly (kg)

• Centre of mass location for each link (XYZ), and which coordinate frame the COM is referenced to

• Moment/inertia tensor about the link COM: Ixx, Iyy, Izz and, if available, Ixy, Ixz, Iyz

• Confirmation of the link coordinate frames used for those values

For the drivetrain:

• Gear reduction for J1–J6

• Any belt/pulley reductions in addition to the gearbox reduction

• Motor rotor inertia for each motor, if known

• Gearbox/output inertia or reflected inertia, if available

• Approximate gearbox efficiency for each joint, if known

• Any known static/Coulomb friction or viscous-friction values

For the kinematic model:

• The definitive AR4 DH parameters / link geometry used by the controller

• Confirmation of joint-axis directions/sign conventions

• Any mechanical zero offsets that aren't represented directly in the DH table

For the wrist/tool:

• Mass and COM of the standard J6/flange assembly

• Rated/default payload

• Payload COM assumptions used when the AR4 was designed

• Any maximum joint torque figures or calculated torque requirements for J1–J6

I'm particularly interested in whether you already have a mass-properties export from the CAD. If you have the original CAD assemblies with materials assigned, even a table/export of mass, COM and inertia tensor for each moving assembly would be ideal.

I'm initially running the dynamics as an observer only, calculating gravity, inertial and Coriolis/centrifugal loading without changing motion, so I can validate the model against encoder following error before implementing any active compensation.

Cheers,

Stefan