Hitachi-LG LDS-01 On Up Board Via USB

Yes - that combination can work reliably on an Up Board running ARC directly on Windows, but the symptoms you’re describing usually point to one of these issues:

1. A marginal USB-UART link at 230400 baud
2. Power noise / ground noise affecting the lidar
3. The lidar skill receiving occasional corrupted serial frames
4. Pose hint configuration not matching the navigation setup

What I’d recommend first

1) Use a known-stable USB-UART adapter

In practice, the most reliable adapters for high-baud sensors like this are usually:

• FTDI-based adapters
• CP2102/CP2104-based adapters from reputable vendors

Since you’ve already tried both, the next test is not another adapter - it’s to simplify the setup:

• Keep the USB-UART adapter directly connected to the Up Board
• Remove the powered hub for testing
• Use the shortest possible cable
• Make sure the lidar has a clean 5V supply
• Keep ground tied at a single point if possible

If the checksum bursts remain periodic, that strongly suggests signal integrity or framing issues, not ARC performance.

2) Confirm the Hitachi-LG LDS skill settings

For the Hitachi-LG LDS Lidar skill:

• BaudRate: 230400
• Offset Degrees: use this only for mounting correction, not for data corruption
• Advanced communication parsing: off unless debugging
• Set variables with location data:
  • on if you want the scan data available in globals
  • off if you’re only using NMS and want slightly less overhead
• Fake NMS Pose hint event:
  • on only if you are using Hector pose hint and no external pose sensor
  • off if Better Navigator is getting pose from another source

Important:

If Better Navigator is showing "No pose provider", that means it does not have a valid Level 3 Group 2 pose source.

So if you’re only using the lidar:

• Hitachi-LG LDS skill: Fake NMS Pose hint event = enabled
• Better Navigator: Pose Hint = Hector

That is the correct pairing for lidar-only mapping.

If you have wheel encoders, T265, or another pose source, then Better Navigator should use that instead, and Fake NMS Pose hint event should usually be disabled.

3) Offset Degrees sign convention

For Offset Degrees, treat it as a mounting correction:

• Positive or negative rotates the scan direction
• It should be used to align the map orientation, not to compensate for serial corruption

If you want, I can help you determine the sign convention in your setup by using a simple known-point test:

• place the robot facing a wall
• observe where the wall appears in the scan
• adjust offset until front-facing objects appear at the correct heading

4) Why the checksum mismatch bursts matter

Because you’re seeing:

• distance zeros
• wild jumps
• checksum mismatch messages
• periodic bursts about once per second

that usually means the serial stream is occasionally getting bad frames. That is not normal lidar behavior and not something Offset Degrees would hide.

This can happen from:

• insufficient power filtering on the lidar
• USB serial adapter instability
• EMI from motors or buck converters
• a cable/connector issue
• adapter driver behavior on the specific Windows system

5) Best next test on the Up Board

Try this exact isolation test:

1. Power the lidar from a clean regulated 5V supply
2. Disconnect all motors and high-current loads
3. Connect only:
   • Up Board
   • USB-UART adapter
   • lidar
4. Use ARC with:
   • BaudRate 230400
   • Advanced communication parsing ON temporarily
   • Fake NMS Pose hint event ON
   • Better Navigator Pose Hint = Hector
5. Watch whether the checksum mismatches still happen

If the issue disappears in isolation, the culprit is almost certainly system noise or power coupling from the robot.

6) If you want Better Navigator to stay happy

For a lidar-only setup, the cleanest configuration is:

• Hitachi-LG LDS skill

  • BaudRate: 230400
  • Offset Degrees: mount correction only
  • Advanced communication parsing: off for normal use
  • Set variables with location data: optional
  • Fake NMS Pose hint event: on

• The Better Navigator

  • Pose Hint Source: Hector
  • Use the lidar scan data
  • No external pose sensor required

If you are using wheel encoders or another pose sensor, then tell me which one, because the recommended Better Navigator pose hint changes.

7) My suspicion

Based on your description, I’d rank the likely causes like this:

1. Power or EMI noise
2. Serial signal integrity / adapter behavior
3. Pose configuration mismatch
4. ARC performance - least likely, since CPU is low

A couple of questions so I can narrow it down

1. Is the lidar and USB-UART sharing the robot battery ground only, or are there any other ground paths?
2. What exact Hitachi-LG LDS-01 power supply voltage are you using at the sensor side?
3. Is the lidar mounted near motors, ESCs, or switching regulators?
4. Are you using Better Navigator with only the lidar, or do you also have a pose sensor like wheel encoders or T265?

If you want, I can also give you a known-good ARC configuration checklist for the LDS-01 + Better Navigator on an Up Board.