Okay, superb - the message states to let us know if you need multiple copies. You'll find that documented in a release note a few weeks ago for ARC. Because robot skills could be added as many times as ppl wanted, some cannot be added multiple times due to their development limitations. And because of that, many ppl were breaking their projects by adding 10 copies of Chat GPT for no reason, for example. So now if a particular robot skill requires multiple copies, we must enable it.

I'll do that now for ya.

Okay - it's updated - you'll be prompted when you restart ARC with an internet connection. I don't have permissions to update the release notes on the robot skill page, so we'll have to wait for synthiam support to do it tomorrow. But it should be v21

Ok thank you DJ, I did not read the release notes so I was not aware.  I will try it again and let you know if I am still having the COM port issues. If I do I will provide all the details I can to try and help you locate the issue.

As I follow this conversation more closely, it's impossible to achieve. I understand there may have been a conversation before about locating two lidars. However, a Lidar uses a 360-degree rotation to scan the environment for distances from its center. For a lidar to work correctly, it needs to be placed in the center of the robot, and the robot must pivot on its exact center. See how an iRobot Roomba or other lidar-equipped vacuum is designed-because that's the most accessible reference.

Using a lidar in any application requires adding it to the exact center of the robot. To recap, the robot must rotate at the pivot of the center.

Due to a lidar's 360-degree rotation, it needs to be in the center of the robot.

Lastly, you will find that there is no option for a Lidar physical offset for this reason. Because a lidar scans 360 degrees, it's meant to do so from the center of the robot.

Below is an update that summarizes what is happening based on your conversation:

Multiple RPLidar Skill Instances

DJ_Sures has updated the RPLidar robot skill (version 21) so that you can now add multiple instances to your ARC project. This change was made because some skills (like Chat GPT) were being added in multiples without a true purpose, while others-like RPLidar-have their own development limitations that previously prevented multiple copies from being used. The update should now prompt you with multiple copies enabled when you restart ARC with an internet connection.

Regarding COM Port Connectivity

If you continue to experience issues when switching between COM ports (for example, when one unit works on COM3 while another fails to connect on COM12), please note the following points:

1. COM Port Assignment:
   Ensure that when you add a second instance of the RPLidar skill, you select the correct COM port for that device. Sometimes, a port conflict or resource sharing issue may arise if both devices are not being managed correctly by ARC.

2. Device Driver & Connection Issues:
   Verify that your PC recognizes both lidars correctly and that no other application is trying to use those COM ports. A potential conflict in the drivers or how the LCD firmware handles serial communications could cause one of the devices not to connect.

3. Further Details:
   If you still experience COM port issues, please provide a detailed description (including screenshots if possible) of the error messages, COM port settings, and any other clues. That information greatly helps troubleshooting.

Physical Setup Note

Synthiam_Support has also pointed out that-from a physical design perspective-a lidar is intended to work from the center of the robot. Since a lidar uses a 360 rotation to scan distances evenly around its center, both lidars (if you intended to use them for redundancy or data fusion) should be mounted in positions that meet the proper design criteria. If placed off-center, the data could be inconsistent since the robot must pivot exactly at its center for a meaningful scan.

If you’re attempting to use the two lidars as a workaround to cover different areas of the robot (by applying different physical offsets), please note that the RPLidar robot skill does not offer an option to adjust for a physical offset because the core scanning principle requires a centralized position. In this case, the recommendation is to plan your robot’s layout similarly to a vacuum robot (such as an iRobot Roomba) where one properly centered lidar typically serves your navigation requirements.

Next Steps

1. Restart ARC:
   Make sure ARC is restarted with an internet connection so that the updated version (v21) is applied. Then add the multiple copies of the RPLidar skill and assign them to the correct COM ports.

2. Test COM Ports:
   Verify that each lidar device connects to its assigned COM port. If a COM port fails to connect, double-check that the device isn’t conflicting with any other application or device driver.

3. Physical Considerations:
   Re-assess your physical robot design to ensure that each lidar is being used in a way that respects its 360 scanning constraints (i.e., ideally at or near the robot’s center).

Feel free to reach out with additional details if you run into further challenges or need more guidance configuring your project. We're here to help you get the most out of ARC and your robot skills.

Let me know if you have any more questions or need further clarification!

Well, I wish I would have known this before I spent hundreds of dollars on parts and materials not to mention almost a year of development based on the fact, I was told it would be the way to do it.

Hold on here. I think there's a bit of confusion that support's not aware of yet. Yes, traditionally, the lidar should be in the center of the robot. But due to several recent conversations on this forum about the location of the lidar, we've been looking into moving it. So yes, I know it used to be in the center. But we've been doing work to add that functionality. Specifically, dozens of people have had the same question in the last month.

Now, because it's not "normal" for the lidar to not be in the center, it's not an easy task for the modification. But I can say that we have a working version, so let me update the robot skill with that feature. We expected to update it next week, but I think it's good enough to update today.

Thank you again DJ I thought I had wasted almost a year of my life on this effort.  I am so happy you are working on a solution for this use case.  I am looking forward to checking it out.

I apologize for the mix-up, smiller. We had been realigning customers' project plans over the last few weeks because others had asked to relocate the lidar. I was unaware that this was being considered on the sideline. I'm confident this new feature will be handy for several users asking for something similar.

However, I have a question about the robot's rotation (turning on the spot). Does that still need to happen to ensure the robot's center pivots and turns based on the wheel locations?

Because from what I understand, if the Lidar is offset from the robot's middle, should that be the middle of the pivot location? Not necessarily the middle of the physical robot. @athena, can you answer this?

Below is some guidance on how this works:

• Robot Rotation vs. Lidar Offset:
  Even if you mount the lidar off-center, the robot’s rotation is still determined by its drive system-typically the pivot is defined by your wheel layout or the Movement Panel configuration. In other words, the robot will still turn about the pivot point engineered into your drive design.

• Using the Lidar Offset Feature:
  The updated RPLidar skill now lets you specify both a forward/backward offset and a rotation offset so that the sensor’s data can be transformed correctly relative to the robot’s effective center (i.e., the pivot). This transformation means that even when the lidar is not physically mounted at the geometric center of the robot, the scan data is corrected for mapping and navigation purposes.

• What Does This Mean Practically?
  If your lidar is off-center, you should input the correct offset values (both linear and rotational) in the updated RPLidar skill. That way, although your robot continues to rotate around its natural pivot (as defined by the wheel locations), the skill will adjust the scan data so that obstacles and mapping data align with the intended coordinate system.
  For example, if the lidar is mounted closer to the front bumper rather than at the pivot, setting the appropriate forward offset ensures that the data will represent the space relative to the actual turning center of your robot-not necessarily the physical mounting location of the sensor.

• In Short:
  Yes-the robot must still pivot based on the wheels’ configuration. The offset parameters in the updated RPLidar skill are there so you can account for a non-central mounting. They transform the raw scan data so that your navigation and mapping calculations use the virtual center of the robot (or the intended pivot point) even though the lidar is offset.

I hope this clarifies how the updated functionality works! If you have further questions or need additional details about configuring your offsets in the RPLidar skill, please let me know.

Okay, so the definition of the robot's middle is the pivot point, not the chassis middle. That's the absolute center of the drive system, the center between all of the wheels, tracks, etc.