A new version of ARIPS is taking shape: ARIPS 12!

The previous platform was over a decade old and originated from my bachelor’s thesis. Although I modified and improved it extensively over the years, it still had several issues, big and small, that could not be solved without a ground-up rebuild.

ARIPS 12 is designed around the following features and improvements:

• Keep the general TurtleBot style with differential drive, a caster wheel and a tiltable Kinect, which has proven itself over the years.
• Keep the two base plates. The laptop goes on top, the lidar and some components in the middle, and the motors and battery below.
• Keep wood as the plate material, since it is easy to work with and modify.
• Keep the Feetech servo ecosystem, since they are precise, affordable, reliable and easy to control.
• Space for a bigger laptop (15” screen) with a dedicated GPU.
• Fast, tool-less removal of the top plate, without screws.
• Thicker base plates, so that screws can go directly into them without needing nuts on the other side.
• Sturdier chassis in general.
• Backlash-free Kinect mount.
• Most important: a bigger arm that can physically pick up objects from a table and open doors in both directions.

Especially the last point I found impossible to achieve with the old chassis. Pulling on doors was possible in theory (though not very reliable), but pushing from the other side was impossible, since the robot could not get close enough to the handle without colliding with the door frame. Without that, my long-desired goal of unconstrained navigation through my whole apartment with closed doors would remain out of reach.

New chassis

The chassis is made of two wooden plates held together with 2020 V-Slot aluminium profiles, just as in many traditional 3D printers.

Front side	Back side

Electronics

Most of the electronics were reused from ARIPS10, particularly the YDLidar, the Kinect and the Arduino motor driver. I switched to a bigger, safer LiFePO4 battery and a new 12V Feetech servo driver board.

Base electronics (Lidar, USB hub, Feetech servo driver, and a ton of cables)	Differential drive, power and motor control

SCARA Arm

To reach a conventional door handle while also being able to pick up objects from the ground, the arm needs a large vertical range of motion. I decided to go with a SCARA arm, driven by a lead screw that moves it up and down the V-Slot profile. To drive the lead screw, I use a geared DC motor instead of a conventional stepper motor. I hope it will be much faster, since I don’t want to wait several minutes for the full range of motion. The DC motor has a rotary encoder and end switches for the top and bottom positions. An STM32 controls the motor and is programmed to imitate a Feetech STS3215 servo. This way, the linear joint should integrate easily with existing ROS drivers and the LeRobot project.

The parts are still under construction. A detailed explanation will follow.

Transitioning to ROS 2

Since ROS 1 Noetic went EOL in 2025 and most newer software and drivers target ROS 2, I dared to make the full transition. There are some third-party libraries and packages which only exist for ROS 1, but thanks to AI it is easier than ever to port them. It is also a chance to rework my own software stack, get rid of stale code, and design a better overall architecture.

I abandoned my own navigation stack completely and now use Nav2. With behavior trees, topological route planning and execution can now be modeled as custom behavior tree action plugins. This gives a clear separation between components, whereas the old arips_navigation was a monolith running in a single process.

Demo of topological navigation

Here is a demo of topological navigation on ARIPS 12. For route planning, I have a semantic map server with annotated door positions. A custom route planner segments the rooms, creates a route graph with doors as edges, and plans a topological route upon request. A behavior tree then executes the route piece by piece. For navigating on flat ground inside a room, I use the usual Nav2 ComputePathToPose/FollowPath combination. For crossing doors, I implemented a custom CrossDoorStep action. This requires slow movement strictly perpendicular to the door edge, since otherwise a wheel might slip on the edge, which can be several mm high in my apartment. Later on, the behavior tree will be extended to handle closed doors and other hazards.