Roomac - general-purpose personal robot (construction + fetch a bottle demo application)

Hi everyone,

I’m happy to share the project that I’ve been working on for the past 3 years. Roomac is a low-cost autonomous mobile manipulation robot that consists of a differential drive mobile base and a 5-DoF manipulator with a gripper. The costs of the whole construction summed up to around 550$ and using this platform I was able to prepare a proof-of-concept application - fetching a bottle to the user. Below you can see a gif of the robot (and here you can watch the full demo).


Software is based on ROS Melodic, I used many ROS packages, some of them are RTABMap, move_base (with TEB as a local planner), robot_localization, MoveIt with BioIKKinematics (robot’s arm has 5DoF and only with BioIK I was able to achieve desired positions), ar_track_alvar.

Working with cheap components was quite a challenge and I’m still amazed that it was possible to configure TEB to smoothly control the drill motors that I used in the base. Overall I worked on this project alone, and it is awesome, what is possible to achieve using ROS, even without a large budget.

Most of the construction was 3D printed, the base consists of DC drill motors, encoders, IMU and STM32BluePill MCU. In the manipulator there are 6 servos: 3 XYZrobot A1-16 and 3 cheaper TowerPro (MG996R and 2xSG-92R) which are controlled by the second STM32BluePill. To detect obstacles and create a map of the environment I used Kinect (the one from Xbox360). The second Kinect is mounted above the table and it is used for the manipulation (robot’s position is detected using ARTags). Navigation computations are run on the laptop placed in the base of the robot.

If you’re interested in this project, you can check out the Github repository and my master’s thesis, which describes it in much more detail.

Apart from construction I also created a simulation of the robot in the Gazebo. There is a docker image with it, so executing the demo is really easy (basically you only need to copy and paste two commands). For further details please refer to the instruction in the README on Github, hope you like it!




Just wanted to say that’s a fantastic project, reminds me a bit of my thesis since it uses a lot of the same parts :smile:

In terms of runtime, if you plan on adding a NUC to the existing battery setup as you say you’ll see that plummet severely since they can draw quite a bit. Given that this is a robot that’ll be confined to one specific area, it might make sense to have it use something like microROS with a wifi capable microcontroller and offload all the expensive processing to another mains powered machine on the local network?

Not sure how well that’ll work for the point cloud data since you’d need quite the high throughput connection, but it may be worth checking out.

Thanks! Nice, can you share your thesis? I would love to check it out.

Before choosing to go with the onboard laptop I did some remote mapping tests with Raspberry Pi 3B (Kinect was connected to the RPi and data was being sent through a WiFi connection to my laptop which ran the RTABMap node). I tried two setups: in one there was only Kinect’s driver running on the RPi, in the other one I followed the Remote Mapping tutorial and additional node synchronized and compressed data. In both cases results weren’t good enough - frequency was low and a lot of data was being dropped (and it was just mapping, without navigation).

1 Like

@ macorobots That is a fantastic achievement given the budget you had.
However i would like to know a bit more about the accuracy of localization and bottle detection.

Thanks! I described all accuracy tests and results in my master’s thesis - odometry, localization, autonomous navigation in chapter 5 and everything regarding manipulation in chapter 6.

Ah yeah, probably not worth bothering until they make a wifi 6 capable Pi or something of the sort. And even if you did reduce the power consumption of the the compute part you’d still be left with it discharging in a relatively short time frame due to actuator use anyway I suppose.

On second thought it would make more sense to just have a contact charger that it returns to after completing tasks, and just idling there. That way it’s always fully charged and ready to go.

Well the thesis itself is actually in Slovenian so I’m not sure if it’ll be of much use, but I did later on put the gist of it in an article format that you can find in English below. There’s also a video linked in the git repo readme.

The main similarity are the Cytron drivers I suppose, the first version also used lead acids but I later replaced them with lipos.