FAQ

Q: Customer Inquiry

There is something blocking behind my robot’s LiDAR, and the sensor keeps treating that occluding object as an obstacle on the display. How do I fix this?

Problem Symptoms

• There is an occlusion behind the LiDAR (such as brackets, cables, chassis structure, etc.)

• In the point cloud or mapping interface, the occluding object is recognized as an obstacle feature

• May affect navigation path planning or cause false alarms

Root Cause Analysis

The LiDAR is like human eyes—it performs a 360-degree scan of the surrounding environment. If something is blocking behind the sensor, it will “see” that occlusion and mistake it for an obstacle ahead, just like when you have a strand of hair stuck behind your glasses lens and constantly feel something blocking your view.

Solution

Step 1: Identify the Occlusion Position

Observe the specific angular range where the abnormal obstacle feature appears in the point cloud.

Step 2: Enter the LiDAR Parameter Settings Interface

Locate the data masking / angle filtering configuration options.

Step 3: Set the Angular Range Corresponding to the Occlusion as a Masked Region

Have the sensor “ignore” this portion of data.

Step 4: Save Parameters and Recalibrate the Point Cloud

Confirm the occlusion has disappeared.

Recommended Parameter Values

Q: Customer Inquiry

I drew a path on the App for the robot to follow, but the robot doesn’t actually walk along that path during operation. What’s going on?

Problem Symptoms

•The navigation path hand-drawn in the App cannot be followed by the robot during actual operation

• The robot takes a detour or stops near the path without moving forward

• From the monitoring interface, there is still considerable clearance between the robot body and surrounding obstacles

Root Cause Analysis

The robot’s “safety distance” is set too large. It’s like a person who insists on staying two meters away from the wall when walking—naturally, they won’t fit through a narrow alley. The robot thinks it is too “wide,” so it dares not take the narrow path you drew, preferring to take a detour or stop instead.

Solution

Step 1: Open the Robot Parameter Configuration Interface

Locate the safety distance related parameters.

Step 2: Appropriately Reduce the Minimum Safety Distance Between the Robot and Obstacles

Step 3: Observe Whether the Robot Can Now Successfully Pass Through the Previously Inaccessible Path

Step 4: Save the Parameters

After confirming the robot can follow the hand-drawn path normally, save the parameters.

Recommended Parameter Values

Q: Customer Inquiry

Every time my inspection robot reboots, the displayed angle is different, and when it turns, the value jumps by a large amount. Is this normal?

Problem Symptoms

• After robot reboot, the startup angle displayed in the mapping App is inconsistent

• During turning, the angle value changes by a large margin

• When turning right or making slight steering maneuvers near the origin point (0-point), the value change is especially noticeable

Root Cause Analysis

The root cause of this issue is the robot was moved while powered off, resulting in inaccurate localization.

If the robot was pushed, repositioned, or moved while shut down, its actual position will no longer match the position stored in memory—like being spun around with your eyes closed and then opening them, unsure which direction you are facing.

At this point, you need to manually enter the App map interface and complete localization initialization to tell the robot “I am here.” Only after initialization is completed will the angle and position displayed in the App become accurate.

Regarding large value jumps when turning at the 0-point: The 0-point is both the start and end point. Turning at this special position will appear to produce particularly large value changes, just like a clock hand jumping from 11:59 to 0:00—although it has only moved a small step, the numerical value has wrapped a full circle. This is normal.

Solution

Step 1: Enter the App Map to Complete Initialization

After the robot powers on, open the App and enter the map interface, manually complete the localization initialization operation. Only after initialization is completed will the angle and position displayed in the App become accurate.

Step 2: Confirm Initialization Is Complete Before Moving

Observe the mapping App interface, confirm that the map has finished loading, the robot position display is stable, and the angle value is no longer jumping, before issuing navigation tasks.

Step 3: Do Not Move the Robot After Shutdown

After the robot is shut down, avoid pushing or moving it whenever possible. Keeping the robot powered off and powered on at fixed positions helps maintain localization consistency and reduces the frequency of initialization.

Step 4: 0-Point Jump Does Not Require Handling

If the value jump is large when turning at the 0-point origin position, this is a normal characteristic and does not require handling.

Step 5: Persistent Deviation Requires Reloading

If the angle deviation persists and affects operations, try reloading the map or re-initializing localization.

Recommended Parameter Values

Q: Customer Inquiry

My inspection robot returns to charge after completing tasks but always fails to charge. After repeated attempts, it reports an error. What is happening?

Problem Symptoms

• After returning to the charging area, the robot cannot align with the charging station, and the charging indicator does not light up

• After repeatedly adjusting its position, charging still fails, and an auto-charging abnormal error is eventually reported

Root Cause Analysis

This is like trying to find a spot where a sofa used to be based on an old photo, only to discover the sofa was moved long ago. When you arrive, nothing matches the photo, and you simply cannot find the charging port. When the robot first “memorized the route” (during mapping), there may have been equipment or obstacles next to the charging station. Later, these items were moved, but the map in the robot’s memory remains the old version. The actual environment it sees does not match the map in its memory, so it cannot find the accurate position of the charging station.

Solution

Step 1: Open the Robot’s App Mapping Software

Enter the “Map Editing” function interface.

Step 2: Locate the Area Where the Charging Station Is Positioned on the Map

Step 3: Check for Obstacle Markings Around the Charging Station

(usually displayed as dark areas or red blocks)

Step 4: Select Those Obstacle Markings That No Longer Actually Exist and Were Moved Away Later

Delete them.

Step 5: Click Save Map

And re-deploy the updated map to the robot.

Step 6: Have the Robot Execute an Auto-Charging Task Again

Verify whether the issue is resolved.

Recommended Parameter Values

Q: Customer Inquiry

My logistics robot keeps rocking back and forth in place at locations where it needs to turn around, but it just can’t make the turn and gets stuck there. What’s going on?

Problem Symptoms

• The robot repeatedly moves forward and backward at the turn-around location, cycling endlessly

• It remains at the same position for an extended period, unable to complete the turn-around action, affecting subsequent tasks

Root Cause Analysis

This is like preparing to make a U-turn in a spacious parking lot, but there’s a “Do Not Enter” line painted on the ground. Even though you clearly have enough space to make the turn in one go, you hesitate because of that line and can only rock back and forth repeatedly to test the situation. The customer has set a virtual wall on the map in the App. After detecting this virtual wall, the robot assumes its body is too long and the turn-around space is insufficient, so it keeps testing back and forth, afraid to complete the turn.

Solution

Step 1: Open the Robot’s App

Enter the “Map Management” or “Map Editing” interface.

Step 2: Locate the Turn-Around Area Where the Robot Is Stuck

Check if there is a virtual wall marker near that position.

Step 3: Confirm That the Virtual Wall Was Manually Added Previously and That the Area Is Currently Permitted for Passage in the Actual Environment

Step 4: Select the Virtual Wall Marker and Delete It

Step 5: Observe the Robot Re-Executing the Turn-Around Action at That Location

Confirm normal operation is restored.

Recommended Parameter Values

Q: Customer Inquiry

My inspection robot stops or takes a long detour when it reaches narrow passages (such as narrow corridors or narrow doors). It could pass through normally before. What’s going on?

Problem Symptoms

• The robot stops at the entrance of narrow passages, indicating restricted passage

• The robot abandons the narrow passage route and automatically reroutes to select a longer path

Root Cause Analysis

This is like walking through a narrow alley with a large backpack on your back, while a mirror behind you keeps reminding you “there’s something behind you, be careful not to hit the wall,” making you afraid to move forward. After the robot has a box mounted on its rear, the LiDAR’s scanning range originally only masked the rear 120 degrees, and the box happens to fall within the remaining scanning area. The LiDAR keeps detecting the box behind it, mistakenly thinking it is an obstacle on both sides of the passage, and judges that the passage width is insufficient, so it dares not pass through the narrow passage.

Solution

Step 1: Confirm Whether There Is a Newly Added Rear Load

(such as a box, equipment, etc.) when the robot passes through the narrow passage.

Step 2: Contact Technical Support Personnel

Adjust the LiDAR scanning mask angle configuration in the backend.

Step 3: Expand the LiDAR Rear Scanning Mask Angle from 120 Degrees to 180 Degrees

So that the LiDAR no longer detects the area of the rear box.

Step 4: Save the Parameter Configuration and Restart the Robot

To activate the new LiDAR configuration.

Step 5: Have the Robot Pass Through the Narrow Passage Again

Observe whether it can pass through normally.

Step 6: If There Are Still Anomalies

Check whether the actual width of the narrow passage meets the robot’s minimum passage requirements.

Recommended Parameter Values

Q: Customer Inquiry

My robot always fails when passing through relatively narrow doors, but if I set a temporary point in front of the door to align its body first, it can pass through. Is there a way to make it go through directly on its own?

Problem Symptoms

• The robot gets stuck or reports a collision when passing through narrow doors

• After setting a temporary point in front of the door to align the body, it can pass through normally

Root Cause Analysis

It’s like a person passing through a narrow door—if you walk at an angle, your shoulder easily hits the door frame; but if you stand straight first, align yourself with the center of the door, and then walk through, it goes smoothly.

When the robot’s “safety distance” (inflation layer) is set relatively small, it will try to pass close to the edge of the door. Combined with not adjusting its angle in advance when passing through the door, the body easily rubs against the door frame, causing it to fail. Setting a temporary point in front of the door is equivalent to having the robot “position itself properly and align to the center” first, so it naturally passes through.

Solution

Step 1: Enter the Parameter Configuration Interface

Find the “Inflation Layer Radius” setting item.

Step 2: Appropriately Increase the Inflation Layer Radius Value

(You can think of it as putting a “thicker coat” on the robot, making it more inclined to walk toward the center.)

Step 3: Simultaneously Set a Pre-Positioned Point in Front of the Door

Have the robot automatically align its body and center on the door before reaching the narrow door.

Step 4: Save the Configuration and Reissue the Task

Observe whether the robot passes through the door smoothly.

Recommended Parameter Values

Q: Customer Inquiry

I’m using the remote controller to operate my inspection robot, but the robot doesn’t move. Is the remote controller broken?

Problem Symptoms

• The robot does not move after moving the joystick

• The remote controller indicator light is normal, but the robot has no power

Root Cause Analysis

It’s like driving an automatic car—you only turned the steering wheel but didn’t step on the accelerator, so the car won’t move forward. The joystick on the remote controller only controls the robot’s direction of travel, while the “throttle” that actually makes the robot move is the throttle wheel on the remote controller. If you only move the joystick without turning the throttle wheel, it’s like only turning the steering wheel without giving gas—the robot naturally stays still in place.

Solution

Step 1: Confirm the Remote Controller Is Powered On and the Indicator Light Is Normal

Step 2: Confirm the Robot Has Been Switched to “Remote Control Mode”

Step 3: During Operation, First Use Your Finger to Move the Joystick to Control Direction (Equivalent to Turning the Steering Wheel)

Step 4: Simultaneously Use Another Finger to Turn the Throttle Wheel to Provide Power (Equivalent to Stepping on the Accelerator)

Step 5: The Robot Will Then Move in the Direction You Specified

Recommended Parameter Values

Q: Customer Inquiry

I noticed that the LiDAR doesn’t seem to be running, and I can’t see any LiDAR data in the system. What’s going on?

Problem Symptoms

• The LiDAR status shows abnormal or offline

• The perception display has no LiDAR data updates

Root Cause Analysis

It’s like the Ethernet cable of your home WiFi router getting loose—your phone can’t connect to the internet. The LiDAR’s data is transmitted to the system via an Ethernet cable. If the network cable connector is loose or has poor contact, the connection between the LiDAR and the host is “broken,” and the system cannot receive data. It looks as if the LiDAR is not running.

Solution

Step 1: First Confirm Whether the LiDAR’s Power Indicator Light Is On Normally

Step 2: Check the Network Cable Connection Between the LiDAR and the Host

See if it is loose or pulled.

Step 3: Unplug and Reinsert Both Ends of the Network Cable Once

Ensure it is firmly inserted and you hear a “click” sound.

Step 4: Wait Approximately 30 Seconds

Check whether the LiDAR status in the system has returned to normal.

Step 5: If It Still Has Not Recovered

Check whether the router or switch ports in between are also firmly inserted.

Recommended Parameter Values

Q: Customer Inquiry

“Our farm robot runs fine during straight-line operations, but when it reaches the end of a field and needs to turn around, it suddenly brakes to a stop, and the App doesn’t show a clear error either. We’ve drawn virtual walls in some areas of the field to keep the robot out, but the robot stops during turns even though it clearly hasn’t reached the virtual wall area yet. Why does this happen?”

Problem Symptoms

• Normal operation during straight-line segments; sudden braking to a stop when turning

• App shows no clear error, or only displays a vague message such as “path planning failed”

• The stop position is often near a virtual wall, even though there appears to be some distance remaining

Root Cause Analysis

This issue is usually caused by the inflation radius being set too small for the turning arc.

Robot turns require more space than straight-line travel. When the robot turns, it follows an arc and the body shifts outward. There is a “safety bubble” (inflation radius) around the robot. If this bubble is set too small, the robot will encroach upon the virtual wall boundary as soon as it turns, causing it to stop in place out of caution. The larger the turn angle, the larger the required turning arc radius, and the more severe this issue becomes.

Solution

Step 1: Contact Technical Personnel to Adjust the Robot’s Safety Distance

• Have technical personnel appropriately increase the safety buffer distance (inflation radius) in the navigation system

• It is recommended to increase the minimum safety distance between the robot and obstacles/virtual walls from the default 0.15 m to 0.4–0.6 m

• Simultaneously increase the costmap inflation radius to 0.6–1.0 m

Step 2: Adjust Obstacle Sensitivity Accordingly

• Have technical personnel appropriately reduce the robot’s “sensitivity” to virtual walls

• Reduce the cost decay coefficient from the default value to 3.0–5.0, making the safety buffer zone transition more gradual

Step 3: Restart Navigation and Verify

• Restart the navigation program after parameter modification

• Have the robot perform the turn action that previously caused it to stop, and confirm it can complete the turn smoothly

• Observe the actual distance between the robot and the virtual wall to ensure adequate safety margin remains

Recommended Parameter Values

Note: The above parameters are not “the larger, the better.” Excessively large safety distances will make the robot overly conservative and may prevent it from passing through narrow areas. Farmland scenarios are typically spacious, so these values can be appropriately relaxed.

Q: Customer Inquiry

“Our robot has encountered two issues during path planning: The first issue is that path planning clearly shows as successful, and the planned path is visible on the interface, but the robot simply doesn’t move and stays put. The second issue is that if the first step’s task execution fails, I set a new waypoint to have the robot continue, but I find that the old path planned in the first step is still displayed on the screen, and the newly set path doesn’t seem to take effect. What is causing this?”
Problem Symptoms

• Path planning shows as successful, and the planned route is visible on the interface, but the robot remains stationary and does not move.

• After resetting new waypoints, the old path remains displayed on the screen, and the new path does not take effect.

Root Cause Analysis

This issue is usually caused by the robot still being in remote control mode and not having switched to navigation mode.

Think of it this way: the robot has multiple “operating modes,” like a car having both manual and automatic transmission. If you previously manually operated the robot using a remote controller (remote control mode) and forgot to switch to automatic navigation mode afterward, then even if the system has planned a route, the robot will only “look” but not “act” — because the system assumes you still want to control it manually.

Similarly, because the mode was not switched correctly, the previously planned historical route was not cleared, so the old path remains displayed on the screen.

Common triggering scenarios:

• Incorrect operation when switching from remote control mode to navigation mode

• Mode did not automatically switch to navigation after system startup

• Mode confusion after emergency stop recovery

Solution

Step 1: Confirm Current Operating Mode

Check the position of the SWA toggle switch on the remote controller to confirm the current mode.

Step 2: Switch to Navigation Mode

Move the SWA toggle switch on the remote controller downward (downward position) to switch to navigation mode. SWA toggle switch upward = remote control mode; downward = navigation mode.

Step 3: Cancel the Old Task

Before resetting new waypoints, first cancel the currently executing task to clear historical path information.

Step 4: Verify Successful Switch

Send a test navigation target point and observe whether the robot begins moving along the planned path. If the robot moves normally, the mode switch was successful.

Step 5: Establish an Operation Checklist

Before starting each navigation task, confirm:

Emergency stop button is released

Remote controller SWA toggle switch is in the downward position (navigation mode)

Localization status is normal

Robot responds to navigation commands

Recommended Parameter Values

Q: Customer Inquiry

“The hybrid robot we use in our workshop, during task execution navigation, reaches a position requiring a large-angle turn and starts behaving abnormally — it rotates left and right back and forth, as if it doesn’t know which direction to go. After rotating like this for a while, the robot comes to a complete stop and doesn’t move at all. But when we check the App on our phone, the navigation task is still shown as in progress — it doesn’t report completion or failure, just stays stuck in that state. This issue repeatedly occurs at large turn positions and seriously affects our production efficiency. What is the cause? Is there a solution?”

Problem Symptoms

• The robot rotates left and right back and forth at large-angle turn positions, swinging indecisively.

• After rotating for a period, the robot comes to a complete stop, and the wheels no longer turn.

• The App shows the navigation task is still in progress — neither completing nor reporting an error, remaining stuck.

Root Cause Analysis

This issue is usually caused by the recorded path having a turn that is too sharp.

If the robot encountered an excessively large angle or too high a speed while learning a route at a certain turn, then when the robot runs autonomously, it will become unable to determine the correct heading at this sharp turn — it tries to adjust both position and direction simultaneously, but the two actions interfere with each other, resulting in left-right swaying, increasingly chaotic rotation, and eventually stopping altogether. However, the system doesn’t realize there is a problem, so the App keeps showing “in progress.”

Common triggering scenarios:

• Sharp turns or large-angle turns exist in the recorded path

• Few localization references near the turn (e.g., open area)

• The recorded path speed was too fast during the turn or the robot did not decelerate in advance

Solution

Recommended Solution: Re-record a Path with Smoother Turns

Step 1: Enter Path Recording Mode

Enter the path recording function through the App to prepare for re-recording the turn section.

Step 2: Increase Turn Radius

Aim for a larger arc and avoid sharp turns:

• Start steering early; don’t wait until the turn point to make abrupt control inputs

• Maintain uniform, steady operation throughout the turn

• Gradually accelerate only after completing the turn

Step 3: Ensure Dense Waypoints

Path recording in turn areas should be denser than on straight sections. Reducing travel speed will automatically increase waypoint density.

Step 4: Verify Path Quality

After recording is complete, have the robot run a trial pass first, focusing on observing whether the turn is smooth and whether left-right swaying occurs. If problems are found, re-record that section.

Recommended Parameter Values

Q: Customer Inquiry

“Our inspection robot keeps spinning in place after starting navigation during task execution. It simply cannot move forward, as if something is blocking it. However, there are clearly no obstacles around us, and the area is wide open. What is causing this? Could it be that the camera angle is not properly adjusted?”

Problem Symptoms

‍

• After starting navigation, the robot only rotates in place and cannot move forward, even though the path ahead is completely clear.

• The lower half of the camera image is largely occupied by the ground, and the horizon line is positioned high, indicating that the camera is tilted too far downward.

Root Cause Analysis

This issue is usually caused by the front camera being angled too far downward.

Think of it this way: the camera is the robot’s “eyes.” It should be looking straight ahead to see the path. But if the “eyes” are looking down too much, the ground directly in front will be perceived as a “wall” or “obstacle.” When the robot sees a “wall ahead,” it won’t dare to move forward and can only spin in place trying to find a way around.

Common triggering scenarios:

• The camera was newly installed or replaced without calibrating its angle

• The camera mount became loose or shifted during transportation or handling

• Camera parameters were reset after a software upgrade

Solution

Step 1: Verify Current Camera Parameters

Contact technical personnel to check the pitch parameter value corresponding to the camera model in the navigation configuration file, and record the current value.

Step 2: Adjust Camera Pitch Angle

Based on the actual situation, appropriately increase the pitch value (tilt the camera upward). For example: changing the pitch value from -0.35 to -0.30 is equivalent to raising the camera angle by approximately 3 degrees. It is recommended to adjust in increments of 0.05–0.1 radians (approximately 3°–6°).

Step 3: Save and Restart

Save the modified parameters and restart the robot control system for the settings to take effect.

Step 4: On-Site Verification

Start the navigation task and observe whether the robot can follow the path normally. Simultaneously check the camera image to ensure the ground occupies an appropriate proportion and the forward field of view is clearly visible.

Recommended Parameter Values

Q: Customer Inquiry

“Our logistics robot, in navigation mode — I selected a map from the navigation file list, but when the robot actually runs, I noticed it’s running a completely different map from the one I selected! On the interface, I selected the map for Warehouse A, but the robot appears to be running using the map for Warehouse B. I’ve double-checked multiple times that the selected filename is correct. This issue has made us afraid to let the robot run autonomously. Could you please help identify what’s going wrong?”

Problem Symptoms

• Warehouse A map was explicitly selected in the interface, but the robot actually runs using Warehouse B map, with localization behavior and path planning completely inconsistent with the selected map.

• The issue persists after reselecting the map file multiple times; the selection operation appears to have no effect.

Root Cause Analysis

This issue is usually caused by modifying the wrong configuration file.

When the robot is running, it needs to load map data, which is specified by configuration files. If multiple similar but different map files exist on-site (e.g., different floors, different areas, different time versions), it is easy to get them mixed up — you think you are modifying the configuration for Warehouse A, but you are actually modifying the configuration for Warehouse B.

Common confusing scenarios:

• Map files with the same name but different contents exist in multiple folders

• A backup file was mistakenly edited during modification; the main file was not changed

• The map selection interface list is out of sync with the underlying configuration actually loaded

• Lack of unified management during multi-person collaborative maintenance

Solution

Step 1: Confirm You Are Modifying the Correct Configuration File

Do not rely solely on the filename; confirm that the configuration file being modified is indeed the one the robot actually loads. Contact technical personnel to verify the map path currently pointed to by the navigation program.

Step 2: Standardize Map File Management

• Establish clear map file naming conventions to avoid files with the same name appearing in different locations.

• Delete or archive expired and obsolete map files to reduce the chance of confusion.

• Maintain modification records noting which file was modified and what content was changed.

Step 3: Check Whether Supporting Files Match

Map usage depends not only on the map file itself but also on supporting files such as waypoints and topology files. Ensure these supporting files correspond one-to-one with the map.

Step 4: Restart System After Modification

After modifying the configuration, restart the robot control system for the new map configuration to take effect.

Step 5: Verification and Confirmation

Restart navigation and observe whether the robot’s localization position and path planning are consistent with the selected map. You can check localization accuracy at several landmark positions (e.g., wall corners, corridor entrances).

Recommended Parameter Values

Q: Customer Inquiry

“Our Ackermann robot gives us a headache every time it auto-charges. The charging station is right there in front of it, but the robot keeps moving forward, backward, forward, backward from about a meter away, sometimes struggling for one or two minutes to align properly. And during the adjustment, the side corner of the front bumper directly hits the edge of the charging station. The charging station is placed in the middle of the aisle with shelves on both sides. Is this Ackermann chassis type just particularly difficult to align?”

Problem Symptoms

• After reaching the vicinity of the charging station, repeatedly moves forward and backward, taking a long time to align

• Each alignment takes 30 seconds to several minutes; auto-charging efficiency is very low

• During reverse adjustments, the front bumper corner easily grazes the side of the charging station

• Impact force is usually minor, but leaves scratches or knocks the charging station out of position

Root Cause Analysis

Cause 1: Inherent Limitations of Ackermann Chassis

Ackermann robots (like cars) cannot rotate in place. Every position adjustment must follow an arc. Even a small position correction causes a significant change in body orientation, making precise alignment particularly difficult.

Cause 2: Improper Charging Station Placement

The charging station is placed in the middle of the aisle, with obstacles (shelves/walls) on the sides and behind the robot, forcing the robot to drive forward and then reverse to align. Combined with the inability of Ackermann robots to rotate in place, adjustment space is limited, resulting in repeated “sawing back and forth.”

Cause 3: Front Bumper Corner in Sensor Blind Spot

The front-most corner of the front bumper is precisely in an area that sensors cannot detect. When the robot approaches the charging station at an angle, the corner contacts the charging station first while the robot remains “unaware.”

Solution

Step 1: Relax Alignment Accuracy

Contact technical personnel to appropriately relax the allowed tolerance at the target point: position tolerance from 5 cm to approximately 20 cm, and angular tolerance from approximately 3 degrees to approximately 8–9 degrees. For Ackermann chassis types, disable the in-place rotation alignment function upon reaching the target. Restart navigation and test; ideal alignment time should be within 10–20 seconds.

Step 2: Place Charging Station Against a Wall

Move the charging station in front of a wall or fixed immovable object, with the station backed against the wall. This way, when the robot reverses to align, the space behind is open, and the algorithm will choose a safer reversing strategy, significantly reducing the risk of corner collision. This is the most recommended solution.

Step 3: Set Virtual Walls When Wall Placement Is Not Possible

If the charging station cannot be placed against a wall, contact technical personnel to draw virtual walls behind and on both sides of the charging station on the map. This effectively creates an “against the wall” scenario, letting the algorithm know the rear path is blocked and preventing the robot from pushing forward.

Step 4: Expand Adjustment Space

Clear obstacles to the sides and rear of the charging station, ensuring at least 1.5× vehicle width of space on the sides and at least 2× vehicle length of space to the rear, providing the robot with sufficient room for adjustment.

Recommended Parameter Values

Q: Customer Inquiry

“After our robot reached a new area, I tapped the navigation target point on the App. The robot showed it received the command, the status looked normal, but it just stood there completely motionless. There was no error on the App. Later, technical personnel said it was a map issue—the wall ghosting in this area was very severe. What exactly is the cause, and how can we thoroughly resolve it?”

Problem Symptoms

• Navigation command successfully sent from App, status displays “Normal” or “Navigating”

• Robot remains completely stationary with no movement whatsoever

• No error or warning on the App

• Upon inspecting the map, walls show “ghosting”—multiple overlapping contour lines for the same wall

Root Cause Analysis

The root cause is poor map quality, causing the robot to be “lost.”

The robot relies on LiDAR scanning of the surrounding environment and comparing it with the map to determine its own position. When the map has issues such as wall ghosting, blurring, or misalignment, the robot cannot match accurately, and localization drifts—it thinks it is at a wrong position, possibly even “believing” it is inside a wall or obstacle.

At this point, the robot’s safety protection mechanism is triggered: “My position is unsafe; I cannot move.” So although the App shows everything is normal (because the App can only see communication and command status, not localization quality), the robot is actually refusing to move because it is “afraid of hitting a wall.”

How does map “ghosting” occur?

• Robot moved too fast during mapping

• Rotated too sharply during mapping

• Drastic lighting changes in corridors (e.g., window areas)

• Environment changed after long-term operation

Solution

Core Solution: Rescan the Map

Step 1: Prepare Mapping Environment

• Remove temporary obstacles on the ground (boxes, cables, etc.)

• Ensure all passages are clear and doors are in normal state

• Keep the environment stable during mapping; avoid frequent pedestrian traffic

• Plan walking routes covering all areas in advance

Step 2: Save and Use New Map

• Save the new map file after mapping is complete

• Configure the new map into the navigation system

• Restart navigation and load the new map

Step 3: Verification

• Send navigation tasks multiple times from different locations

• Confirm the robot can move and localize normally

Recommended Parameter Values

Q: Customer Inquiry

“Our inspection robot at the site has recently developed a strange problem—when told to go straight forward, it simply refuses, always detouring around or just stopping there motionless, as if something is blocking the way ahead. But when we went over to check, there was clearly nothing on the ground; it was wide open! It had always worked fine before. Then a few days ago, we had on-site personnel adjust the camera angle on the robot, and ever since then, it’s been like this. Can you help us figure out what’s going on? Did we break something?”

Problem Symptoms

• Robot cannot move straight forward; the path ahead is clearly open and unobstructed

• Robot frequently detours, hesitates, or spins in place

• Problem began after someone adjusted the camera angle

Root Cause Analysis

This issue is related to the camera angle. Depth cameras have a “pitch up / pitch down” angle setting that is precisely calibrated at the factory—the camera should look straight ahead and must not see the ground. However, if on-site personnel tilted the camera downward, the lens will “look down” and see the ground, misidentifying the ground as an obstacle. This causes the robot to believe there is something blocking the way ahead and be afraid to move forward.

In simple terms: The camera is pitched too far down and mistakes the ground for an obstacle.

Solution

Locate the Camera: Find the depth camera on the robot, usually on the head or upper front section.

Loosen Fixing Screws: Use a tool to gently loosen the fixing screws on the bracket; do not fully unscrew to prevent the camera from dropping.

Adjust Angle Upward: Tilt the camera upward slightly (make the lens “look up”), adjusting no more than 2–3 degrees each time.

Observe the Effect: Check whether the “obstacle” display in front of the robot disappears on the debug interface.

Tighten Fixing: After the angle is properly adjusted, retighten the screws with moderate force.

Test and Verify: Have the robot walk a straight segment and confirm it can move forward normally.

If the adjustment is substantial, it is recommended to contact technical personnel to perform camera recalibration, ensuring depth data is properly aligned with LiDAR.

Recommended Parameter Values

Q: Customer Inquiry

“We have deployed several FR-MID logistics robots in our workshop. The robot body width is 0.84 m. There is a 1.3 m wide door in the workshop, and the robot needs to turn into it from the side direction. But every time it reaches this doorway, the robot seems particularly clumsy—it always goes through at an angle, scraping both the left and right sides of the body very close to the door frame, and sometimes it just gets stuck there and stops, and the task is interrupted. The door is 1.3 m wide, and the robot is only 0.84 m wide. By all rights there should be plenty of room! Is something wrong with our robot? Can you make it pass through this doorway more intelligently?”

Problem Symptoms

• Robot has particular difficulty turning into a 1.3 m wide doorway from the side

• Robot body goes through at an angle with both sides very close to the door frame

• Frequently gets stuck at the doorway and stops, interrupting the task

• Door width is 1.3 m, robot width is 0.84 m; theoretically there is sufficient space

Root Cause Analysis

This issue is not because the robot is “clumsy,” but because its “safety distance” is set too small.

When navigating, the robot automatically leaves a “safety buffer zone” around obstacles (such as door frames). The size of this buffer zone is called the inflation radius. If the inflation radius is set too small, the robot will believe it can travel right alongside obstacles, thus choosing a “shortcut” path that goes through the door at an angle. However, passing through a narrow door at an angle requires extremely precise control; the slightest deviation will cause the robot to scrape the door frame.

If the inflation radius is increased, the robot will consider “getting too close to the door frame is unsafe” and choose to first adjust its orientation at the doorway, then drive straight through the door opening after facing it squarely. Although this appears to involve more movements, the success rate is actually higher.

Solution

Contact Technical Personnel to Adjust Parameters: The obstacle inflation radius parameter in the navigation configuration needs to be modified; this operation is recommended to be performed by technical personnel.

Provide Reference Values: Inform technical personnel of the current door width (1.3 m) and robot width (0.84 m), and recommend increasing the inflation radius from the default 0.3–0.4 m to 0.5–0.6 m.

Verify the Effect: After adjustment, test the robot’s door-passing behavior. You should observe the robot proactively adjusting its orientation at the doorway and then driving straight through after facing the door opening squarely.

Balance Consideration: If the inflation radius is set too large, the robot may become overly conservative in other areas and take unnecessarily long detours. If this occurs, it can be slightly reduced.

Recommended Parameter Values

Calculation Formula Reference: Inflation radius ≥ (door width − robot width) ÷ 2 + control error margin ≈ 0.23 + 0.1 = above 0.33 m; recommended actual setting should be somewhat larger.

Q: Customer Inquiry

“Our inspection robot backend system has recently been failing every time it calls the operations robot’s API, returning connection timeout or service not found errors. I opened the map interface and found that there is no LiDAR point cloud data on the map at all—the green scan lines that used to be there are gone. I used a laptop on-site to ping the LiDAR’s IP address, and it was unreachable; even the router’s IP was unreachable. But the equipment and cables all appear to be properly connected—no one has touched them. Later we remembered that previously, in order to enable the robot to access between two networks, we had the network administrator help configure network bridging. Could this be related? We’re completely confused right now. Please help us.”

Problem Symptoms

• Backend robot API calls fail with connection timeout errors

• LiDAR scan data completely disappears from the map interface

• Cannot ping LiDAR IP address; cannot ping router/gateway IP either

• Problem appeared after configuring network bridging

Root Cause Analysis

The root cause of this problem is the network bridging configuration.

The robot system contains multiple devices (IPC, LiDAR, router, etc.) that originally resided on the same local area network and communicated with each other via fixed IP addresses. Configuring network bridging effectively disrupted the original network structure—the IP addresses of the various devices may no longer be on the same subnet, and they can no longer “find” each other.

Specifically:

• The LiDAR uses a fixed IP address to communicate with the IPC; after the network changed, it became “disconnected”

• The IPC cannot connect to the LiDAR, so there is no scan data on the map

• The network path between the backend and the robot is also broken, so API calls fail

• Unreachable ping indicates the underlying network connection is already broken

Solution

Confirm Network Changes: Recall what bridging configurations the network administrator made at the time and record the configuration details.

Contact Network Administrator for Assistance: This is a network-level issue; network administrator involvement is required. Provide the following checklist to the network administrator:

– Check whether the IPC and LiDAR are still on the same subnet

– Check whether the bridge interface IP configuration is correct

– Check whether the routing table has a route to the LiDAR subnet

Simple Troubleshooting: On the IPC, ping the LiDAR’s IP address. If it is still unreachable, the network layer has not yet been restored.

Restart After Network Recovery: After the network administrator fixes the network configuration, restart the robot system and LiDAR driver.

Verify Recovery: Confirm that the map interface can normally display LiDAR data and that API calls return to normal.

Important Reminder: The robot system’s network configuration is relatively sensitive. If network adjustments are needed in the future, it is recommended to first contact our technical support to assess the impact. Do not configure bridging, VLAN, or other network changes on your own.

Recommended Parameter Values