Page 1 of 1

Sending RMP_CMD_NONE not getting a response

Posted: Wed Apr 25, 2012 2:10 pm
by twlbean
Documentation for this command says:
This command can be used to poll the CCU for data without issuing a command that will result in an action. This command does nothing, but it is valid and will solicit a response.
When I send an RMP_CMD_NONE message (with parameter = 0) to the platform I do not get a response. Is this a bug?

Re: Sending RMP_CMD_NONE not getting a response

Posted: Wed May 02, 2012 9:05 am
by phussey
I just tested this and the CCU responds just fine to the RMP_CMD_NONE general purpose command on all interfaces.

With CAN the packet is:
id: 0x0501
data[0] = 0
data[1] = 0
data[2] = 0
data[3] = 0
data[4] = 0
data[5] = 0
data[6] = 0
data[7] = 0

With USB or Ethernet the packet is:

data: [0x05, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x80, 1D]

To test yourself go into rmp_interface.py and modify as follows:

1. comment out lines 270 - 282 (where the command gets populated)
2. insert:

self.commands[0] = int(RMP_USB_ETH_CFG_CAN_ID);
self.commands[1] = int(RMP_CMD_NONE);
self.commands[2] = int(0);

should look like this when your done:

"""
now populate the message
"""
"""
if self.general_purpose_command == RMP_CMD_NONE:
vel_cmd = convert_float_to_u32(self.velocity_cmd_f);
yaw_cmd = convert_float_to_u32(self.yaw_cmd_f);

self.commands[0] = int(RMP_USB_ETH_CMD_CAN_ID);
self.commands[1] = int(vel_cmd);
self.commands[2] = int(yaw_cmd);

else:

self.commands[0] = int(RMP_USB_ETH_CFG_CAN_ID);
self.commands[1] = int(self.general_purpose_command);
self.commands[2] = int(self.general_purpose_param);
"""

self.commands[0] = int(RMP_USB_ETH_CFG_CAN_ID);
self.commands[1] = int(RMP_CMD_NONE);
self.commands[2] = int(0);

The OCU will still receive data just fine when sending only the RMP_COMMAND_NONE general purpose command. Hope this helps.

Re: Sending RMP_CMD_NONE not getting a response

Posted: Mon May 07, 2012 4:59 pm
by twlbean
It turns out I was sending the command without knowing the user feedback bitmap settings. The configured feedback settings (in my case) actually gave less data than expected which left me waiting for more data every time.

The fix, for me, was to use the RMP_CMD_FORCE_CONFIG_FEEDBACK_BITMAPS command instead.