他社製品は互換性に問題がある可能性があります。 同じメーカー製品としての使用をお勧めします。
XBeeとCM-550はどのように接続されていますか? カーネンターはフックでしっかり固定されていますか?




May I ask about what kind of data do you plan to send via XBee to the CM-550?

Remocon Packets as defined by ROBOTIS here?

Also what/how the CM-550 is going to process whatever you are sending via Xbee to it? TASK or MicroPython code to process the Remocon Packets?

If this is the situation (Remocon Packet via UART Port), then you will need to set Remote Port, i.e. Control Table Address 43 to 1 (i.e. UART mode) also. Because by default it is set to BLE.

If you plan to send plain ASCII characters via Xbee, you probably should look into TASK PRINT PORT (Address 35) - then on the CM-550 you will have to use MicroPython. See this post created for using Matlab with CM-550, but it showed a solution using TASK PRINT PORT (i.e. CONSOLE() in MicroPython).

There are no problems with the software. I can generate Remocon Packets in C++ and send them via XBee, and the CM-550 receives and processes them in MicroPython.

What I want to discuss is a complete hardware problem.

Apologies if I have misunderstood your needs, as translation via web browser can be tricky at times.

Did you mean that the connection at the UART connector on the CM-550 tended to get loose for your project? In the past, I have used this “replacement” wireless cable from ROBOTIS:

The big JST end is designed for the UART port on CM-XXX controllers and I have found that they stayed IN very well when my robot is in motion. Your PH.pdf shows a very similar part to this ROBOTIS cable, so I am not sure why they would be “loose” for you when plugged in your CM-550’s UART port.

Then I just cut off the other end of this cable and spliced them into Dupont type of jumper wires. Have you done the same? Are the Dupont jumper wires turning out to be too loose for you? You may have to wire-wrap them or solder them directly into the header pins?