Wheel Encoder On Opencm 9.04

Yes - the key issue is that Wheel Encoder Counter is not a generic "read any text" serial parser. It expects the specific command/response behavior used by its supported firmware, which is why your L:...,R:... output and "listen for G then print" approach are timing out or framing badly.

Short answer

• It does not read streaming text like a serial monitor log.
• It expects a request/response protocol matching the skill’s firmware.
• It generally needs its own firmware-side communication path dedicated to encoder data.
• It should not share the same COM/UART path ARC is using to drive the OpenCM as an EZB if that same port is already occupied for robot control.

What the skill is expecting

The Wheel Encoder Counter skill was built around the firmware documented here:

• Wheel Encoder Counter skill:
  https://synthiam.com/Support/Skills/Navigation/Wheel-Encoder-Counter?id=17591

• Wheel Encoder firmware source/reference:
  https://synthiam.com/Firmware/Wheel-Encoder-Firmware-NVXCXGPCQMJ

From that implementation, the skill expects to send a command and receive a structured reply, not parse arbitrary text output. The exact byte-level framing is tied to the firmware used by the skill, so a simple serial line like this is not sufficient:

L:123,R:456

Why your current approach fails

Your current output is human-readable and asynchronous:

SerialUSB.print("L:");
SerialUSB.print(leftCount);
SerialUSB.print(",R:");
SerialUSB.println(rightCount);

But the skill is likely doing something like:

1. send a poll/request
2. wait for a response within a timeout
3. parse a specific frame layout
4. optionally reset or reuse the values

If the response doesn’t match the expected structure exactly, ARC reports:

• timeout reading encoder values
• invalid data frame

Can it share the same COM port as OpenCM servo control?

Usually, no.
If ARC is using the OpenCM 9.04-C over USB as the EZB interface for DYNAMIXEL control, that USB serial connection is already in use for the board’s primary role.

So if you try to also use that same link for wheel encoder polling, you’re mixing:

• EZB firmware traffic for DYNAMIXEL control
• encoder poll/response traffic for the wheel counter skill

That is typically not supported on the same serial channel unless the firmware was specifically designed to multiplex both features.

Best options

Option 1: Use a separate small MCU just for encoders

This is the simplest and most reliable path.

• Arduino Nano / Uno / Pro Mini
• OpenCM handles DYNAMIXEL
• second MCU handles encoder counting
• Wheel Encoder Counter talks to the second MCU

This is exactly the use case the skill was designed for.

Option 2: Extend the OpenCM firmware and create a custom ARC robot skill

If you want to keep everything on the OpenCM, the better ARC-native approach is:

• keep your OpenCM firmware custom
• expose encoder counts in a protocol you define
• create a custom robot skill in ARC that reads those values

That gives you full control and avoids forcing your OpenCM firmware into the UNO-specific Wheel Encoder Counter protocol.

Create a robot skill overview here:

• https://synthiam.com/Support/Create-Robot-Skill/Overview

Practical recommendation

If your goal is NMS pose updates, I’d recommend one of these:

1. Fastest path: add a tiny Arduino dedicated to encoders and use the existing Wheel Encoder Counter skill
2. Cleanest long-term path: make a custom OpenCM-compatible ARC skill for encoder + pose data

About the protocol

I don’t want to guess the exact frame format and baud assumptions here, because the Wheel Encoder Counter skill is tied to its firmware implementation, and using the wrong packet structure will keep causing the same timeout/framing behavior.

If you want, I can help you do either of these next:

• Option A: build the OpenCM encoder firmware into a custom ARC JavaScript/Python skill
• Option B: wire up a tiny Arduino encoder bridge and show you how to connect it to the existing Wheel Encoder Counter skill

If you paste your current OpenCM serial code and tell me whether you prefer custom skill or separate Arduino bridge, I’ll help you map out the exact next steps.

Also, if you’re scripting this behavior in ARC, the ARC AI Assistant can be handy for rewriting the code directly in the editor:
https://synthiam.com/Products/AI-Assistant