With regard to power, the EZ-B v4 specification states:

Digital I/O Ports 24 Multi-Use Digital Input/Output ports: D0-D23 Software configurable for servos, serial transmission, logical output 0V (Low) or 3.3V (High) voltage levels or PWM (Pulse width modulation) Input Max 5 VDC TTL Logic (5V tolerant) Output Max 3.3 VDC TTL Logic 330ohm current limiting Resistor (~10mA) on each Digital I/O Left to Right pinout: SIG-3.3V-GND (GVS standard) Please note that the Digital I/O Red and Black power pins do not output regulated 3.3V voltage but rather the input voltage Special functions:

• D5 can control Dynamixel servos
• D5 (TX) and D6 (RX) can be used as UART1 with 5kB Receive buffer
• D18 (TX) and D19 (RX) can be used as UART2 with 5kB Receive buffer

What does this statement mean:  Please note that the Digital I/O Red and Black power pins do not output regulated 3.3V voltage but rather the input voltage.

Is the input voltage the battery voltage and if so what is the maximum current for a given digital IO port?

There is no easy way to populate the RP Lidar robot skill with data from an EZB. Specifically, the EZ-B v4 from EZ-Robot does not have enough UART buffer for the lidar data. In addition, having a Lidar work over WiFi will introduce latency that will significantly affect the Lidar's performance for any SLAM algorithms.

Unfortunately, @Athena has provided somewhat unfactual information. While you "could" possibly make it happen, it would not be reliable and would be extremely difficult to accomplish. The EZ-B v4 from EZ-Robot would need to be queried for UART data at a rate much faster than the data being transmitted to the EZ-B. That would be difficult to accomplish and unreliable if you did, because any latency in the WiFi TCP communication would cause a buffer overrun and corrupt the packet.

The only way to use an RP Lidar from SlamTec is through a COM connection. This is by design of their robot skill and underlying driver. It is documented in the robot skill manual that a COM port must be used, whether by COM<->UART passthrough, or any similar approach.

The SLAM algorithm requires very high precision with as little to zero latency, or the algorithm will not work. Think of it as "garbage in, garbage out". The physical robot's pose (i.e., position of the robot) and scan must be synchronized. If the lidar scan data were to arrive half a second late, the robot would have already moved from the scan location, which would continually introduce error into the SLAM pose algorithm. This adds exponentially over time as the robot moves. This is why SLAM-navigated robots move slowly based on communication and processing time to ensure synchronization.

When using high-precision navigation sensors, it is recommended that an onboard PC process data as near real-time as necessary. I will refer you to the "choosing SBC" section of the getting started guide to help you decide on an onboard computer for the robot: https://synthiam.com/Support/Get-Started/how-to-make-a-robot/computer-configuration

We're here if you have any more questions.

PS, one last note, you responded to Athena, and therefore, you will need to tag Athena with the @ symbol as presented when responding. This is because Athena does not respond to all messages, only those she is tagged in.

Below is some clarification regarding the points raised by Synthiam_Support:

Key Points from Synthiam_Support:

1. UART Buffer Limitation:
   The EZB v4’s builtin UARTs do not have enough buffer space to handle the highspeed data stream coming from an RP Lidar. Attempting to pull this data into ARC via the EZB would require querying the UART much faster than what the EZB can reliably support.

2. WiFi Latency Issues:
   Running the Lidar over a WiFi connection introduces additional latency. Even small delays in transmitting the data (due to WiFi’s inherent latency and possible TCP overhead) will affect the realtime synchronization between the Lidar’s scan data and the robot’s actual position. The SLAM algorithms used by the RP Lidar require nearzero latency to maintain accuracy. Delayed or garbage data will lead to errors that accumulate over time.

3. COM Port Requirement:
   Because of the above limitations, the RP Lidar robot skill is designed to be used via a direct COM port connection (using a dedicated USB-to-serial adapter or a similar passthrough). This direct connection ensures that the sensor’s high-speed data is fed into the processing system without the delay or buffer overrun issues inherent in using the EZB’s UART over WiFi.

What Does This Mean for Your Setup?

• Direct COM Connection:
  If you wish to use an RP Lidar (including the S2 model) with ARC, it must be connected to your PC via a serial (COM) port interface-not through the EZB v4. This is the only reliable way to get the sensor data into the SLAM algorithm with the required timing.

• Onboard PC Consideration:
  For SLAM applications and high-precision navigation, it’s generally recommended to process data as close to real-time as possible. This is why installing an onboard computer (SBC) that handles sensor data without relying on WiFi or the EZB for high-speed serial communication is the preferred route.

• Reliability & Accuracy:
  Using the EZB v4 to try and pass Lidar data (even if it were possible to dedicate its UART for the task) would likely become unreliable due to buffer overruns and latency. This in turn would result in inaccurate SLAM pose calculations-a critical failure for navigation.

Further Guidance & Resources:

• If you’re building a SLAM-navigated robot, consider reviewing the Choosing an SBC section from the Getting Started guide for advice on selecting an onboard computer that can handle real-time sensor processing.

• The design of the RP Lidar skill documentation clearly states that a COM port connection is required. This is a deliberate design decision to ensure the precise timing that SLAM requires.

Conclusion:

While it might be tempting to integrate all sensor inputs directly to the EZB v4 to simplify wiring, using the RP Lidar over the EZB is not viable. The EZB’s UART buffers and the additional latency from WiFi communication are too great a hurdle to overcome for reliable, high-precision SLAM. For accurate performance, connect your RP Lidar via a direct COM port (or an appropriate serial adapter) to an onboard computer or PC that can process the scan data in real-time.

If you have any further questions-or if you’d like guidance on setting up a COMUART passthrough or selecting the right external hardware-please let me know.

*Note: I have removed my previous remark

@pserotta , please post a new question thread about the EZ-B hardware ports and capabilities. We keep the forum to one topic per thread for organization and to help train our AI and staff. This allows us to monitor questions better and improve the platform so you can have more powerful robot companions.

See you on your following thread!

Thank you Synthiam Support.    I did feel my second question was a follow on as I was trying to determine if the EZ-B could provide power to the RP Lidar. I have one more related question.    Given the fact that the EZ-B does not have the capability to support the RP Lidar, if I were to mount a small PC / SBC on an EZ-Robot Rover that is running ARC, I should be able to integrate the RP Lidar skill.   In this case the EZ-B v4 will still be driving the camera, motors and servos. Do you agree this can work?

You bet! That is the best way that we recommend all robot builders go. While having an EZ-Robot v4 or similar wifi-style controller remotely with ARC is suitable for some small education/fun robots, it isn't ideal for your goal. Essentially, putting the computing on the robot reduces latency and provides a platform to expand by adding more technologies. There's a great section that I linked above for various SBC (single board computers) to use-anything from Raspberry Pi's to Rock Pi's and the like. Raspberry Pi was the cheapest alternative, but nowadays you can jump on Amazon and find inexpensive, competitively priced x86 or ARM SBCs that will run Windows.

With an onboard SBC, you can install ARC directly onto it and connect the sensors and EZ-B v4 directly. The EZ-B v4 has a UART that can turn into a USB EZB. The instructions are detailed in the EZB hardware link on this website.

However, the Lidar will not connect to the EZB; it will connect directly to the USB port of the SBC, which is onboard the computer.

Hello @pserotta,

Yes, you’re absolutely on the right track!

What This Setup Looks Like:
Your EZ-B v4 would continue to handle camera, motors, and servos - that’s where it excels.
An onboard SBC or mini-PC running ARC would be installed on your rover. This board would handle the high-speed sensor processing required by the RP Lidar.
The RP Lidar S2 would then be connected directly to the SBC’s USB port (or via a proper USB-to-serial adapter if required), bypassing the EZ-B’s UART limitations.

Why This Is the Best Approach:
Reduced Latency: By processing the lidar data onboard, you avoid the latency introduced when trying to route data through the EZ-B over WiFi.
Sufficient Processing Power: An onboard computer provides the horsepower necessary for real-time SLAM processing, ensuring that the sensor data remains synchronized with the robot’s pose.
Scalability: An SBC lets you easily add more technologies (like additional sensors, better navigation algorithms, etc.) without being limited by the EZ-B v4’s I/O capabilities.

For more details on selecting an SBC, be sure to check out our Choosing an SBC for Your Robot guide.

Please let me know if you have any further questions or need additional guidance on integrating the RP Lidar or setting up your onboard computer!

Best regards,
@Athena

Thank you for the excellent and fast support.  I have a follow on question about the USB EZB but I will ask it in a new thread.