AGV Customization Delegate - End Speed in Add Kinematics

Question

question

Iago MF asked Dec 18, '23 Iago MF commented Jan 17, '24

AGV Customization Delegate - End Speed in Add Kinematics

Hi!

In a project, I've been told that AGVs, when coming to a stop for any reason, apply a precision speed of 65 mm/s at a distance of 165 mm from the stopping point before halting. Since I was already using the customization delegate for other purposes, it seemed appropriate to implement this behavior in the addKinematics, applying it when the end speed is 0. However, what happens in the model is that the endSpeed data is almost always 0 and it makes intermediate stops between control points. I don't understand why it returns that endSpeed value if the kinematics added to advance between control points shouldn't have an end speed of 0 for it to move smoothly, given OnBuildKinematics.

Does this mean that the end speed is the final speed of the travel path regardless of the segments it makes with kinematics between control points? If so, then how does the addKinematics know whether the AGV has to stop or not if it always returns an endSpeed of 0?

I attach a sample model.

Thanks in advance

23.2 Precision Speed.fsm

Software Version:

FlexSim 23.2.3

agvnetwork customization delegate

232-precision-speed.fsm (33.0 KiB)

· 2

Felix Möhlmann commented · Dec 18, 2023 at 06:53 PM

The kinematics are added up to the stop distance of the allocation point (which would generally be a control point if not using accumulation or otherwise changing the stop distances). The endspeed always being 0 is correct in that way.

However, at the point where the AGV would start to decelerate as part of the final kinematic, it will try to allocate the next allocation point. If successful, the previous kinematics are dismissed and new kinematics are planned up to the new stop distance, starting at the current speed.

Unfortunately, this knowledge does not help to find a solution, since as I mentioned, it is the last decelation in the kinematics that determines when the next point is allocated. As such, any previous speed changes will invariably be part of the AGV motion.

To at least get the travel timing correct, you could use a lower custom deceleration value, so the time to come to a full stop is the same as if the AGV first decreased down to precision speed.

Posting this as a comment, since this is a) just knowledge based on observation and b) someone else might have a better/proper solution

0 ·

Iago MF Felix Möhlmann commented · Dec 19, 2023 at 07:19 AM

I thougth that the kinematic to the stop point was at the end speed calculated to accomplish the next travel path peak speed. Then if it isn't possible to allocate a control point in the current travel path (at the look ahead point), a new kinematics interrumpts to decelerate.

I'll use a custom deceleration until a better solution then.

Thanks Felix!

0 ·

Answer 1 · 2024-01-16T21:31:56Z

anthony.johnson answered Jan 16, '24 Iago MF commented Jan 17, '24

Felix's comment is correct. When it builds kinematics, it adds kinematics up to the next point where it would have to stop if it could not allocate ahead. The end speed here is going to be 0. Once the delegate has added the kinematics, it then analyzes those kinematics to find the point at which the AGV would start to decelerate to the 0 end speed. That point becomes the 'pre-arrival' point. Then, when it gets to the pre-arrival point, if it cannot allocate ahead, it will again restart the kinematics to decelerate to 0. However, if it can allocate ahead, it will start the process over, building kinematics ahead to the next point. So it's kind of doing double duty building kinematics when it has to decelerate because of a failed allocation: building ahead on the path to 0 end speed at the stop point, and then rebuilding to 0 end speed when it can't allocate. Perhaps this should have been designed differently, but it is what it is at this point.

The times when the customization delegate will be called with end speeds that are not zero is when the AGV travels over transfers between different paths. You don't see this in your model because all of the control points are on a single path.

As far as how to implement your specific situation, I'm not sure I understand what your goal is. If you want it to be at 65 mm/s when it is 165 mm from the stop point, and decelerate from that point to 0, to me this is just a different way of defining the deceleration. The average velocity over the deceleration is 32.5 mm/s, and distance traveled is 165 mm, so the time to decelerate should be 165/32.5 = 5.07 s. So your deceleration should be 65 mm/s over 5.07s = 12 mm/s/s. Don't know if you really need a custom AGV delegate for that. Maybe I'm not understanding your specific desires.

· 1

Iago MF commented · Jan 17 at 07:31 AM

Thanks for explaining. The problem in the model I'm working on is that, due to the high volume of movements and the quantity of AMRs. When testing with slight variations in deceleration and turning times, significant impacts on results have been noticed. While I initially thought using the actual kinematics directly would be the most accurate approach, I agree with you that calculating the required acceleration for the desired stopping time is a valid alternative.

Thank you so much!

0 ·

question