Question 1

What problems does ROS2's switch from ROSMaster to DDS middleware solve that ROS1 faced? Explain the peer-to-peer discovery mechanism and QoS policies in DDS.

Accepted Answer

ROS1 ROSMaster problems: (1) Single point of failure - if roscore dies, the entire system crashes; (2) No real-time guarantees - message delivery is non-deterministic; (3) No built-in security - every node on the network is trusted implicitly; (4) Multi-robot coordination is complex - requires bridges between namespaces. DDS solutions: (1) Peer-to-peer discovery via SPDP (Simple Participant Discovery Protocol) and SEDP (Simple Endpoint Discovery Protocol) - no intermediate server needed; (2) QoS policies: RELIABILITY (BEST_EFFORT vs. RELIABLE), DURABILITY (VOLATILE vs. TRANSIENT_LOCAL), DEADLINE (how long until a message must arrive), LIVELINESS (is the node still alive), HISTORY (how many messages to keep); (3) DDS Security plugins for authentication and encryption. Common vendors: FastDDS (eProsima, ROS2 default), CycloneDDS (Eclipse, good performance for embedded). QoS selection: sensor data uses BEST_EFFORT (low latency), command/control uses RELIABLE. Ask whether the candidate has ever debugged DDS network issues - for example, multicast being blocked by switches in a factory environment (requires configuring FASTDDS_DEFAULT_PROFILES or switching to unicast). Strong candidates know about ROS_DOMAIN_ID for isolating multiple robots on the same network and how to tune rmw_cyclonedds to reduce latency. Ask about experience with ros2 doctor and ros2 daemon for troubleshooting discovery issues.

Question 2

In ROS2, when do you use Publisher/Subscriber, when Service/Client, and when Action? Give real examples with a warehouse robot.

Accepted Answer

Three communication patterns and when to use each: (1) Publisher/Subscriber - continuous data stream, no response needed, fire-and-forget: sensor data (LiDAR scan, camera frame, IMU), odometry, robot state. Warehouse example: publish /scan from LiDAR at 10Hz for Nav2 costmap; (2) Service/Client - one-time request/response, synchronous, short duration (< 1 second): get robot status, set parameter, trigger one-shot action. Warehouse example: /get_map service so a client can request the current map from the map server; (3) Action - long-running task with feedback and the ability to cancel: navigating to a destination, arm manipulation sequence, charging. Warehouse example: NavigateToPose action - goal (target coordinates), feedback (current position, ETA), result (success/failure), cancellable when an obstacle appears. Rule of thumb: duration > 1s + needs feedback + can be preempted -> use Action. Ask about experience implementing Action servers/clients from scratch, not just using Nav2 off the shelf. Candidates who truly understand will explain the Action lifecycle: ACCEPTED -> EXECUTING -> SUCCEEDED/ABORTED/CANCELED. Ask further about handling goal preemption (robot heading to A, receives new goal to go to B). Bonus points for knowing Managed Nodes (LifecycleNode) in ROS2.

Question 3

GHN's sorting center in Binh Duong needs to automate goods movement. Would you choose AMR or AGV and why? Analyze the specific technical and operational factors.

Accepted Answer

Comparative analysis: AGV (Automated Guided Vehicle): (1) Navigation: fixed path - magnetic tape, QR codes, reflectors on the floor; (2) Pros: lower cost, simple, easier to maintain locally, suited for fixed routes; (3) Cons: inflexible layout, rerouting is time-consuming, cannot dynamically avoid obstacles; (4) Best for: fixed production lines, narrow corridors. AMR (Autonomous Mobile Robot): (1) Navigation: SLAM + dynamic path planning (Nav2), self-maps environment; (2) Pros: flexible layout, self-navigates around people/goods obstacles in real time, easy to add/remove stops; (3) Cons: higher cost (~$15,000-40,000/unit UR-style), requires careful commissioning, dirty LiDAR causes failures; (4) Best for: logistics sorting with changing layouts. Conclusion for GHN Binh Duong: AMR is the better choice because sorting centers have seasonally changing layouts, have workers moving around that need to be avoided, and require flexible scaling. Considerations: floor flatness (AMR is sensitive to flooring), Wi-Fi coverage adequacy, and budget. This is a practical case study question. Look for candidates with a systems mindset: not just tech specs but also TCO (Total Cost of Ownership), uptime SLA (GHN has delivery SLAs), and local support/maintenance (very important in Vietnam where vendor support is slow). Ask further about fleet management software, charging strategy (opportunity charging vs. full charging), and integration with WMS (Warehouse Management System).

Question 4

Compare LiDAR-SLAM (Cartographer) and Visual SLAM (ORB-SLAM3) on accuracy, cost, and operating conditions. Which would you choose for a warehouse in Vietnam and why?

Accepted Answer

LiDAR-SLAM (Cartographer - Google): (1) Accuracy: 2-5cm in structured environments, consistent over time; (2) Cost: 2D LiDAR (RPLIDAR) $150-500, 3D LiDAR (Velodyne, Ouster) $2,000-15,000; (3) Operating conditions: unaffected by lighting, stable in light dust, struggles in featureless environments (long corridors), poor performance outdoors in rain; (4) Map: 2D occupancy grid or 3D pointcloud; (5) Compute: lightweight, runs on Jetson Nano. Visual SLAM (ORB-SLAM3): (1) Accuracy: 1-3cm under ideal conditions but drifts without loop closure; (2) Cost: stereo camera $100-300, fisheye camera even cheaper; (3) Operating conditions: sensitive to changing light, texture-poor environments (plain white walls), motion blur, dust on lens; (4) Map: sparse 3D map (keypoints) or dense with RGBD; (5) Compute: heavier, requires GPU or powerful ARM. Conclusion for Vietnamese warehouse: LiDAR-SLAM (Cartographer) is superior because: warehouse lighting changes (loading dock doors open/close), dust is common in warehouses, high reliability is more important than ultimate accuracy, 2D LiDAR cost is appropriate for Vietnamese SMEs. Strong candidates will propose a hybrid approach: LiDAR-SLAM for localization and navigation, camera for object detection and obstacle avoidance. Ask about specific Cartographer experience: SLAM algorithm (submaps, loop closure), parameter tuning (min_range, max_range), and how to handle dynamic obstacles in the warehouse (moving people).

Question 5

Explain the Nav2 architecture for autonomous warehouse navigation: how do AMCL, Global Costmap, Local Costmap, and Behavior Tree work together?

Accepted Answer

Nav2 architecture - full pipeline: (1) AMCL (Adaptive Monte Carlo Localization): particle filter-based localization, uses LiDAR scan matching against known map to estimate pose; particle count self-adjusts based on uncertainty (adaptive). Input: /scan + /map, Output: /amcl_pose; (2) Global Costmap: static map + inflation zones around obstacles, used for global path planning (NavFn or Smac Planner). Resolution typically 5-10cm. Layers: static layer (from map server), obstacle layer, inflation layer; (3) Local Costmap: small window around robot (typically 3x3m to 5x5m), updated in real time from sensors, used for local path planning and obstacle avoidance. Layers: obstacle layer (LiDAR), voxel layer (3D). Controllers: DWB (Dynamic Window Approach B) or Regulated Pure Pursuit; (4) Behavior Tree (Nav2 BT): orchestrates the entire navigation - ComputePathToPose -> FollowPath -> if stuck: ClearCostmaps -> Spin -> Wait -> Replanning. BT allows defining complex recovery behaviors as tree structures; (5) Lifecycle management: every Nav2 node is a LifecycleNode - configure -> activate -> deactivate -> cleanup, enabling safe system startup/shutdown. Ask about real Nav2 parameter tuning experience: inflation_radius (too small and the robot hits walls, too large and it cannot pass narrow corridors), cost_scaling_factor, controller frequency. Strong candidates know how to write custom BT nodes for specific use cases (e.g., docking at a charging station). Ask about nav2_bringup and how to modify the default behavior tree XML.

Question 6

You need to integrate YOLOv11 with a pick-and-place robot for bin picking mixed electronic components. Describe the pipeline from detection to execution, handling overlap and occlusion cases.

Accepted Answer

Full pipeline: (1) Perception: RGB-D camera (Intel RealSense D435 or ZED 2) provides color image + depth map. YOLOv11 instance segmentation (not just bounding box) to detect each component and its mask; (2) 3D pose estimation: project bounding box/mask onto depth map, compute 3D centroid in camera frame. Use PCA on object pointcloud to estimate orientation (grasp angle); (3) Grasp planning: filter objects with confidence > threshold, prioritize unoccluded objects (visible area/total area > 0.7). Compute grasp point avoiding collision with bin walls and neighboring objects. GraspNet-1Billion or geometric heuristics; (4) Coordinate transform: camera to robot base frame via hand-eye calibration matrix. Use tf2 in ROS2; (5) Motion planning: MoveIt2 with collision objects from depth map. Pre-grasp pose -> approach -> grasp -> retreat; (6) Handling overlap/occlusion: select topmost object (highest centroid Z); re-detect after each pick to update scene; implement retry logic on grasp failure (force sensor feedback). Evaluation: target grasp success rate > 90% for single-SKU, > 80% for mixed bin. Ask about training data strategy - electronic components have few public datasets, requiring synthetic data generation (NVIDIA Isaac Sim, BlenderProc) and domain randomization. Strong candidates know the difference between instance segmentation and semantic segmentation and why instance segmentation is critical for bin picking (each object must be individually distinguished). Ask about force/torque sensors to detect grasp success and handle slippage.

Question 7

You are tasked with deploying a Universal Robots UR10e cobot working alongside workers in an electronics factory in Dong Nai. Walk through the compliance process for ISO 10218 and ISO/TS 15066, and the practical challenges in Vietnam.

Accepted Answer

Full compliance process: (1) ISO 10218-1 (robot manufacturer) + ISO 10218-2 (integrator/system integrator) - clearly delineated responsibilities. The UR10e is already ISO 10218-1 certified, but the integrator (you) must comply with ISO 10218-2 for the entire workcell; (2) ISO/TS 15066 - 4 collaborative modes: Hand-Guiding (worker physically guides robot), Safety-Rated Monitored Stop (robot stops when person enters zone), Speed and Separation Monitoring (robot slows when person approaches, using Safety laser scanner such as SICK microScan3), Power and Force Limiting - PFL (robot self-limits force on contact - the mode UR10e commonly uses, must be validated against biomechanical limits); (3) Risk Assessment per ISO 12100: identify hazards (pinch point, crush, entanglement), estimate risk (S×E×P matrix), reduce risk per hierarchy (elimination -> safeguarding -> PPE); (4) PFL Validation: measure actual contact force and pressure using force measurement device (Pilz PMC), compare against ISO/TS 15066 Annex A biomechanical limits (e.g., human chest maximum 140N); (5) Vietnam realities: no dedicated QCVN standard for cobots; FDI factories (Foxconn, Samsung) require CE marking; documentation must be available in Vietnamese for workers; workers need training on collaborative workspace awareness; local safety engineers are often unfamiliar with ISO/TS 15066. Ask about experience with UR Safety Configuration (safety planes, joint limits, tool speed limits in Universal Robots Polyscope) and how to integrate a safety laser scanner into the safety circuit (safety PLC). Strong candidates know that 'collaborative' cobot does not mean inherently safe - risk assessment is still required, and in many cases guarding is still needed at high speeds or heavy payloads.

Question 8

You are fusing LiDAR and IMU with EKF. After 10 minutes of operation, the covariance matrix starts to diverge and the robot loses localization. How do you debug and handle this?

Accepted Answer

Causes of covariance divergence: (1) Process noise (Q matrix) too small - EKF overtrusts the model, insufficient updates from sensors; (2) Measurement noise (R matrix) too small - EKF overtrusts sensors, amplifies noise; (3) IMU bias drift - accelerometer and gyroscope drift with temperature and time (IMU needs warm-up); (4) LiDAR feature-poor environment - long corridors with no distinguishing features (degenerate case); (5) Time synchronization offset - IMU and LiDAR timestamps not synchronized (must be < 0.5ms); (6) Incorrect extrinsic calibration - transform from LiDAR frame to IMU frame is wrong. Debug process: (a) Plot covariance eigenvalues over time to identify which axis is diverging; (b) Inspect raw IMU data for abnormal spikes; (c) Check LiDAR scan quality - sufficient point density; (d) Verify timestamps using ros2 topic hz and ros2 topic delay. Fixes: (1) Tune Q and R matrices using Allan variance analysis for IMU; (2) Implement covariance capping to prevent complete divergence; (3) Implement relocalization trigger when uncertainty exceeds threshold; (4) Hardware fix: use higher-grade IMU (MEMS vs. tactical grade). This question distinguishes candidates with real practical experience from those who only know EKF theory. A strong candidate will immediately ask about the environment (long straight corridors are degenerate for LiDAR) and will know that Allan variance is the standard tool for characterizing IMU noise. Ask further about experience with the robot_localization package (ROS2) and how to configure ekf_node.yaml.