[BUG] Python API - [flexiv::Robot] getPrimitiveStates: No response from server
Closed this issue · 3 comments
Version information
- RDK: 0.10
- Robot software: v2.10.9
- OS: MacOS Sonoma 14.4
Describe the bug
When parsing the pt_states, the internal robot server fails to update the primitive states.
Steps to reproduce
- Issue Slide Zig Zag primitive
- Poll for pt_states
- See error
Example Command and output:
pt_states = robot.getPrimitiveStates()
RuntimeError: [flexiv::Robot] getPrimitiveStates: No response from server
Relevant Log Lines:
[2024-05-22 04:28:59.251633][error] [General]300000: Fault. Primitive states triple buffer shouldn't be empty
[2024-05-22 04:28:59.251643][trace] /home/flexiv/sw/flexiv_sw/flexiv/lib/FlexivRdk/FlexivRdkServer/Src/RpcServer.cpp:179 @ sendPtStates.[2024-05-22 04:28:59.251643][error] [General]300000: Fault.
[2024-05-22 04:28:59.251643][trace] /home/flexiv/sw/flexiv_sw/flexiv/lib/FlexivRdk/FlexivRdkServer/Src/RpcServer.cpp:507 @ process.[2024-05-22 04:29:02.845823][debug] contact lost count > 1500
[2024-05-22 04:29:02.955823][debug] contact lost count > 1500
[2024-05-22 04:29:03.256003][debug] [RDK] [RPC Server] Restarting ...
[2024-05-22 04:29:03.256013][debug] [RDK] [RPC Server] Created new socket handle
[2024-05-22 04:29:03.256033][debug] [RDK] [RPC Server] Listening on: [0.0.0.0:19802]
[2024-05-22 04:29:03.256063][debug] [RDK] [Commands Server] Restarting ...
[2024-05-22 04:29:03.256073][debug] [RDK] [Commands Server] Created new socket handle
[2024-05-22 04:29:03.256083][debug] [RDK] [Commands Server] Listening on: [0.0.0.0:19801]
[2024-05-22 04:29:03.256683][debug] [State Machine] Transit system state from [WORKING_EXTERNAL_AUTO] to [STOPPED_EXTERNAL_AUTO]
Expected behavior
Server to constantly output pt_states data.
Additional context
Seems similar to #47
@Knoose It seems you are calling getPrimitiveStates() too fast. If this function is called faster than 1kHz, then there will be no new data available to get. Please reduce the frequency of call to getPrimitiveStates().
Did the older RDK clients protect against this unsafe behavior? Prior to this update, we never observed this issue and our integration layer has not changed.