pith. sign in

arxiv: 2604.24242 · v1 · submitted 2026-04-27 · 💻 cs.RO

OpenPodcar2: a robust, ROS2 vehicle for self-driving research

Pith reviewed 2026-05-08 02:55 UTC · model grok-4.3

classification 💻 cs.RO
keywords open source hardwareautonomous vehicleROS2mobility scooterself-drivingnav2SLAMlow-cost platform
0
0 comments X

The pith

OpenPodcar2 turns a mobility scooter into a robust low-cost ROS2 autonomous vehicle for research and deployment.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper presents OpenPodcar2, an open-source platform that modifies an off-the-shelf mobility scooter with electronics, ROS2 software, and the nav2 navigation stack to create a self-driving vehicle. It documents hardware builds, provides simulation, and implements planning and control for driving from current to desired poses while avoiding obstacles. This design allows the vehicle to carry a passenger or load at speeds up to 15 km/h in a compact, safe form that fits in a lab. A reader would care because it offers an affordable way to conduct real-world autonomous driving research without the expense of custom vehicles.

Core claim

OpenPodcar2 is a robust, ROS2-interfaced, low-cost, open source hardware and software autonomous vehicle platform based on an off-the-shelf hard-canopy mobility scooter donor vehicle, extended with electronics and ROS2 interfacing to enable research and potential deployment use cases, providing a balance between real world utility, safety, cost and robustness.

What carries the argument

The common ROS2 interface provided by the OSH R4 mechatronics board integration and Gazebo simulation, combined with the nav2 stack for SLAM and command enactment to drive the vehicle.

If this is right

  • It can transport a human passenger or similar load at speeds up to 15km/h.
  • It supports use as a last-mile autonomous taxi service or to transport delivery containers around a city center.
  • It is small and safe enough to be parked in a standard research lab.
  • It has a total build cost of around 7,000USD from new components, or 2,000USD with a used donor vehicle.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Other researchers could replicate or extend the platform for their own experiments in outdoor navigation.
  • The open-source documentation may encourage similar low-cost adaptations of everyday vehicles for robotics.
  • Testing in varied environments could reveal how well the robustness holds for longer deployments.
  • The platform might serve as a testbed for studying human-robot interaction in passenger transport scenarios.

Load-bearing premise

The hardware modifications, ROS2 integration, and nav2 stack produce a system that is robust enough for both research and potential deployment use cases without major failures in real-world conditions.

What would settle it

A series of real-world tests where the vehicle experiences repeated navigation failures, safety incidents, or hardware breakdowns while attempting to drive around obstacles to a target pose.

Figures

Figures reproduced from arXiv: 2604.24242 by Charles Fox, Chris Waltham, Mark Crampton, Md Umar Ibrahim, Rakshit Soni.

Figure 1
Figure 1. Figure 1: R4 interfaced to drivers and relays on the Mounting Board (left) and used to control OpenPodcar2 view at source ↗
Figure 2
Figure 2. Figure 2: Podcar steer control node for physical podcar, wrapping R4 ROS2 nodes and reading cmd view at source ↗
Figure 3
Figure 3. Figure 3: Successful RTAB SLAM indoor (left) and outdoor (right) 2D occupancy maps view at source ↗
Figure 4
Figure 4. Figure 4: Pedestrian represented by 3D bounding box (yellow) with track history (green) crossing in front of view at source ↗
Figure 5
Figure 5. Figure 5: RTAB SLAM large indoor map with NAV2 Stack, following a successful large loop closure view at source ↗
Figure 6
Figure 6. Figure 6: 3D map of the large indoor environment achieve wider fields of view or higher perception redundancy. The platform therefore supports experimental evaluation of localization, SLAM, planning, control, parking, and human-aware navigation algorithms under real-world conditions. By enabling repeatable testing on an accessible physical system, OpenPodcar2 contributes toward lowering the entry barrier to AV exper… view at source ↗
Figure 7
Figure 7. Figure 7: Real pedestrian crossing experiment with Openpodcar2. view at source ↗
Figure 8
Figure 8. Figure 8: Original motor controller-driver removed from the Donor Vehicle view at source ↗
Figure 9
Figure 9. Figure 9: Original steering column; replaced with laptop stand view at source ↗
Figure 10
Figure 10. Figure 10: Support on axle stands The Donor Vehicle has Ackermann steered geometry. To control this steering, a the Linear Actuator is mounted on the brackets near to the tie rod in the front. Due to mechanical limits, the Linear Actuator is not exactly in the middle of the front axle view at source ↗
Figure 11
Figure 11. Figure 11: Underside view of front wheels’ steering relationship view at source ↗
Figure 12
Figure 12. Figure 12: Steering bracket CAD Install the Linear Actuator on the underside of the vehicle, using the brackets with nuts, bolts and washers for spacing to position its base, as shown in view at source ↗
Figure 13
Figure 13. Figure 13: Steering linear actuator installation Connect wires to the Linear Actuator and run them to the passenger compartment for later connection. Use two people to un-tilt the vehicle and return it to its normal position. Depthcam physical install Lift the Donor Vehicle’s front panel (usually this is done to refill the windscreen washer fluid). Drill a hole in it and bolt on the Depthcam as in view at source ↗
Figure 14
Figure 14. Figure 14: Depth camera installation Wifi Router install Drill holes in the upper rear of the Donor Vehicle, use them with cable ties to mount the Wifi Router to the vehicle exterior as shown in view at source ↗
Figure 15
Figure 15. Figure 15: WiFi Router installation Mounting Board Cut three Acrylic Boards each to 400 mm × 215 mm (with 5 mm thickness). The boards may be cut from a single acrylic (e.g. Perspex brandname) sheet using a handsaw, laser cutter, or an external cutting service. 22 view at source ↗
Figure 16
Figure 16. Figure 16: 2D design of mounting board On one of the Acrylic Boards, arrange the required electronics as shown in view at source ↗
Figure 17
Figure 17. Figure 17: Components position on Mounting Board To form the Mounting Board, stack the three Acrylic Boards vertically using metal bolts as spacers/standoffs at the perimeter holes as shown in view at source ↗
Figure 18
Figure 18. Figure 18: Mounting board, formed from three stacked Acrylic Boards view at source ↗
Figure 19
Figure 19. Figure 19: Forming the GND distributor from one corner’s spacers. view at source ↗
Figure 20
Figure 20. Figure 20: Circuit Breaker connections R4 Bench-test the R4 according to the R4 documentation. Configure the R4 firmware to use the network name and password as the router, using the R4 documentation. Fit the 5-15A (inclusive) fuses in the fuse holders mounted on the R4 as shown in table 1 and view at source ↗
Figure 21
Figure 21. Figure 21: Required fuses for OpenPodcar2 mounted on R4 view at source ↗
Figure 22
Figure 22. Figure 22: Dead man handle (DMH) Mount the R4 DHM Relay on the mounting board using standoffs. Connect the R4 DHM Relay to the R4 relay interface using a 3 pin JST harness carrying input, 5V supply and ground, as shown in table 3 and view at source ↗
Figure 23
Figure 23. Figure 23: R4 DHM Relay DC/DC 24→5V converter Mount the module on the Mounting Board using standoffs. (Note: XT60H is a standard connector type. These yellow plastic connectors have a curved side hosting pin 1 for +ve and a square side hosting pin 2 for -ve; and that -M an -F denote male and female connectors. They can be attached to wires by soldering and heat shrink.) Connect the converter to the R4 power distribu… view at source ↗
Figure 24
Figure 24. Figure 24: DC/DC 24→5V converter DC/DC 24→12V converter Mount the converter on the Mounting Board using bolts. Connect the converter both to and from R4 as in table 5 and view at source ↗
Figure 25
Figure 25. Figure 25: DC/DC (24→12V) DC/DC 24→19V converter Mount the module on the mounting board using bolts. Take input power from the R4 high current 24OUT 1 connector using the XT60H M red and black pair, and route the converter output to the target device using the yellow and black XT60H M pair, as shown in table 6 and Figure ??. Keep cabling short and strain relieved view at source ↗
Figure 26
Figure 26. Figure 26: DHB12 steering motor driver connection with R4 view at source ↗
Figure 27
Figure 27. Figure 27: Linear Actuator connection with R4 32 view at source ↗
Figure 28
Figure 28. Figure 28: OSMC connections view at source ↗
Figure 29
Figure 29. Figure 29: Power Relay OSMC Fan Mount the OSMC Fan on top of the OSMC with standoffs. Power the fan from OSMC’s aux pins in view at source ↗
Figure 30
Figure 30. Figure 30: OSMC Fan connection with OSMC 8-Way Relay Bank Mount the Relay Bank on the mounting board using standoffs. Connect the relay bank logic and coil supply to the R4 eight channel relay interface on RelayPort 1, providing the individual relay control signals and common supply reference. Terminate load wiring at the relay screw terminals and routed to the target circuits according to whether normally open or n… view at source ↗
Figure 31
Figure 31. Figure 31: 8–Way relay bank 35 view at source ↗
Figure 32
Figure 32. Figure 32: Side view view at source ↗
Figure 34
Figure 34. Figure 34: Battery connections 37 view at source ↗
Figure 35
Figure 35. Figure 35: Depthcam level checked with spirit level view at source ↗
Figure 36
Figure 36. Figure 36: Steering angle readings vs Linear actuator voltages across full left and right turns view at source ↗
Figure 37
Figure 37. Figure 37: RTAB 3D Indoor Map in a tight lab space The RTAB-Map package also provides the visual odometry named as RGBD odometry which is deployed in the vehicle to provide the pose information and odom to base_link transform. This has shown reliable results for indoor operations. Moreover, the RTAB-Map SLAM package is used to perform the the mapping and localization which takes the odom to base_link transform as in… view at source ↗
Figure 38
Figure 38. Figure 38: ROS2 RTAB nodes and messages camera mounted in-front of the vehicle, there is need to tweak the Grid/RangeMax, Grid/RangeMin and Grid/RayTracing according to the range of the RGBD camera. The Intel Realsense D435 mounted on the vehicle has range of 10m but offers good accuracy for 5m range. The system checked with both ranges and default is set to 5m. The outputs are the map to base_link transform, and th… view at source ↗
Figure 39
Figure 39. Figure 39: ROS2 nav2 nodes and messages Pedestrian/object detection and tracking The RGBD camera is used for pedestrian detection and tracking as well as for SLAM. An off-the-shelf ROS2- wrapped YOLOv85 is linked to the camera to perform and report pedestrian and vehicle detection and tracking 4known as local planners in ROS1 5https://github.com/Rak-r/yolov8 ros2 OpenPodCarV2.git 52 view at source ↗
Figure 40
Figure 40. Figure 40: ROS2 nodes for pedestrian detection and tracking view at source ↗
Figure 41
Figure 41. Figure 41: Pedestrian detection results in simulation (left) and real-world deployment on the physical Open view at source ↗
Figure 42
Figure 42. Figure 42: Pedestrian masking and navigation during real-world deployment of OpenPodcar2. (Left) masked view at source ↗
Figure 43
Figure 43. Figure 43: ROS2 GZ Bridge node graph with custom nodes setup. view at source ↗
Figure 44
Figure 44. Figure 44: ROS2 NAV2 full stack setup with Gazebo sim. view at source ↗
Figure 45
Figure 45. Figure 45: Simulated world with map in rviz along with PointCloud2 for camera sensor The pod2_navigation package consists all the scripts referenced and modified from the official release [23]. For simulation tests, we have tested the different level of the stack in simple custom world created to monitor how the podcar performs in tight environments. For this, the package also involves custom built maps. nav2 is the… view at source ↗
Figure 46
Figure 46. Figure 46: System Architecture 58 view at source ↗
Figure 47
Figure 47. Figure 47: Top view of mounting board assembly Power systems Battery The donor vehicle’s original lead acid battery is the main 24V power source for the entire OpenPodcar2 system. It supplies energy to the propulsion motor (via the OSMC), steering (via DHB12), computation (R4, laptop) and communication (router). The battery’s negative terminal forms the shared ground reference for all systems. Compared to 12V, a 24V… view at source ↗
Figure 48
Figure 48. Figure 48: Donor motor assembly 63 view at source ↗
read the original abstract

OpenPodcar2 is a robust, ROS2-interfaced, low-cost, open source hardware and software, autonomous vehicle platform based on an off-the-shelf, hard-canopy, mobility scooter donor vehicle. It is a modification of the previous OpenPodcar design, which extends it with robust electronics and ROS2 interfacing, to enable both research and also potential deployment use cases. The platform consists of (a) hardware components: documented as a bill of materials and build instructions; (b) integration to the general purpose OSH R4 mechatronics board and a Gazebo simulation of the vehicle, both presenting a common ROS2 interface (c) higher-level ROS2 software implementations and configurations of standard robot autonomous planning and control, including the nav2 stack which performs SLAM and enacts commands to drive the vehicle from a current to a desired pose around obstacles. OpenPodcar2 can transport a human passenger or similar load at speeds up to 15km/h, for example for use as a last-mile autonomous taxi service or to transport delivery containers similarly around a city center. It is small and safe enough to be parked in a standard research lab robust enough for some deployment cases. Total build cost was around 7,000USD from new components, or 2,000USD with a used Donor Vehicle. OpenPodcar2 thus provides a research balance between real world utility, safety, cost and robustness.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

1 major / 2 minor

Summary. The paper describes OpenPodcar2, an open-source autonomous vehicle platform derived from an off-the-shelf mobility scooter. It details a bill of materials and build instructions for hardware modifications, integration with the OSH R4 mechatronics board, a Gazebo simulation sharing a ROS2 interface, and configurations of the nav2 stack for SLAM, obstacle-aware planning, and control. The platform is positioned as low-cost (approximately $2,000–$7,000), capable of transporting a passenger or load at up to 15 km/h, and providing a balance of real-world utility, safety, cost, and robustness suitable for both research experiments and limited deployment scenarios such as last-mile services.

Significance. If the hardware and software integration function as described, the work would supply a reproducible, affordable hardware testbed that lowers the barrier for self-driving research in resource-constrained labs. The explicit provision of a common ROS2 interface, Gazebo model, and nav2 configurations is a concrete strength that supports extension and comparison with other platforms. The significance for deployment claims, however, is constrained by the absence of any reported performance data.

major comments (1)
  1. [Abstract and §5] Abstract and §5 (Evaluation/Results): the central claim that OpenPodcar2 is 'robust enough for some deployment cases' and 'provides a research balance between real world utility, safety, cost and robustness' is load-bearing yet unsupported by quantitative evidence. The manuscript supplies BOM, build instructions, simulation, and nav2 configurations, but reports no navigation success rates across trials, logged interventions, uptime statistics, payload effects, or identified failure modes (e.g., at 15 km/h or on uneven surfaces). Without such data the robustness assertion rests on design intent and standard-stack usage rather than demonstrated behavior.
minor comments (2)
  1. [Figure captions and §3] Figure captions and §3 (Hardware): the wiring diagram and component labels could be expanded to explicitly map each element to the corresponding ROS2 topic or driver node, improving reproducibility for readers replicating the build.
  2. [§4] §4 (Software): the description of the nav2 parameter files would benefit from a short table listing the key tuned values (e.g., controller gains, costmap inflation radii) rather than referring readers only to the repository.

Simulated Author's Rebuttal

1 responses · 0 unresolved

We thank the referee for their constructive review and for recognizing the value of the open-source platform, hardware documentation, simulation, and ROS2 integration. We address the single major comment below.

read point-by-point responses
  1. Referee: [Abstract and §5] Abstract and §5 (Evaluation/Results): the central claim that OpenPodcar2 is 'robust enough for some deployment cases' and 'provides a research balance between real world utility, safety, cost and robustness' is load-bearing yet unsupported by quantitative evidence. The manuscript supplies BOM, build instructions, simulation, and nav2 configurations, but reports no navigation success rates across trials, logged interventions, uptime statistics, payload effects, or identified failure modes (e.g., at 15 km/h or on uneven surfaces). Without such data the robustness assertion rests on design intent and standard-stack usage rather than demonstrated behavior.

    Authors: We agree that the manuscript does not contain quantitative performance data from real-world trials to substantiate the robustness and deployment claims. The contribution centers on the documented hardware modifications, OSH R4 integration, Gazebo model with shared ROS2 interface, and nav2 configurations rather than empirical evaluation. We will revise the abstract and §5 to remove or qualify the unsupported assertions (e.g., changing 'robust enough for some deployment cases' to language that reflects design intent and component choices). A limitations paragraph will be added noting the absence of trial statistics and identifying field validation as future work. These changes will appear in the revised manuscript. revision: yes

Circularity Check

0 steps flagged

No circularity: purely descriptive systems report with no derivations or fitted predictions

full rationale

The paper is a descriptive systems report detailing hardware modifications, ROS2 integration, bill of materials, build instructions, Gazebo simulation, and nav2 stack configurations for an autonomous mobility scooter platform. It contains no mathematical derivations, equations, parameter fitting, predictions of new quantities, or uniqueness theorems. The central claim of robustness for research and potential deployment is presented as a design outcome supported by standard open-source stacks and documented components rather than any self-referential reduction or fitted input. Self-reference to the prior OpenPodcar design is limited to noting it as a base for extension and does not bear load on any claimed result. No steps reduce by construction to inputs.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

No free parameters, axioms, or invented entities are involved; the paper is a hardware-software platform description without theoretical modeling or data fitting.

pith-pipeline@v0.9.0 · 5566 in / 1061 out tokens · 33797 ms · 2026-05-08T02:55:47.853753+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

78 extracted references · 78 canonical work pages

  1. [1]

    https://f1tenth.org/

    F1tenth. https://f1tenth.org/

  2. [2]

    https://mit-racecar.github.io/

    MIT RaceCar. https://mit-racecar.github.io/

  3. [3]

    https://mushr.io/

    MuSHR. https://mushr.io/

  4. [4]

    arXiv preprint arXiv:2206.14651

    Aharon, N., Orfaig, R., Bobrovsky, B.Z.: Bot-sort: Robust associations multi-pedestrian tracking. arXiv preprint arXiv:2206.14651 (2022)

  5. [5]

    In: TAROS (2023)

    Alabi, E., Camara, F., Fox, C.: Evaluation of OSMC open source motor driver for reproducible robotics research. In: TAROS (2023)

  6. [6]

    https://github.com/ApolloAuto/apollo

    ApolloAuto: Apollo. https://github.com/ApolloAuto/apollo

  7. [7]

    HardwareX10, e00217 (2021)

    Betancur-V´ asquez, D., Mejia-Herrera, M., Botero-Valencia, J.: Open source and open hardware mobile robot for developing applications in education and research. HardwareX10, e00217 (2021)

  8. [8]

    IEEE Transactions on Intelligent Transportation Systems22(10), 6131–6151 (2020) 12

    Camara, F., Bellotto, N., Cosar, S., Nathanael, D., Althoff, M., Wu, J., Ruenz, J., Dietrich, A., Fox, C.W.: Pedestrian models for autonomous driving part i: low-level models, from sensing to tracking. IEEE Transactions on Intelligent Transportation Systems22(10), 6131–6151 (2020) 12

  9. [9]

    In: Human Factors in Intelligent Vehicles, pp

    Camara, F., Cosar, S., Bellotto, N., Merat, N., Fox, C.W.: Continuous game theory pedestrian modelling method for autonomous vehicles. In: Human Factors in Intelligent Vehicles, pp. 1–20. River Publishers (2022)

  10. [10]

    Transportation research part F: traffic psychology and behaviour78, 410–423 (2021)

    Camara, F., Dickinson, P., Fox, C.: Evaluating pedestrian interaction preferences with a game theoretic autonomous vehicle in virtual reality. Transportation research part F: traffic psychology and behaviour78, 410–423 (2021)

  11. [11]

    International Journal of Social Robotics13(8), 1929–1949 (2021)

    Camara, F., Fox, C.: Space invaders: Pedestrian proxemic utility functions and trust zones for autonomous vehicle interactions. International Journal of Social Robotics13(8), 1929–1949 (2021)

  12. [12]

    Jounral of Open Hardware7(1), 1–13 (2023)

    Camara, F., Waltham, C., Churchill, D., Fox, C.: OpenPodcar: an open source vehicle for self-driving car research. Jounral of Open Hardware7(1), 1–13 (2023)

  13. [13]

    Journal of Open Hardware7(1) (2023)

    Carter, S.J., Tsagkopoulos, N.C., Clawson, G., Fox, C.: Openscout: Open source hardware mobile robot. Journal of Open Hardware7(1) (2023)

  14. [14]

    IEEE Control Systems Magazine39(1), 26–55 (2019)

    Goldfain, B., Drews, P., You, C., Barulic, M., Velev, O., Tsiotras, P., Rehg, J.M.: Autorally: An open platform for aggressive autonomous driving. IEEE Control Systems Magazine39(1), 26–55 (2019)

  15. [15]

    Gonzales, J.: Planning and Control of Drift Maneuvers with the Berkeley Autonomous Race Car. Ph.D. thesis, University of California at Berkeley (2018)

  16. [16]

    In: 2016 IEEE international conference on robotics and automation (ICRA)

    Hess, W., Kohler, D., Rapp, H., Andor, D.: Real-time loop closure in 2d lidar slam. In: 2016 IEEE international conference on robotics and automation (ICRA). pp. 1271–1278. IEEE (2016)

  17. [17]

    https://www.opensourceecology.org/ (2003)

    Jakubowski, M.: Open Source Ecology. https://www.opensourceecology.org/ (2003)

  18. [18]

    In: 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems (ICCPS)

    Kato, S., Tokunaga, S., Maruyama, Y., Maeda, S., Hirabayashi, M., Kitsukawa, Y., Monrroy, A., Ando, T., Fujii, Y., Azumi, T.: Autoware on board: Enabling autonomous vehicles with embedded systems. In: 2018 ACM/IEEE 9th International Conference on Cyber-Physical Systems (ICCPS). pp. 287–296. IEEE (2018), https://github.com/Autoware-AI/autoware.ai

  19. [19]

    In: 2019 IEEE Intelligent Vehicles Symposium (IV)

    Kessler, T., Bernhard, J., Buechel, M., Esterle, K., Hart, P., Malovetz, D., Truong Le, M., Diehl, F., Brunner, T., Knoll, A.: Bridging the gap between open source software and vehicle hardware for autonomous driving. In: 2019 IEEE Intelligent Vehicles Symposium (IV). pp. 1612–1619 (2019). https://doi.org/10.1109/IVS.2019.8813784

  20. [20]

    In: 2011 IEEE international symposium on safety, security, and rescue robotics

    Kohlbrecher, S., Von Stryk, O., Meyer, J., Klingauf, U.: Aflexible and scalable slam system with full 3d motion estimation. In: 2011 IEEE international symposium on safety, security, and rescue robotics. pp. 155–160. IEEE (2011)

  21. [21]

    Journal offield robotics36(2), 416–446 (2019)

    Labb´ e, M., Michaud, F.: RTAB-Map as an open-source lidar and visual simultaneous localization and mapping library for large-scale and long-term online operation. Journal offield robotics36(2), 416–446 (2019)

  22. [22]

    Journal of Open Source Software 6(61), 2783 (2021)

    Macenski, S., Jambrecic, I.: SLAM toolbox: SLAM for the dynamic world. Journal of Open Source Software 6(61), 2783 (2021)

  23. [23]

    In: 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) (2020)

    Macenski, S., Martin, F., White, R., Gin´ es Clavero, J.: The marathon 2: A navigation system. In: 2020 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS) (2020)

  24. [24]

    Merat, N., Bellotto, N., Camara, F., Fox, C., Cosar, S.: Towards pedestrian-av interaction: method for elucidating pedestrian preferences (2018)

  25. [25]

    In: IECON 2019 - 45th Annual Conference of the IEEE Industrial Electronics Society

    Nakamoto, N., Kobayashi, H.: Development of an open-source educational and research platform for autonomous cars. In: IECON 2019 - 45th Annual Conference of the IEEE Industrial Electronics Society. vol. 1, pp. 6871–6876 (2019). https://doi.org/10.1109/IECON.2019.8926794 13

  26. [26]

    Hard- wareX14, e00426 (2023)

    Nwankwo, L., Fritze, C., Bartsch, K., Rueckert, E.: Romr: A ros-based open-source mobile robot. Hard- wareX14, e00426 (2023)

  27. [27]

    https://www.openmotors.co/evplatform/

    Open Motors: Tabby EVO. https://www.openmotors.co/evplatform/

  28. [28]

    https://gitlab.com/pixmoving/pixbot

    PixMoving: Pixbot. https://gitlab.com/pixmoving/pixbot

  29. [29]

    HardwareX14, e00436 (2023)

    Raudm¨ ae, R., Schumann, S., Vunder, V., Oidekivi, M., Nigol, M.K., Valner, R., Masnavi, H., Singh, A.K., Aabloo, A., Kruusam¨ ae, K.: Robotont–open-source and ros-supported omnidirectional mobile robot for education and research. HardwareX14, e00436 (2023)

  30. [30]

    In: 2024 IEEE 29th International Conference on Emerging Tech- nologies and Factory Automation (ETF A)

    Sell, R., Malayjerdi, M., Pikner, H., Razdan, R., Malayjerdi, E., Bellone, M.: Open-source level 4 au- tonomous shuttle for last-mile mobility. In: 2024 IEEE 29th International Conference on Emerging Tech- nologies and Factory Automation (ETF A). pp. 01–06. IEEE (2024)

  31. [31]

    In: International Conference on Social Robotics (ICSR) (2026)

    Soni, R., Fox, C.: Pedestrians play chicken with an autonomous vehicle. In: International Conference on Social Robotics (ICSR) (2026)

  32. [32]

    Sensors21(11) (2021)

    Vincke, B., Rodriguez Florez, S., Aubert, P.: An open-source scale model platform for teaching autonomous vehicle technologies. Sensors21(11) (2021). https://doi.org/10.3390/s21113850, https://www.mdpi.com/ 1424-8220/21/11/3850, https://github.com/BastienV-SATIE/AutonomousCar/

  33. [33]

    Journal of Open Hardware9(1) (2025)

    Waltham, C., Perrett, A., Soni, R., Fox, C.: R4: rapid reproducible robotics research open hardware control system. Journal of Open Hardware9(1) (2025)

  34. [34]

    In: European conference on computer vision

    Zhang, Y., Sun, P., Jiang, Y., Yu, D., Weng, F., Yuan, Z., Luo, P., Liu, W., Wang, X.: Bytetrack: Multi- object tracking by associating every detection box. In: European conference on computer vision. pp. 1–21. Springer (2022) 14 Appendix A 15 OpenPodcar2 Bill of Materials Name Component USD Source Interface Implementation Donor V ehicle Phiseng TE-889XLS...

  35. [35]

    Ubuntu 22.04 clean install: https://ubuntu.com/tutorials/install-ubuntu-desktop

  36. [36]

    ROS2 Humble full desktop install: https://docs.ros.org/en/humble/Installation/Ubuntu-Install-Debians. html

  37. [37]

    Gazebo fortress install: https://Gazebosim.org/docs/fortress/install

  38. [38]

    Follow this guide step by step: https://index.ros

    ros_gz package could be installed as a binary package. Follow this guide step by step: https://index.ros. org/r/ros gz/. This enables communication between ROS2 Humble and Gazebo fortress

  39. [39]

    Install and configure R4firmware: https://gitlab.com/charles.fox/r4pcb

  40. [40]

    Follow the guide for ROS2 link for Intel wrapper – https://github.com/ IntelRealSense/realsense-ros#installation-instructions

    Install depthcam drivers. Follow the guide for ROS2 link for Intel wrapper – https://github.com/ IntelRealSense/realsense-ros#installation-instructions. Choose option 1 and click on Linux Debian in- stallation guide and run commands mentioned line by line

  41. [41]

    Select option 2: Install librealsense2 package from ROS servers: sudo apt install ros-humble-librealsense2*

    Install ROS2 integration for depthcam: In the same repo: Under installation and step 2 : install latest Intel RealSense SDK 2.0. Select option 2: Install librealsense2 package from ROS servers: sudo apt install ros-humble-librealsense2*. 38 Then, install ROS2 Wrapper: option 1→ sudo apt install ros-humble-realsense2-* Realsense ROS2 wrapper to visualize p...

  42. [42]

    •Add the following to your ˜/.bashrc: source /opt/ros/humble/setup.bash

    To test that ROS2 is installed properly. •Add the following to your ˜/.bashrc: source /opt/ros/humble/setup.bash . •Open two terminals, infirst run: ros2 run demo_nodes_cpp talker , you should see hello in the console. •In other terminal, run: ros2 run demo_nodes_py listener , you should see I Heard . •In order to keep the nodes communication robust, set t...

  43. [43]

    To test the Gazebo fortress is installed on the system, in the terminal run: ign gazebo .If it launches, you’ll see the simulation software window. •To test the ros_gz package , run: ros2 run ros_gz_bridge parameter_bridge chatter@std_msgs/msg String@gz .msgs.StringMsg •View the topic in other terminal using: ros2 topic list -t Installation for OpenPodcar...

  44. [44]

    •Make the new workspace, with src directory

    If using Gazebo fortress, clone the repository following below commands. •Make the new workspace, with src directory. mkdir -p ros2_gz_ws/src . •Clone the repository using: git clone --recurse-submodules -b Fortress https://github.com/Rak-r/OpenPodcar2 .git

  45. [45]

    After cloning the repository, check that you have pod2_description, pod2_bringup, pod2_navigation, pod2_sensor_tools in your src directory

  46. [46]

    •Assuming you are in src directory, run: cd

    Now, build the packages from the root of the workspace directory using ROS2 package building tool colcon. •Assuming you are in src directory, run: cd .. • colcon build --symlink-install . This will build the packages and the --symlink-install is used to make changes in the packages in src directory and also changes in the install dircetory without re-buil...

  47. [47]

    If colcon build fails to build any packages and shows stderr in terminal console, make sure all the dependencies are installed correctly

    If everything works well, you will have three directories along with src named install, build and log . If colcon build fails to build any packages and shows stderr in terminal console, make sure all the dependencies are installed correctly

  48. [48]

    Calibration Depthcam calibration The Depthcam needs physical calibration in order to achieve reliable SLAM and mapping operation

    In case of Step 4, try running: rosdep install --from-paths src -y --ignore-src . Calibration Depthcam calibration The Depthcam needs physical calibration in order to achieve reliable SLAM and mapping operation. For this, place an object 10m away at the same height as the camera from the ground. Adjust camera to ensure that the object appears in the cente...

  49. [49]

    To launch OpenPodcar2 with depth camera enabled, run the below launchfile: •Launch with Rviz2 : ros2 launch p o d 2 _ d e c s r i p t i o n p o d 2 _ d e s c r i p t i o n . launch . py sc an _n od e := false RG BD _n od e := true rviz := true } This launch will launch the simulation in Gazebo. Turn on the play pause button to run the simulation. To view t...

  50. [50]

    Config directory: This includes the parameterfile which includes the parametrers for AMCL, BT_Navigator, Controller server, Planner server, Global and Local Costmaps, Behaviour servers, Map server

  51. [51]

    Launch Directory: The launch directory consists of OpenPodCar_V2_NAV2.launch.py which is modified from the default nav2_bringup package for launching the specified nodes and takes the nav2_dwb_smac from the config directory which uses dwb as controller server and SmacPlannerHybrid as global planner server

  52. [52]

    Launching instructions To run the Navigation with OpenPodcar2 while mapping launch RTAB-Map to start the visual odometry (VO) and Mapping

    Maps Directory: The maps directory consists of maps created to test the NA V2 with prebuilt maps. Launching instructions To run the Navigation with OpenPodcar2 while mapping launch RTAB-Map to start the visual odometry (VO) and Mapping. Following this start the NA V2 stack as described below. Moreover, for pure localization with prior map setup, the defau...

  53. [53]

    Navigate to root of the ROS2 workspace: cd <workspace>

  54. [54]

    Source the ROS2 workspace: source install/setup.bash 44

  55. [55]

    Start RTAB-Map: ros2 launch pod2_rtabmap rtabmap_sim.launch.py

  56. [56]

    NA V2 Stack: ros2 launch pod2_navigation OpenPodCar_NAV2.launch.py slam:=false rviz:=true amcl:=false

  57. [57]

    If want to build the custom map using slam_toolbox, then change the mode to mapping in mapper_params_online_async .yaml

  58. [58]

    RTAB-Map can be started in localization mode by passing the argument localization to true while launching the algorithm

    RTAB-Map saves the information in a database (.db)file from which 3D map, 2D occupancy grid map can be generated. RTAB-Map can be started in localization mode by passing the argument localization to true while launching the algorithm

  59. [59]

    In future more version suppport will be added

    The map can be saved either by command-line: ros2 run nav2_map_server map_saver_cli -f <map> Docker support The docker version is supported for ROS2 humble and gazebo Fortress due to LTS version of gazebo at the time project development. In future more version suppport will be added. Follow the below instructions for using docker version of OpenPodcar2 wi...

  60. [60]

    After cloning the repository from same above instructions, make sure docker is installed correctly

  61. [61]

    pip3 install rocker

    Install rocker in the local machine to run GUI applications without any hastle inside the container. pip3 install rocker

  62. [62]

    Build the image: docker build -t openpodcar2_docker

  63. [63]

    Run the container with rocker: rocker --x11 openpodcar2_docker

  64. [64]

    docker build --build-arg INCLUDE_YOLO=true -t openpodcar2_docker

    If want to build the perception stack as well, then build the image with argument in below command. docker build --build-arg INCLUDE_YOLO=true -t openpodcar2_docker

  65. [65]

    Source ros2 and the workspace before running any ros2 nodes or launchfiles as done in normal local machine setup

  66. [66]

    Test the setup by running the below. ros2 launch pod2_description pod2_description.launch.py scan_node:=false rgbd_node:=true Teleop physical vehicle To launch the physical OpenPodcar2 with teleoperation mode, the higher-level incoming game-pad commands as Twist message linear.x, angular.z are converted to R4 protocol message which controls the main drive...

  67. [67]

    Turn on the R4: The R4_Board feature a MCB for ease to switching on and off

  68. [68]

    Refresh the wifisearch in the PC to see the available networks

    Turn on the wifirouter: Connect the laptop/PC with the visible router wifinetwork name. Refresh the wifisearch in the PC to see the available networks

  69. [69]

    Navigate to root of the workspace directory: cd <workspace>

  70. [70]

    Source the ROS2 workspace: source install/setup.bash

  71. [71]

    With rviz2: ros2 launch pod2_description OpenPodCar.launch.py rviz:=true

  72. [72]

    Launch the R4-ROS2 R4_Websockets, R4_Reciever, R4_Publisher and teleop_twist_joy node: ros2 launch pod2_bringup R4_ROS2.launch.py teleop_node:=true To drive the vehicle, hold down the physical DMH button on the gamepad (named as enable button in the configuration directory, config) then use its joycon to steer left and right and drive forward and backward. ...

  73. [73]

    Launch the depthcam Node: ros2 launch pod2_sensor_tools realsense_launch.py

  74. [74]

    Verify proper camera launch: Look for /camera_color/_image_raw, /depth, /depth_camera_info and /cloud_in topics using; ros2 topic list -t

  75. [75]

    46 Starting the robot model and rest of the stack:

    Start the pointcloud_to_laserscan node: ros2 launch pod2_sensor_tools point_to_scan.launch.py This node will convert the incoming PointCloud2 message into LaserScan message which is used by SLAM. 46 Starting the robot model and rest of the stack:

  76. [76]

    Launch robot URDF model: ros2 launch pod2_description OpenPodCar.launch.py rviz:=true

  77. [77]

    Launch RTAB-Map visual odometry (VO) and SLAM: ros2 launch pod2_rtabamap rtabmap.launch.py

  78. [78]

    Parameter tuning To achieve reasonable results, parameters have been tuned to match the developed mobile platform, with the final parameters included in the release code

    Launch NA V2: The same command from the autonomous simulation instruction can be used to launch the physical vehicle nav2 stack. Parameter tuning To achieve reasonable results, parameters have been tuned to match the developed mobile platform, with the final parameters included in the release code. Where new builds deviate from the original design it is li...