Since the release of Mobile Robot Resource (Multi Layers), it has been unable to function properly. I am unsure of the significance of VC officially releasing such a completely unusable component (to meet personal KPIs?). I have repeatedly reported the issue in the original post, but it has not been resolved. Regarding the core issue of the Mobile Robot Resource (Multi Layers) component being unusable, I summarize it as follows:
The inability to confirm the direction of AMR may lead to potential collisions.
My own idea: Add an optional alignment attribute to the Pathway Area component, so that the AMR of TravelForwardAxis for bi is forced to align with the X-axis of the path coordinates when passing through this path. This can solve the biggest problem of Mobile Robot Resource (Multi Layers) (this is just a solution I personally came up with);
The incorrect object coordinates of the Mobile Robot Resource (Multi Layers) may cause the AMR to collide with other objects during the rotation process.
Solution: The object coordinates of Mobile Robot Resource (Multi Layers) should be at the geometric center with a zero Z-axis, rather than directly below the DEFAULT_location
The meaning of N+1 mode: If this mode is enabled, after AMR fills up N levels, the TransportNode can also act as one level.
If issues 1 and 2 are resolved, the Mobile Robot Resource (Multi Layers) can be put into normal use immediately. If issue 3 is resolved, the application scenarios of AMR can be expanded.
I hope the VC official can attach importance to this component.
@idkfa I am just giving feedback that there is a serious issue with this component currently. You can confirm the problem. If it is not updated, then this component will not have much meaning in eCat
Exactly, that’s why I recommend submitting a formal support request via support@visualcomponents.com. Unlike the forum, support requests are handled formally and ensure the issue is documented for further investigation.
However, if you prefer to address this in the forum, let’s give it a try. I have added the ExtraBuffer feature for item 3 in eCat 4.10. Could you upload videos to describe items 1 and 2 in more detail? This will help us better understand and address these issues.
@idkfa Thank you very much for responding to my question.
Firstly, I would like to add that the first and second questions are actually related,
Let me first discuss the second issue. As can be seen from the first picture in the attachment, the power wheel of the AMR is located at the bottom center, which means that it needs to rotate around the geometric center of the chassis when rotating (this is the case for all AMRs of this type in the market, Can reduce AMR rotation radius and site occupation). In other words, there is an X-axis offset between the coordinates of the AMR components and the coordinates of the TransportNode, which leads to a forward or backward offset of the FlowInResourceLocation and FlowOutResourceLocation of the shelf relative to the product when the AMR picks or places from the shelf. This is also the reason why it is necessary to enforce directionality during the pick and place path of the AMR on the shelf. If the existing AMR is manually rotated 180° around the Z-axis, the direction will be reversed when starting the simulation.
This warehousing and logistics model is of a dense type, and it does not tilt into the shelf aisle as the video you provided does, which means that the path of the AMR entering the shelf is very close to the shelf. As shown in the second picture in the attachment, if the coordinates of the AMR component are not at the geometric center of the bottom, it will collide with the shelf
I also provided a demo CAD with 2 options, but in reality, only one option can be selected, even if both options can meet the requirements at the same time.
@idkfa Additionally, I would like to add that I believe these three issues are related to AMR and not mine, as the VC development of this component must have been based on existing physical products in the market. However, the working logic of this component is different from that of the physical product, which is the reason for the problem
I have tried to enable the CenterlineConnect property, but it did not solve these issues. However, if the AMR is rotated 180 ° before starting the simulation, the channel between the AMR and the shelves will change again
Thank you very much for providing timely feedback
To ensure operational efficiency, the default entry mode for real AMR is +x in any aisle. In special cases, such as when there is a wall at the end of the shelf aisle, AMR will be set to force a -x entry when entering this shelf aisle;
Additionally, I would like to add two more questions:
The +x direction of real AMR should be at the level end, while the AMR component in eCat is exactly the opposite;
After modifying the length, width, and height of the AMR Level in eCat, although the values of the Vehicle’s length, width, and height remain unchanged, the Vehicle model also changes accordingly, and vice versa; normally, the two parts of the model should be independent and unaffected
@idkfa Sorry, I double checked my previous statement and it seems there may be an error. I will rephrase it here
This real AMR should have directional requirements for any channel. Assuming a channel requires the AMR to be oriented in the+X to right direction on the channel, the real AMR will enter the channel in the+X direction from the left. Conversely, if the real AMR enters the channel from the right, it will enter in the - X direction to ensure that the+X of the real AMR meets the requirements on this channel. You can refer to the following picture
@idkfa Hello, thank you very much for taking the issue with this component seriously and addressing it. Is the first problem already being modified? When is it expected to be repaired? I am looking forward to using this component in various scenarios
