Reachy 2 mobile base issue: SetSpeed service not available

Users Support
,
1

Hi Pollen Robotics team,

I am having an issue with the Reachy 2 mobile base. The dashboard can open and I can SSH into the robot, but when the mobile base is enabled, the core logs repeatedly show:

service SetSpeed not available, waiting again...

The Python SDK also cannot properly connect to/control the robot when this happens.

Current setup

I am connected to Reachy through SSH:

ssh bedrock@reachy2-pvt01.local

The config file is located at:

/home/bedrock/.reachy_config/reachy.yaml

The mobile base section originally had:

mobile_base:
  version_hard: 1.2
  serial_number: MB-001
  version_soft: 1.1

When I temporarily set:

mobile_base: null

and restart reachy2-core, the robot core works better for head/arms. But when I enable the mobile base again, the SetSpeed not available issue returns.

What I checked

I ran:

ls /dev | grep vesc

but nothing appears.

I also checked:

ls -l /dev/vesc_wheels

and it returns:

No such file or directory

So it seems /dev/vesc_wheels is not being created/detected.

I also checked the serial devices:

ls -l /dev/serial/by-id

and I can see two FTDI USB serial converters:

usb-FTDI_USB__-__Serial_Converter_FT94EN9J -> ../../ttyUSB1
usb-FTDI_USB__-__Serial_Converter_FT94ENR0 -> ../../ttyUSB0

I tried temporarily linking each one to /dev/vesc_wheels:

sudo ln -s /dev/ttyUSB0 /dev/vesc_wheels
sudo systemctl restart reachy2-core

and also:

sudo ln -s /dev/ttyUSB1 /dev/vesc_wheels
sudo systemctl restart reachy2-core

but both still resulted in the same SetSpeed not available issue.

I removed the temporary link after testing:

sudo rm -f /dev/vesc_wheels

Other logs noticed

At one point, I also saw Dynamixel timeout messages such as:

dynamixel_controller error
get_motors_temperature timeout
get_current_torque timeout
get_current_velocity timeout
left dx1 / right dx1 timeout

However, the main repeated issue when enabling the base is still:

service SetSpeed not available, waiting again...

Physical checks done

I checked the following:

- Mobile base power is on
- Emergency stop is released
- USB devices are detected as ttyUSB0 and ttyUSB1
- Reachy dashboard is reachable
- SSH access works

Question

Could you please advise what the correct expected device mapping should be for the mobile base on Reachy 2?

Specifically:

1. Should /dev/vesc_wheels be automatically created by a udev rule?
2. How can I identify which FTDI device is the mobile base controller?
3. Is there a service or udev rule I should restart to recreate /dev/vesc_wheels?
4. Could this be a mobile base firmware/power/USB hub issue instead?
5. Are there any official commands to test the mobile base controller directly?

For now, I can keep mobile_base: null to use the upper body, but I would like to restore the mobile base properly.

Thank you.

image
image800×600 99.5 KB

2

Hi @bannc ,
Sorry to hear you’re experiencing issues with your Reachy2

Thanks a lot for the detailed message !

  • Could you tell me if previously the mobile base was correctly working ? And if something happened before you get those errors ?

  • Could you please try to get the lidar ? ls /dev/rplidar_s2

  • Could you try to search the vesc by their idVendor ? sudo find /sys -name "idVendor" -exec grep -l "0483" {} \;

  • Could you tell me what’s inside the udev rules of your robot : cat /etc/udev/rules.d/10-reachy-local.rules

  • And could you copy/paste the entire logs from journalctl -fu reachy2-core from the moment you restart the core service ?

Thanks a lot !
Claire

3

Hi Claire,

Thanks a lot for your reply.

I ran the checks you asked for.

  1. Previous status

From what I knew, the robot was working properly last August. However, I am not fully sure about the exact mobile base status because I only started testing this robot recently.

Currently, the upper body/head/arms can move through the dashboard. The issue appears when I enable the mobile base.

  1. Lidar check

Command:

ls /dev/rplidar_s2

Output:

ls: cannot access ‘/dev/rplidar_s2’: No such file or directory

So the lidar is not detected.

  1. VESC idVendor check

Command:

sudo find /sys -name “idVendor” -exec grep -l “0483” {} ;

Output:

No output was returned.

I also checked:

lsusb | grep 0483

Output:

No output was returned.

So I cannot see the expected VESC device with vendor ID 0483.

  1. Udev rules

Command:

cat /etc/udev/rules.d/10-reachy-local.rules

The rule for vesc_wheels is present. It expects:

idVendor==“0483”
idProduct==“5740”
product==“ChibiOS/RT Virtual COM Port”

and should create:

/dev/vesc_wheels

However, since the 0483:5740 device does not appear in lsusb, /dev/vesc_wheels is not created.

  1. Core logs

I also captured the logs from journalctl after restarting reachy2-core.

The main errors I noticed are:

  • poulpe_ethercat_grpc::client reports “Connection refused”
  • ros2_control_node reports errors connecting to EthercatPoulpeController / PoulpeRemoteClient
  • several hardware config files fail to load, including neck_beta.yaml and the shoulder/elbow/wrist poulpe config files
  • ros2_control_node dies with:

Wrong state or command interface configuration

  • The logs also show many missing state and command interfaces.

The Orbbec camera is detected correctly, and the upper body can still move through the dashboard, but the mobile base devices seem missing:

  • /dev/rplidar_s2 is missing
  • /dev/vesc_wheels is missing
  • lsusb | grep 0483 returns nothing
  • the udev rule exists, but the expected 0483:5740 VESC device is not detected

Could this point to a mobile base USB hub/cable/power issue, since both the lidar and VESC device are missing?

Thanks a lot.

4

Hi Claire,

Small update on the Reachy2 Teleoperation app side.

After checking the robot core container, I matched my local Python SDK versions with the robot-side versions:

  • reachy2-sdk: 1.0.7
  • reachy2-sdk-api: 1.0.11

After doing this, the Python SDK works correctly. It connects successfully and can read motor information from the robot.

For example, the SDK shows:

  • Connected: True
  • Head: on=True
  • Right arm: on=True
  • Left arm: on=True
  • Joint present positions and goal positions are available for the head, right arm, and left arm

I can also move the upper body/head/arms through the dashboard.

However, the Reachy2 Teleoperation app still shows:

  • “No motors information”
  • “Reachy is not ready yet”
  • “Some required robot services are not available, teleoperation is not possible”

The Teleoperation app version shown is:

  • Application Version: 1.1.0

From docker ps, the relevant containers appear to be running:

  • core
  • webrtc_streaming_playback_ros
  • grpc-webrtc-bridge
  • webrtc_signalling
  • reachy2-dashboard
  • display/plum-related services

I am connecting to the robot in the Teleoperation app using the robot’s local network IP address, not the .local hostname.

Since the SDK and dashboard can both access the upper-body motor information, could this be a Teleoperation app / WebRTC / bridge compatibility issue? Or is there another service required by the Teleoperation app that I should check?

Thanks a lot.