Sơ lược về Robot Operating System(ROS)

Robot operating system  là một hệ thống phần mềm chuyên dụng để lập trình và điều khiển robot, bao gồm các công cụ để lập trình, hiển thị, tương tác trực tiếp với phần cứng, và kết nối cộng đồng robot trên toàn thế giới. Nói chung là nếu bạn muốn lập trình và điều khiển một con robot, sử dụng phần mềm ROS sẽ giúp quá trình thực hiện nhanh hơn và bớt đau khổ hơn rất nhiều. Và bạn không cần ngồi viết lại những thứ mà người khác đã làm rồi, mà có những thứ muốn viết lại cũng không có khả năng. Như Lidar hoặc Radar driver chẳng hạn.

ROS chạy trên nền Ubuntu,  do đó để sử dụng ROS đầu tiền các bạn phải cài Linux. Cho bạn nào chưa biết cài Linux và ros thì mình có link này cho các bạn:

 

Những Robot và sensor được hỗ trợ bởi ROS:

16

Trên đây là những robot được hỗ trợ, bắt đầu từ Pepper(a), REEM-C(b), Turtlebot(c), Robotnaut(d) và Universal robot(e). Ngoài ra, các sensor được hỗ trợ bởi ROS gồm có LIDAR, SICK laser lms1xx, lms2xx, Hokuyo, Kinect-v2, Velodyne.., để biết thêm chi tiết, các bạn có thể xem hình dưới đây.

17

Hiểu cơ bản về cách hoạt động của ROS:

Về cơ bản ROS files được bố trí và hoạt động như sau, từ trên xuống theo thứ tự như sau, metapackages, packages, packages manifest, Misc, messages, Services, codes:

18Trong đó gói tổng(Metapackages) là một nhóm các gói(packages) có liên quan tới nhau. Lấy ví dụ như, trong ROS có một gói tổng tên là Navigation, gói này có chứa tất cả các gói liên quan tới việc di chuyển của robot, bao gồm di chuyển thân, bánh, các thuật toán liên quan như Kalman, Particle filter… Khi chúng ta cài đặt gói tổng, nghĩa là tất cả các gói con trong nó cũng được cài đặt.

Gói(Packages), ở đây là mình dịch là gói cho dễ hiểu, khái niệm gói rất quan trọng, chúng ta có thể nói rằng cái gói chính là các nguyên tử cơ bản nhất tạo nên ROS. Trong một gói gồm có, ROSnode, datasets, configuration files, source files,  tất cả được gói lại trong một “gói”. Tuy nhiên, mặc dù có nhiều thứ  trong một, gói, nhưng để làm việc, chúng ta chỉ cần quan tâm 2 thứ trong 1 gói, đó chính là src folder, chứa source code của chúng ta, và file Cmake.txt, đây là nơi ta khai báo những thư viện cần thiết để thực thi(compile) code.

Sự Tương tác giữa các node trong ROS

ROS computation graph là bức tranh toàn cảnh về sự tương tác của các nodes, topics với nhau.

19

Ở hình trên ta có thể thấy Master chính là nodes kết nối tất cả các node còn lại, các nodes còn lại muốn giao tiếp với nhau phải thông qua node Master.

Nodes: ROS nodes chỉ đơn giản là quá trình sử dụng ROS API để giao tiếp với nhau. Một robot có thể có rất nhiều nodes để thực hiện quá trình giao tiếp của nó. Ví dụ như, một con robot tự lái sẽ có những node sau, node đọc dữ liệu từ Laser scanner, Kinect camera, localization and mapping, node gửi lệnh vận tốc cho hệ thống bánh lái.

Master: ROS master đóng vai trò như một node trung gian kết nối giữa các node khác nhau. Master bao quát thông tin về tất cả các nút chạy trong môi trường ROS. Nó sẽ trao đổi chi tiết của một nút với khác để thiết lập kết nối giữa chúng. Sau khi trao đổi thông tin, giao tiếp sẽ bắt đầu giữa hai nút ROS. Khi bạn chạy một chương trình ROS, lúc nào ros_master cũng phải chạy trước. Bạn có thể chạy ros master bằng cách ->terminal->roscore.

Message: Các nút ROS có thể giao tiếp với nhau bằng cách gửi và nhận dữ liệu dưới dạng ROS mesage. ROS message là một cấu trúc dữ liệu được sử dụng bởi các nút ROS để trao đổi dữ liệu. Nó giống như là một protocol, định dạng thông tin gửi đi nữa các node, ví dụ như string, float, int…

Topic: Một trong những phương pháp để giao tiếp và trao đổi tin nhắn giữa hai node được gọi là ROS Topic. ROS Topic giống như một kênh tin nhắn, trong kênh đó dữ liệu được trao đổi bằng ROS message. Mỗi chủ đề sẽ có một tên khác nhau tùy thuộc vào những thông tin mà nó sẽ phụ trách cung cấp. Một Node sẽ đăng bài(publish) thông tin cho một Topic và một nút khác có thể đọc từ Topic bằng cách đăng ký(subcrible) với nó. Cũng giống như bạn muốn xem video của mình thì phải subcrible channel của mình vây. Nếu bạn muốn xem thử chương trình mình đang chạy có những topic nào, thì câu lệnh là rostopic list, nếu muốn xem một topic nào đó xem thử có những node nào đang publish hoặc subcrible vào nó. Thì câu lệnh là rostopic info /têntopic. Nếu muốn xem trong topic đó có gì thì type rostopic echo /têntopic.

Service: Service là một loại phương pháp giao tiếp khác với Topic. Topic
sử dụng tương tác publish hoặc subcrible nhưng trong dịch vụ, nó tương tác theo kiểu request – response. Cái này y chang như bên network. Một nút sẽ hoạt động như một server, có một server thường xuyên
chạy và khi Node client gửi yêu cầu dịch vụ cho server. Máy chủ sẽ thực hiện dịch vụ và gửi kết quả cho máy khách. Client node phải đợi cho đến khi máy chủ phản hồi với kết quả. Server đặc biệt hữu dụng khi chúng ta cần thực hiện một lệnh gì đó mà cần thời gian lâu để xử lý, vậy thì chúng ta để nó ở server, khi cần thì ta gọi.

 

Advertisements

RTAB-Map and Kidnapped Robot

One of the more difficult challenges in robotics is the so-called “kidnapped robot problem.”  Imagine you are blindfolded and taken by car to the home of one of your friends but you don’t know which one.  When the blindfold is removed, your challenge is to recognize where you are.  Chances are you’ll be able to determine your location, although you might have to look around a bit to get your bearings.  How is it that you are able to recognize a familiar place so easily?

It’s not hard to imagine that your brain uses visual cues to recognize your surroundings.  For example, you might recognize a particular painting on the wall, the sofa in front of the TV, or simply the color of the walls.  What’s more, assuming you have some familiarity with the location, a few glances would generally be enough to conjure up a “mental map” of the entire house.  You would then know how to get from one room to another or where the bathrooms are located.

Over the past few years, Mathieu Labbé from the University of Sherbrooke in Québec has created a remarkable set of algorithms for automated place learning and SLAM (Simultaneous Localization and Mapping) that depend on visual cues similar to what might be used by humans and other animals.  He also employs a memory management scheme inspired by concepts from the field of Psychology called short term and long term memory.  His project is called RTAB-Map for “Real Time Appearance Based Mapping” and the results are very impressive.

Real Time Appearance Based Mapping (RTAB-Map)

The picture on the left is the color image seen through the camera.  In this case, Pi is using an Asus Xtion Pro depth camera set at a fairly low resolution of 320×240 pixels.  On the right is the same image where the key visual features are highlighted with overlapping yellow discs. The visual features used by RTAB-Map can be computed using a number of popular techniques from computer vision including SIFT, SURF, BRIEF, FAST, BRISK, ORB or FREAK.  Most of these algorithms look for large changes in intensity in different directions around a point in the image.  Notice therefore that there are no yellow discs centered on the homogeneous parts of the image such as the walls, ceiling or floor.  Instead, the discs overlap areas where there are abrupt changes in intensity such as the corners of the picture on the far wall.  Corner-like features tend to be stable properties of a given location and can be easily detected even under different lighting conditions or when the robot’s view is from a different angle or distance from an object.

RTAB-Map records these collections of visual features in memory as the robot roams about the area.  At the same time, a machine learning technique known as the “bag of words model” looks for patterns in the features that can then be used to classify the various images as belonging to one location or another.  For example, there may be a hundred different video frames like the one shown above but from slightly different viewpoints that all contain visual features similar enough to assign to the same location.  The following image shows two such frames side by side:

rtabmap-image-match

Here we see two different views from essentially the same location.  The pink discs indicate visual features that both images have in common and, as we would expect from these two views, there are quite a few shared features.  Based on the number of shared features and their geometric relations to one another, we can determine if the two views should be assigned to the same location or not.  In this way, only a subset of the visual features needs to be stored in long term memory while still being able to recognize a location from many different viewpoints.  As a result, RTAB-Map can map out large areas such as an entire building or an outdoor campus without requiring an excessive amount of memory storage or processing power to create or use the map.

Note that even though RTAB-Map uses visual features to recognize a location, it is not storing representations of human-defined categories such as “painting”, “TV”, “sofa”, etc.  The features we are discussing here are more like the receptive field responses found in lower levels of the visual cortex in the brain.  Nonetheless, when enough of these features have been recorded from a particular view in the past, they can be matched with similar features in a slightly different view as shown above.

RTAB-Map can stitch together a 3-dimensional representation of the robot’s surroundings using these collections of visual features and their geometric relations.  The Youtube video below shows the resulting “mental map” of a few rooms in a house:

The next video demonstrates a live RTAB-Map session where Pi Robot has to localize himself after been set down in a random location.  Prior to making the video, Pi Robot was driven around a few rooms in a house while RTAB-Map created a 3D map based on the visual features detected.  Pi was then turned off (sorry dude!), moved to a random location within one of the rooms, then turned on again.  Initially, Pi does not know where he is.  So he drives around for a short distance gathering visual cues until, suddenly, the whole layout comes back to him and the full floor plan lights up.  At that point we can set navigation goals for Pi and he autonomously makes his way from one goal to another while avoiding obstacles.

RobotCup: The Future Champion League

RoboCup is an annual international robotic competition proposed in 1997 and founded in 1997. The aim is to promote robotics and AI research, by offering a publicly appealing, but formidable challenge. The name RoboCup is a contraction of the competition’s full name, “Robot Soccer World Cup”, but there are many other stages of the competition such as “RoboCupRescue”, “RoboCup@Home” and “RoboCupJunior”. In 2015 the world’s competition was held in Heifei, China. RoboCup 2016 will be held in Leipzig, Germany. The official goal of the project:

“By the middle of the 21st century, a team of fully autonomous humanoid robot soccer players shall win a soccer game, complying with the official rules of FIFA, against the winner of the most recent World Cup”.

As a Master student of Frankfurt University, I aslo have a project with the Robot who is the best choice for for the Robot Cup as the moment, his name is NAO.

NAO

Nao (pronounced now) is an autonomous, programmable humanoid robot developed by Aldebaran Robotics, a French robotics company headquartered in Paris. The robot’s development began with the launch of Project Nao in 2004. On 15 August 2007, Nao replaced Sony’s robot dog Aibo as the robot used in the Robot Cup Standard Platform League, an international robot soccer competition. The Nao was used in RoboCup 2008 and 2009, and the NaoV3R was chosen as the platform for the SPL at RoboCup 2010. Nao robots have been used for research and education purposes in numerous academic institutions worldwide. As of 2015, over 5,000 Nao units are in use in more than 50 countries.

RoboCup Standard Platform League: Goal Detection

Abstract—This paper presents a new fast and robust goal detection system for the Nao humanoid player at the RoboCup standard platform league. The proposed methodology is done totally based on Artificial Vision, without additional sensors. First, the goals are detected by means of color based segmentation and geometrical image processing methods from the 2D images provided by the front camera mounted in the head of the Nao
robot. Then, once the goals have been recognized, the position of the robot with respect to the goal is obtained exploiting 3D geometric properties. The proposed system is validated with real images by emulating real RoboCup conditions. Index Terms—RoboCup and soccer robots, Artificial Vision and Robotics, Nao humanoid, Goal Detection, Color Segmentation, 3D geometry.

A. Detection Based on Geometrical Relations
The first proposed method is intended to be robust and fast in order to overcome some of the usual drawbacks of the vision systems in the RoboCup, such as the excessive dependency of the illumination and the play field conditions, the difficulty in the detection of the goal posts depending on geometrical aspects (rotations, scale,. . . ) of the images captured by the robots, or the excessive computational cost of robust solutions based on classical Artificial Vision techniques. The proposed
approach can be decomposed into different stages that are described in the next subsections.
1) Color calibration: The first stage of the proposed method consists of a color calibration process. Thus, a set of YUV images acquired from the front camera of the Nao robot is segmented into regions representing one color class each.
Fig.2 shows an example image captured by the Nao robot containing a blue goal.
The segmentation process is performed by using a k-means clustering algorithm, but considering all the available centroids as initial seeds. Thus, in fact, seven centroids are utilized, corresponding to the colors of the ball (orange), goals (yellow and blue), field (green), robots (red and blue) and lines (white).
sensors-13-14954f7-1024

The first problem addressed in this project is the segmentation of the image to separate the object (in this case the goal) from the background. As the RoboCup rules specify that goals are painted either sky blue or yellow, a simple segmentation solution based on color has been chosen.  It can be assumed that normally no other objects of similar colors will be present in the picture taken from the camera. If a similar color object is indeed present, it will corrupt the segmentation result, and depending on is size or shape it can render the method inoperative.

Therefore, proper tuning of the segmentation parameters is mandatory to avoid these situations. The following figure shows the result of an ideal segmentation of a camera image.

Ideal segmentation (right) of the goal in the camera image (left).Edge_detection

Edge detection
Once the image is segmented to separate the goal from the background, one can attempt to extract the edges of the resulting binary image. This is done to reducethenumberoflinesdetectedinthefollowingHoughtransformstage, while retaining the structural information of the goal.

Ideal edge detection (right) of the segmented image (left).

Edge_detection1