Error: Failed to allocate instruction batch!

[TopRamen1]

Hi

I'm using the Smartmicro DRVGRD 169 (umrr9f_v2_0_0) radar I encountered a connection issue strange issue after trying to change the ip_source_address and ip_dest_address parameters. I will add here that I have changed them successfully in the past but the second time errors occurred. The sensor can be pinged only on the default address, not on the new one.

To fix this issue I tried to run the ros2 driver service to reset the parameters to the default values. I launched the node with the radar sensor ip set to the default, it initialized without errors:

[INFO] [smartmicro_radar_node_exe-1]: process started with pid [58]
[smartmicro_radar_node_exe-1] [INFO] [1685544115.126520882] [smart_radar]: Data stream services have been received!
[smartmicro_radar_node_exe-1] [INFO] [1685544117.152770493] [smart_radar]: Radar services are ready.

After that, I wanted to reset the sensor parameters but unfortunately, I get the following output:

ros2 service call /smart_radar/send_command umrr_ros2_msgs/srv/SendCommand "{command: "comp_eeprom_ctrl_default_param_sec", sensor_id: 100}"
requester: making request: umrr_ros2_msgs.srv.SendCommand_Request(command='comp_eeprom_ctrl_default_param_sec', sensor_id=100)

response:
umrr_ros2_msgs.srv.SendCommand_Response(res='Failed to allocate instruction batch! ')

I get the ''Failed to allocate instruction batch!" error on the set_ip_address command as well.

What exactly does this service response mean? Is there any other option to do a factory reset on this sensor when the communication fails?

Thanks for help in advance.

[smartSRA]

Hey,

The standard procedure when updating the ip address using the ros2 service is to restart the sensor and relaunch the node with the new ip address.

I suppose since you changed the ip address, it is not communicating with the sensor and hence failing to allocate the instructions. I would suggest to verify the sensor ip addresses and make sure that the driver is connected to the sensor. This could be done by doing an echo of the topic where you should see the pcl data.

Once you have made sure that the sensor is connected and working with the driver only than you should send the service calls.

[TopRamen1]

The data is not being sent to the point cloud topic. After changing the params the sensor stopped sending outputs on both the old ip address (192.168.11.11) and the new one (10.15.20.230). I can ping the sensor on the old IP and not on the new one.

Additionally, I have tried changing the destination ip (this functionality is not supported by the driver). My suspicion now is that I have a mismatch between the destination and sensor ip addresses which creates a problem with connecting to the sensor.

I suspect that the sensor is running with the destination ip in a different subnet than the sensor ip.

Is there a way to reset the sensor parameters without working connection?

[smartSRA]

Hey,

There surely is a mismatch in your connection settings. This would be a bit harder to be done through the driver. I would suggest to use our drive recorder tool to reset the sensor.

The second option would be to make sure that the destination address of the sensor and the source are on the same subnet and data is being exchanged and continue using your modified addresses.

[TopRamen1]

I tried to use the drive recorder but see the same problem there.

When using Wireshark to sniff the communication I see that the sensor tries to get initialized at both 192.168.11.11 and 10.15.20.230.

Regarding the Drive Recorder, I tried to establish the connection but I get the same results as through ros2. The connection can't be established on both subnets and in different dest and sensor configurations

[smartSRA]

Hey,

I would suggest to use can interface (ideally if you have a lawicel converter) rather than ethernet with the drive recorder and reset the sensor.

[TopRamen1]

I have Vector CANanalyzer Interface available, I used it previously with the sensor however after playing with the sensor parameters the CAN was turned off and stopped publishing. The connection can't be established as well.

This leaves me with no CAN or Ethernet connection. Is there a recovery option for such situations? Perhaps some way to sniff the device ip configuration or so on?

[smartSRA]

You can still send the commands or instructions using CAN. When you disabled CAN that command only disables the streaming of data and not the entire CAN connection so you can still communicate with the sensor using CAN.

[TopRamen1]

I am currently trying to send the reset commands via CAN but the channels remain inactive. It worked before using the ROS2 services to change parameters.

In the short period after the reinit the parameters seem to be passed with success however the senor does not go back to the default values.

i try to use the comp_reset_ctrl_factory_reset command

One more observation i have is that the commands in the drive recorder are different than the ones available in the ros driver here: https://github.com/smartmicro/smartmicro_ros2_radars/blob/master/umrr_ros2_driver/config/sensor_commands.json

[smartSRA]

I would suggest to follow the Driverecorder manual which tells in detail on how to setup CAN and send instructions/commands. Once you sent a reset request you need to restart the sensor.

If you are still having trouble, I would suggest you contact our support team and they should further assist you preferably a live session.

The driver only offers few of the commands however drive recorder has many other commands that the sensor uses. They are not different just a subset.

[TopRamen1]

Just to be sure the Driverecorder you are referring to is the Customer Interface available in Firmware Bundle in the partner-zone? I could not find a Driverrecorder specific guide.

[smartSRA]

I am not sure if all the information is available in the firmware bundle. I would suggest you to contact the support team so they can assist you in setting up Drive recorder.

[smartSRA]

I believe this issue has been resolved as you have had contact with our support team and hence I would close this issue.