thanks for your response. the firmware version read by ARC is 257 /258. I am not sure Slamtec knows about these numbers . That's why I sent you the version from robostudio which is 1.1/1.2.  it seems to be the official version of slamtec

Have you tried the latest update to the RP Lidar robot skill?

It is very interesting that their libraries and applications return different values for the firmware. Because ARC doesn’t provide firmware version numbers for the RP Lidar. ARC functions like an operating system (similar to Microsoft Windows), and the RP Lidar robot skill is developed by the hardware manufacturer using their own SDK, library, or API. If you see firmware values such as 257 and 258, those are raw values returned directly by their library. Their RoboStudio software likely translates these values into something more user-friendly, while the robot skill returns them as-is. We could not guess their reasoning for having differing representations of the firmware.

Since Synthiam doesn't develop the RP Lidar’s SDK or robot skill, we can’t speak to the manufacturer’s reasoning for returning different firmware values.

That said, the latest update to the RP Lidar robot skill appears to include several improvements-one of which addresses timeout behavior, which relates to the issue you previously encountered. We recommend installing the latest version of the RP Lidar robot skill and reviewing the new configuration options to see if they help resolve the problem.

Indeed, the latest update solved the problem - the 'new' RPLIDAR with firmware version 258 now works. I retested with the older RPLIDAR (firmware version 257), and it works too. I don't know what you did, but everything works fine now. The RPLIDAR skill v26 has a new feature: 'force scan' or 'use typical scan.' In my case, 'typical scan' is being used. The Better Navigator also works with both versions.

That’s wonderful to hear. The resolution must have been related to their new Timeout option. Looking at their sdk, we guess their default was 2000 ms and the new default setting is 5000. That must provide more time for the motor to spin to speed without timing out.

Regarding the firmware, I know what you guys are seeing. I took a look at their library and they return the firmware version as an unsigned 16 bit int...

typedef struct _sl_lidar_response_device_info_t
{
    sl_u8   model;
    sl_u16  firmware_version;
    sl_u8   hardware_version;
    sl_u8   serialnum[16];
} __attribute__((packed)) sl_lidar_response_device_info_t;

So it looks like the 16 bit unsigned int is both parts of the decimal firmware. It can be wrapped such as...

uint16_t fw = devinfo.firmware_version;
int fw_major = (fw >> 8) & 0xFF;
int fw_minor = fw & 0xFF;

std::cout << "Firmware Version: " << fw_major << "." << fw_minor << std::endl;

Okay - we can display that version in the robot skill formatted as major/minor. That will be a bit of a hack because they aren't doing that in their robot skill for some reason. It's probably something they overlooked.