AGV Customization Delegate - Error in kinematics parameter

AGV Customization Delegate - Error in kinematics parameter

moehlmann_fe
Advocate Advocate
156 Views
2 Replies
Message 1 of 3

AGV Customization Delegate - Error in kinematics parameter

moehlmann_fe
Advocate
Advocate

[ FlexSim 23.1.3 ]

Hi everyone,

I found what I think must be a bug with the AGV customization delegate.

The goal is to be able to be able to force the AGV to change speed at pre-determined distances along the travel path (path classes wouldn't work since it needs to be able to travel along the same path at different speeds, depending on which path it will take at the next intersection, for example). The idea was to use the delegate to handle adding the kinematics in custom code. When passing control points, the AGV would receive data that determines at which distance past the control point it has to change its speed. This data is used when adding the kinematics to split them up into multiple smaller sections.

This approach depends on knowing the distance along the path at which the kinematic starts. This is given as a parameter in the respective "addKinematics" node as shown in the documentation.

1690459415988.png

However, this parameter has the wrong value when the current travel section ends at the end of a path. As you can see in the gif below, the first time the code is executed, the "atTravelDist" parameter is equal to the distance travelled rather than 0. The second section, which ends at the control point, has the correct value.

wrongtraveldist.gif

Tests with multiple paths inbetween two control points seem to indicate that the distance the AGV will travel along that section is incorrectly added to the parameter in these cases. This can be observed well, if the AGV starts at the control point in front of the curved path in the attached model.

AGV-delegate-parameter-bug.fsm

For now I get around this in my actual model by storing the cached travel distance in the AGV's tree in the OnAllocate event (so before new kinematics are added). Then adding each kinematic distance onto that value when creating new kinematics. So I always have access to the correct start distance.

0 Likes
Accepted solutions (1)
157 Views
2 Replies
Replies (2)
Message 2 of 3

jason_lightfoot_adsk
Autodesk
Autodesk
Accepted solution

Confirmed this Felix - thanks for point it out. The atTravelDist isn't the distance along a path it's the cumulative kinematic travel in X which as you say, looks like it should be zero the first time it's called. I'll send it into the dev team.

0 Likes
Message 3 of 3

moehlmann_fe
Advocate
Advocate
Thank you for confirming and reporting the issue.
0 Likes