Document 'Failed to initialize the streaming trajectory'

[cboostpverwimp]

When calling the /start_point_queue_mode followed by populated /queue_traj_point request I receive the following result:

[INFO] [1732279176.490005285] [simple_queue_client]: motoros2_interfaces.srv.StartPointQueueMode_Response(result_code=motoros2_interfaces.msg.MotionReadyEnum(value=1), message='')
[INFO] [1732279176.499192106] [simple_queue_client]: motoros2_interfaces.srv.QueueTrajPoint_Response(result_code=motoros2_interfaces.msg.QueueResultEnum(value=3), message='Failed to initialize the streaming trajectory

Sadly I have not been able to find any documentation about what this means or what could cause this. Could someone help me out?
follow_joint_trajectory does work as intended.

Controller: YRC1000micro
Robot: Motomini
MotoROS2 ver.: Humble 0.1.3

[gavanderhoorn]

Please always provide us with a full debug log when asking for support.

See Debug log client (note: the script is not (yet) part of the release .zips, but you may find it here).

Please make sure to start the debug logger before starting your YRC1000micro, to avoid capturing partial logs.

Please also provide more information about how you are queuing points.

It would also help tremendously if you could provide a minimal reproducable example (ie: code).

Having written that:

follow_joint_trajectory does work as intended.

could you please explain in what way it does not work as you expected?

---

Edit: possibly similar/related: #230.

[cboostpverwimp]

Thanks for the quick response! My apologies for the lack of information.
I misunderstood the use of the debug_listener.py. This gives the context I was looking for:

...
[2024-11-22 13:16:36.900554] [192.168.41.204:51387]: Ros_MotionControl_StartMotionMode: exit
[2024-11-22 13:16:37.101754] [192.168.41.204:51387]: Ros_MotionControl_ActiveTrajMode = 2
[2024-11-22 13:16:37.101754] [192.168.41.204:51387]: Ros_ServiceStartPointQueueMode_Trigger: activated
[2024-11-22 13:16:37.109354] [192.168.41.204:51387]: Streaming point received
[2024-11-22 13:16:37.109354] [192.168.41.204:51387]: Initial point in trajectory queue
[2024-11-22 13:16:37.109554] [192.168.41.204:51387]: Initializing trajectory for group #0
[2024-11-22 13:16:37.109554] [192.168.41.204:51387]: ERROR: Trajectory start position doesn't match current position (MOTO joint order).
[2024-11-22 13:16:37.109554] [192.168.41.204:51387]:  - Requested start: 0, 0, 0, 0, 0, 0, 0, 0
[2024-11-22 13:16:37.109754] [192.168.41.204:51387]:  - Current pos: 19635, 11157, -19321, -8147, 46549, 5799, 0, 0
[2024-11-22 13:16:37.109754] [192.168.41.204:51387]:  - ctrlGroup->prevPulsePos: 19635, 11157, -19321, -8147, 46549, 5799, 0, 0
[2024-11-22 13:16:37.110154] [192.168.41.204:51387]: Reply (3): Failed to initialize the streaming trajectory
[2024-11-22 13:17:51.876954] [192.168.41.204:51387]: Stopping point-queue motion mode. Please call 'start_point_queue_mode' to start a new queue.
...

Error on my part. I know how to progress from here.

Having written that:

   follow_joint_trajectory does work as intended.

could you please explain in what way it does not work as you expected?

This works exactly as intended, it does what I expect it to do.

[gavanderhoorn]

I'm happy you figured it out, but:

I misunderstood the use of the debug_listener.py. This gives the context I was looking for:

no, I think you did not misunderstand anything.

We should improve the error reporting of QueueTrajPoint.

Looking at the debug log should not be necessary.

This works exactly as intended, it does what I expect it to do.

ah yes, apologies.

I misread that as "does not work as intended".

[gavanderhoorn]

We should improve the error reporting of QueueTrajPoint.

tracking in #336.