I purchased an ArmPi Ultra High-Performance Robotic Arm Controller (STM32 core board + carrier board). The board does not communicate over its serial interface, and I’ve done extensive testing to isolate the problem. I own a second, working ArmPi Ultra controller, which let me compare directly. I’d appreciate your guidance on next steps.
Symptom: the controller does not respond to any command sent to it. No response bytes are ever received.
The most important test - your own software, on your own OS: I wrote your official system image (Armpi_Ultra_20260713.img, from your shared drive) to an SD card and booted the Raspberry Pi 5 from it. Under your own OS, your own SDK (/home/pi/hiwonder-toolbox/ros_robot_controller_sdk.py), and your own /dev/rrc device symlink, the board still returns complete silence to a simple buzzer command. Your ros_robot_controller node auto-starts and opens the port, but the board never replies. This rules out my host, my OS, my software, and my configuration - the same environment you ship works on my other unit but not this one.
Additional findings:
1. Known-good comparison: identical host, cable, and software work immediately on my other ArmPi Ultra controller (buzzer beeps, servos respond). This board is silent under the exact same conditions.
2. The board enumerates normally as a CH340 USB-serial device (1a86:7523) → /dev/ttyUSB0. The USB link is fine.
3. Commands were sent with correct framing (0xAA 0x55 + CRC8) at 1,000,000 baud and swept across 9600-921600 baud. No response at any rate.
4. LED behavior (this is the key clue): on power-up, the carrier board LED flashes red/blue continuously. Pressing the core board’s RST button makes it go steady red (matching my working unit). However, the moment any host opens the serial port, the board reverts to the red/blue flashing state and stops responding. My working unit stays steady red when the port is opened.
My interpretation: the red/blue flashing appears to be the STM32 entering bootloader/DFU mode. It looks like this board drops into the bootloader whenever the serial port’s control lines are asserted at connection - i.e., the auto-reset/boot-strapping circuit (DTR/RTS to NRST/BOOT0) may be behaving differently on this unit than on my working one. That would explain why the application firmware never stays running while a host is connected.
Product and Purchase
- Product model:
- SKU or kit name:
- Purchase channel:
- Controller board:
Software and Environment
- Operating system:
- Connection method:
- Software version:
- Firmware version:
- Image version:
- Tutorial step:
Issue Description
- What did you expect to happen?
- What actually happened?
- Error message or logs:
Reproduction Steps
Evidence
- Photos or short video:
- Wiring photo:
- Screenshot:
What You Have Tried
Urgency
- Is this for a class, competition, or deadline?
