Update after a break

After some waiting and more waiting… and some work in the meantime on a different project (I might describe that one also one day), I’m back to this idea of a controllable Roomba. I started to install required software on the Raspberry Pi I’ve bought. The OS is Raspbian Jessie with ROS Kinetic. It’s not difficult – just takes some time, because most of packages had to be built (almost no binaries). I’m happy because I’ve learnt a new thing! Last time I was doing this kind of thing I’ve missed one of the paragraphs in the installation guide and didn’t know exactly how to properly add released packages to the build. I was adding their source code to the standard workspace and than built it. Which worked, but made every build during development quite long (it checks every package in the workspace for updates). In Ubuntu, you can install most of the packages via apt-get. And there are no such binaries for Debian systems. Because why should there be? ROS is not that strongly supported on Debian. Let alone an ARMv7 Debian… But from the installation guide, we see that invoking this (with package names we want to install instead of “packages” in the second line) adds the packages to the basic workspace.

cd ~/ros_catkin_ws
rosinstall_generator packages --rosdistro kinetic --deps --wet-only \
    --tar > kinetic-custom_ros.rosinstal
wstool merge -t src kinetic-custom_ros.rosinstall
wstool update -t src
rosdep install --from-paths src --ignore-src --rosdistro kinetic -y \
    -r --os=debian:jessie
sudo ./src/catkin/bin/catkin_make_isolated --install \
    -DCMAKE_BUILD_TYPE=Release --install-space /opt/ros/kinetic -j2

Basically, the rosinstall_generator creates a rosinstall file for the packages, which allows easy installation of dependencies (rosdep install) and building of those packages from sources (the last line). wstool is used here to update the workspace (let’s just say it has to be there).

Beside installing bare ROS, I have also installed the create_autonomy package I’ve mentioned here and a  raspicam_node for using the Pi camera with ROS (quite useful and simple). I did have a problem with the Eigen3 library when building the robot_state_publisher package, which is a dependency for create_autonomy. I fixed it by applying the changes mentioned by bchretien here to the CMakeLists.txt file in the sources of the robot_state_publisher package. When compilng cv_bridge on the other side, the Raspberry ran out of memory. The solution was to change the last option in the last command from -j2 to -j1. It limited the number of cores on which the compilation was taking place from 2 to 1 and thus reducing the amount of memory required to compile. I’m still trying to force myself to write a bigger article about ROS. It’s coming, I promise.

I also managed to strip my Roomba to bare parts (and assemble it back to the functional state). This thing is really well designed. Most of the parts are separate modules. E.g. the motors and wheels. After unscrewing the bottom plate, you just need to unscrew 3 screws and the module pops out. It’s connected with the rest by an edge connector, which makes it even simpler – there are no cables. At least in this part. The front, where there are more sensors is more messed up, but it’s still pretty neat and tidy. Always, in such constructions, the ideal length of the cables is causing me to smile. Quite the contrary of prototype projects.

In the next article I’ll try to describe some basics of 3d printing and how it’ll be useful for this project. Cheers!

 

First purchases!

Sooo… after checking everything the second time, some things started to become confusing. For example, I’ve found statements like that the ROI is implemented in the 500, 700 and 800 series. The problem – I found out that the best option, should be a 600 series model. The 650 seemed nice, and a reasonable price. But it’s a 600 series model and as I wrote above the ROI is implemented in the 500, 700 and 800 series. Why not 600? It looks like the 600 series is sometimes counted into the 500 series. I don’t know why – don’t ask me. I wanted a 600 series model badly, because the hardware of the official iRobot development platform – Roomba Create 2 – was based on the 600 series. So there area some to be 3D printed models of stuff that I might find useful. Better to have it than not to have it.

So – I’ve bought a 650 model. And yes – it has the ROI connector! I didn’t have the time to buy parts and assembly the communication converter (as I wrote here, you need some sort of a signal converter between the Roomba and the computer you’re using it with). But probably if it has the connector – it should be fine. After testing in my apartment I’ve found a few problems. First of all – it’s not so smart if you have few rooms and the door is opened (or there is no door). The robot might as well clean all rooms perfectly or get stuck in one. You might buy additional accessories (like a “Virtual Lighthouse” – but yea, it costs). The control algorithms look a bit random sometimes – but in general they work great. Only if there is a big open space with a small, bottleneck like passing to a smaller space, the robot might get confused. I have a small step on the 1st floor, which leads directly to the stairs. Going-down-type-of-stairs. No, come back – going-really-fast-down-type-of-stairs. Unfortunately, the step is too small to be detected by the Roomba’s cliff sensors, but it’s high enough for it to have some trouble trying to pass it. Resulting – I’m pretty sure that if there was no step in this place, the robot would not have fallen down the stairs. But now I’m afraid it will. So, having 3 bedrooms and a bathroom on the first floor, I’ll have to clean all of them separately, because the robot would fall of the stairs. And no – sadly there is no place here for the virtual wall (like this one).

The robot also failed to move around our drying racks. It ended in desperately trying to overcome the obstacle for a minute or so. Not what you would’ve expect from a smart robot – would you? Navigation and obstacle avoidance should be improved. And it will.

About the rest. I’ve figured I would use a Raspberry Pi 3 for the brains of the robot. It should be enough to process everything. It has a dedicated camera which could be used for indoor mapping and navigation – so it fits. For more precise indoor navigation I will try to use either AR tags or something like iBeacons. But I like the idea of AR tags. And it’s cheaper! 🙂

Still I have to solve the vocal processing part. But I think I will stick with Amazon Echo or directly implement Alexa on the Pi I will use on the Roomba. We shall see.

The Roomba

Ok! First research job done. I am sure I can use a Roomba. And it’s not going to be an awful story full of pain. Roombas above model 600 (so Create 2, 6xx, 7xx, 8xx series) have something called iRobot Open Interface implemented (let’s refer to this as OI). You can find it here. Basically, you have to connect a Roomba’s serial interface to Your PC (with e.g. Roomba OSMO or you can find a lot of tutorials on how to do it with home made electronics) and post special one-byte commands to the interface. Every value has it’s function. For example if you send 128 you activate the serial communication. And if you post 135 the Roomba should start its basic cleaning procedure. The fun part is that you can also post direct steering commands and read sensor values to basically override the implemented software. So, this is what I was looking for. Oh and of course you don’t change the internal software of the robot – so after having some fun, you can just push CLEAN and it will start cleaning like nothing happened.

As fun as it may seem, spending a week writing a parser for the communication wouldn’t be that cool. So after a minute I’ve found this. Which is basically a ROS Roomba node. And luckily it doesn’t have every option 100% coded, so I have some basic functionality and can implement and contribute something if I need it. It’s nice because it will give me an opportunity to learn in practice how to use the OI without the need to implement everything. Which is kind of boring after you are sure about the main idea. For example, brush motors and cliff sensors are marked as Planned not as Available. I could use those, so maybe I will code them later.

There are also tons of other implementations. Which is good. If something will not be working I will have some reference. And no. I haven’t bought the robot yet. First I want to confirm that everything will be working together. Next stops are camera, indoor positioning systems (IPS) and voice processing.

 

PS.  I promise I will write more about ROS soon 🙂

 

The basics – project approach

So… lets start over. My enthusiasm caused me to write a bit too much in the previous post… And yeah – you might be wondering why I’ve called the basics “project approach”, not “coding something”. That’s because before we get to write any line of code there’s a lot of work to be done. I mean planning and research. Let’s learn something useful, aside of regular hacking. Hopefully this will allow You not to waste money or time on projects you actually don’t want to do. Or make stuff easier and allow you focus on the things you want to do. For me, in example, I prefer coding to electronics or mechanical design. So I will be more keen on using ready platforms and modules. But it’s different for everyone. The same thing for everyone should be to write requirements.

Requirements

Requirements basically tell You what are the specific goals of the project. It should tell You what the end product has to do (which is called functional requirements) and how it should do it (non-functional requirements). In the industry, the most common situation is that the customer tells what he wants (defines the functional requirements) and the development team defines how they’re going to do it (define the non-functional requirements). No.. back – the customer doesn’t usually know what he wants… but back again – I hope You got it. Another example – when You’re buying a door to Your house, You want it basically to do two things: let your family and guests in and keep the thieves out. Those are functional requirements. The development team than takes those and thinks how to make it happen. So they decide that the door should have a lock, which only opens when you wish for it to be opened. It can be a key lock, or maybe something more fancy, like Bluetooth lock, which connects to your phone or… oh well, you get the idea. Before thinking about the hardware or software, think about what it should do. In my case – I wanted to develop some skills and learn more about environment perception in robotics. Than I got the idea I could do it on a Roomba and I got really excited. But as I mentioned in the introduction – lets start over.

The why

I want to learn more about robotic perception and exploration. And the best way is to learn in practice – right? So, I decided to make a robotic platform which can:

1. Perform SLAM (including visual).
2. Easily charge the battery without maintenance (it might be funny, but sometimes it’s really annoying).
3. Be moved anywhere and still find its global position (limited to a single apartment).
4. Perform visual object recognition.
5. Determine the best path to reach its goal with 3D analysis of the surroundings.
6. Move from point A to point B.
7. Finally: perform missions which are combinations of tasks triggered by vocal commands. E.g. by saying Bring me a cold beer.

Roomba has great advantages, because it’s a simple, yet efficient mobile platform, it’s ROS-connectable (or so I have heard) and most models have a docking station. Fun part: only requirements 6 and 7 directly require a mobile platform. Requirements 1, 2, 3, 4 and 5 could be easily fulfilled with a smartphone. It has many sensors and a camera, so it can do a nice job in visual SLAM, you can easily buy docking stations, it can be moved and the challenge would be to make it aware of where it is (actually this is called Indoor Positioning Systems and is quite a problem to make it work literally anywhere) and it can still perform advanced tasks like path planning. But eventually, we want the thing to move by itself. That’s why we need a mobile platform (maybe put a phone on the Roomba?). Now, it would be nice to do a big research about mobile platforms available on the market. But I’ve already decided for a Roomba. A regular Roomba, not the Create one. Why? Because it has a built-in cleaning function and that can easily be turned into one of the missions. And I am too lazy to do the cleaning myself. What else would we need… #nonFunctionalRequirements

1. A camera (req. 1 and 4) and additional movement sensors (req. 1). And obviously a computer to process all the data.
2. A docking station for req. 2.
3. A global positioning system (also known as GPS) for req 3. Well… since here global means just one apartment, not the whole globe, GPS will not do well. It would be useful outside, but inside the satellite signal is just too weak. A replacement has to be found.
4. 3D mapping capability and analysis for req. 5. If we will do 3D visual SLAM it should be fine, but still it needs some computing power to calculate and analyze everything.
5. Movement capability for req. 6 and 7,
6. Vocal processing and an API or interface to program missions for req. 7.

Now. Having the non-functional requirements and just remembering the functional requirements we can try to figure out how to do the stuff we want to do. Now is the part where we should do some research. To learn how to solve those problems. Or use experience and just guess. But experience is dangerous. It obviously takes less time – you can figure out a solution just by looking at the problem. But the danger is that experience has been built on the past. If you rely on your experience too much, or you use experience gained a long time ago, you might end up using ancient and not the best available technology. Especially in the terms of advanced and new technologies. They kind-of quickly stop being new… or advanced… So my advice? Always do some research about how a problem can be solved! You might end up learning something and actually saving much time.

Problems to solve

I only know that I want to use a Roomba. Maybe I should have put it in the requirements? Well, doesn’t matter that much now. I will also need a camera, a way to determine indoor position and something for the vocal processing. I have some ideas, but I’ll make some research about it before writing any more. Oh yea – it would also be nice to confirm that I actually CAN use a Roomba for this kind of project. Meaning there exists a communication interface or ideally, a piece of software wrapping this interface in an easy to use API. We’ll see!

 

PS. This is a really brief explanation of what requirements are and are not. I know that from the industrial point of view much more kind of obvious things should be added. Like e.g. “the device shall be powered by a standard 230 V AC, 50 Hz power socket” or “the robot shall obey Asimov’s Laws”, etc. But lets say that we want to make it as simple as possible! And not bore anyone to death…

 

 

 

The first post

This is my first post. What will this site be about? We will see about that. Surely about hacking. And advanced tech. My research interest is robotic perception so we will have a lot of it. And I want to start hacking with an iRobot Roomba. It’s kind of cheap in contrary to other robotic platforms and obviously you can do a lot of fun stuff when combined with a Raspberry Pi. And after You’re done playing with it, it still can vacuum your house. How better can it be?

If you hang along, you will probably learn the basics of advanced robotics. I mean more advanced than combining a few wires and an Arduino. The fun part, is that all of the research is done. It’s somewhere out there, waiting to be found an put in good use. There is really a lot of open source software just waiting to get used. Visual recognition, obstacle avoidance, path planning or reverse kinematics. To begin with, that is. A lot more to discover. Let’s just start with SLAM and some sensor fusion. Hopefully Kalman filtering and stuff. We’ll see. But first some research. Remember – before starting buying parts, see what You can do with it 🙂
Hear you soon!