Keywords

1 Introduction

Competitions have been broadly used as an effective venue for promoting scientific and technological progress in robotic research. Many robotic competitions are held around the world every year, such as RoboCup competition, DARPA Robotics Challenge, Robot Cleaning Competition [1]. Particularly for the domestic service robots area, RoboCup@Home has been widely considered as the most influential testbed. It’s nearly ten years since the first RoboCup@Home competition was held in 2006. Now we can clearly see the great advance that has been manifested by the competition in various robotic research including navigation, speech recognition, human-robot interaction and object recognition. Most recently, a survey article [8] has been published for comprehensively evaluating this progress over the past decade.

Although the RoboCup@Home competition indeed boosts the research on domestic service robots, it still has limitation in the aspect of scientific significance [1]. To address this, the RoCKIn project [10] has been proposed and aims to design and initiate a scientific robotic competition using the global Motion Capture System (MoCap), which can provide the ground truth of robot’s performance. The demo challenge on Benchmarking Service Robots (BSR) shares the same motivation to the RoCKIn. More importantly, it also proposes quantitative measurements for robotic research especially for low-cost platform.

The BSR workshop & demo challenge is a sub-event of RoboCup 2015, and successfully attracted ten teams to join in the competition lasting for three days. During the competition, our KeJia-LC robot demonstrated the abilities of 3D navigation, dynamic environment perception, accurate localization, etc. In the remainder of this paper, we will detail our robot hardware and software design that were developed for this competition.

2 Background of the Demo Challenge on BSR

The BSR competition has two main intentions that have been reflected clearly in the rules. Firstly, it attempts to accelerate the emergence of a standard mobile robot platform that should be low-cost, universal and extensible. Only a low-cost platform, at least not expensive, could possibly adapt to the affordability of different teams. The cost of the robots (shown in Fig. 1) in the RoboCup@Home league is usually higher than the acceptable level of some teams who are eager to participate. The expensive “threshold price” has been an issue hindering the further expansion of the RoboCup@Home league, and it is the reason why the cost of the robots in this competition is limited to a certain amount. Secondly, the BSR competition itself also intends to be more scientific, and even a benchmarking tool which could be treated as an objective performance evaluation of robot systems. As it is known, RoboCup@Home [12, 13] is more focused on assessing the performance of integrated robot system through executing several high-level tasks, sometimes the teams just know the results that they fail in tests, but it’s difficult for them to trace the causes and reproduce the runtime scenarios. The BSR competition utilizes a optical MoCap to obtain the ground truth of robot’s trajectories, which provide a possible method to evaluate robots’ performance using specific quantitative measurements.

At present stage, the rules of BSR competition mainly involve the precision of odometry, localization and navigation, the perception of environment and the reaction to dynamic change.

2.1 Rules and Skills

According to the rulesFootnote 1, the whole BSR competition is divided into two stages and a final. In Stage I, the teams are required to complete several simple tasks with odometer sensor under different load conditions, any other auxiliary sensors are prohibitive. The score of Stage I depends on the distance between the expected motion distance/angle and the actual measured values. In Stage II, robots are required to reach several waypoints in correct order under different load conditions. Between different waypoints, robots need to avoid different types of obstacles, such as hollow chairs, small objects and moving people. Perhaps, the most interesting obstacle is the double-arch door (shown in the Fig. 2), there are two slider beams in such a door and the height is adjusted randomly in the competition, hence the robot must decide whether and which channel it’s able to pass through. The score of Stage II depends on the number of the waypoints robots reaches successfully and the precision of the robots’ stopping positions. The form of the Final Stage is same with Stage II, but the degree of difficulty increases.

Fig. 1.
figure 1

Robots in RoboCup@Home 2015

Fig. 2.
figure 2

Double-arch door

Besides the mentioned rules, the robot must meet the cost restriction. Detailly, the hardware cost or the market retail price of the basic mobile platform should be less than 10,000 RMB (about 1,600 USD). Meanwhile, the price of any extended sensors should be not more than 50 % of the basic mobile robot platform. In addition, we also need to consider the load capacity of robot.

2.2 Different Requirements and Techniques with RoboCup@Home

Our team WrightEagle@Home have taken part in six consecutive RoboCup@Home competitions since 2010, all our related techniques are developed with the requirements of RoboCup@Home. In order to adapt to the new rules of BSR competition, we need to find out the unexplored technological demands.

Cost Restriction. The cost restriction has a great influence on the hardware design, we have to try out a set of hardware equipments which satisfy both the constrains of cost and performance. The situation of RoboCup@Home league is quite different, the teams are allowed to select any kind of equipment and sensors. In most case, a common laser scanner is much more expensive than the whole robot in the BSR competition.

Precision of Navigation. The BSR competition is more concerned about the precision of robot navigation, which directly determines the test score. Unlike in the RoboCup@Home competition, there is no specific restriction of reaching points, just within the tolerable range of where they are supposed to be.

Load Capacity. The load capacity of robot is seldom considered especially in domestic environment. In BSR competition, the mobile robot platform is expected at least to bear the weight of 20 kg (nearly the weight of a bag of rice), this regulation could be thought of increasing the versatility under different occasions.

Perception of 3D Environment. With the rapid development of sensor technology, many new 3D sensors (e.g., Microsoft Kinect, Xtion Pro Live) are emerging, which provide reliable perception of 3D environment. To perceiving obstacles in the BSR competition, the robots are strongly recommended to equip with additional 3D sensors rather than exclusive planar lasers. In fact, it’s also hard to perceive the dynamic changes with cheap laser scanner.

Uneven Floor. In the latest rulebook of RoboCup@Home [11], it notes that minor unevenness such as carpet, transitions in floor covering between different areas, and minor gaps are expected. But in setting of real competition area, these thorny things are avoided to the greatest extent. In the BSR competition, the robot are explicitly expected to step over unevenness with the maximal height of 3 cm.

3 Hardware Design of KeJia-LC

The KeJia-LC robot platform aims to be a low-cost, general and extensible robot chassis. As shown in Fig. 3, the shape of the chassis is a square box with size of \(50*50*30\) cm, which is suitable for passing across narrow passages and avoiding obstacles in common domestic environment. Under the metal shell of chassis, some metal strips constitute the framework of the platform, this structure gives the chassis good loading capacity (even the weight of an adult). In front of the chassis, there exists a groove with depth of 10 cm, it could endure heavy objects because the bottom of the groove is supported on the baseplate. The whole chassis is driven by differential structure, it consists two concentric wheels and a passive omni-directional wheel, which endows KeJia-LC platform with a good maneuverability and stability. On the chassis, an adjustable support bracket is fixed, where the two sensors (e.g., Kinect and laser scanner) are mounted.

Fig. 3.
figure 3

(a) The front of the chassis (b) The bottom of the chassis (c) The RPLIDAR laser scanner

In the hardware design of KeJia-LC, we have taken many issues into account, and some special concerns are listed as follow:

  1. (1)

    Selection Principles of Motor Drive: The motor drive system mainly includes three parts: electric motor, motor reducer and motor controller, each of them has influence on the performance of the mobile platform and the cost. The mobile platform is expected to have a powerful motivator, therefore we choose a homemade high-quality DC motor with considerable volume. As to motor reducer, we adopt the planetary reducer rather than the harmonic reducer for these reasons: (a) The price of harmonic reducer commonly is much more expensive than planetary, which will greatly increase the budget. (b) The platform may suffer violent vibration when moving on uneven floor, which will cause serious damage to harmonic reducer but less to planetary. The chosen motor controller has rich control interfaces, moreover its price is reasonable. In general, the cost of the whole motor drive system is about 3,000 RMB.

  2. (2)

    Selection Principles of Sensors: The extended sensors of KeJia-LC robot platform include a kinect and a laser scanner presently. The kinect has been widely used for 3D environment perception with many robots, and lots of related techniques have been developed, which are quite useful for our competition work. To seek for a low-cost, usable laser scanner is a quite hard job, fortunately, we found a product named RPLIDAR (shown in Fig. 3), it performs 360 degree scanning with the detection range of 6 m. With the usage of RPLIDARFootnote 2, we implemented our mapping, localization and navigation modules.

4 Software Design

4.1 Odometry Parameters Calibration

According to the rules of Stage I, only the robot has accurate odometry without external sensors could get a high score. To get a precise odometry of our robot, we need to determine which parameters should be tuned accurately. As illustrated in Fig. 4, the movement of the robot platform is composed by rolling of the two wheels. The trajectory of the robot in a short time is usually considered as an arc (Fig. 5), thus, the calculation formulas are derived as:

$$\begin{aligned} {\left\{ \begin{array}{ll} \varDelta \theta = (l_2-l_1)/d \\ \varDelta x = sin\varDelta \theta * (l_1+l_2)/2\varDelta \theta \\ \varDelta y = (1-cos\varDelta \theta ) * (l_1+l_2)/2\varDelta \theta \\ x^{'} = x - sin\theta * \varDelta y + cos\theta * \varDelta x \\ y^{'} = y + sin\theta * \varDelta x + cos\theta * \varDelta y \\ \theta ^{'} = \theta + \varDelta \theta \end{array}\right. } \end{aligned}$$
(1)

where \((x,y,\theta )\) is the odometry data at the last time, \((\varDelta x, \varDelta y, \varDelta \theta )\) is the tiny movement in the robot’s coordinate, the \((x^{'},y^{'},\theta ^{'})\) is the new calculated odometry data. Thereinto, the \(l_1, l_2\) get from:

$$\begin{aligned} l_i = \varDelta E_i*2\pi r/R\qquad (i = 1, 2) \end{aligned}$$
(2)

In Eq. 2, the \(\varDelta E_i\) is the increased position values of encoder i in one update cycle and the R means the reduction ratio. It’s obvious that the wheels distance d and the wheels radius r are the key parameters to the odometry precision.

Fig. 4.
figure 4

The structural model of differential wheels

Fig. 5.
figure 5

The motion model of differential wheels

In order to simplify the tuning operation, we divide the process into two steps. In the first step, we choose to obtain the true value of the wheels radius r, because the odometry is only determined by r when moving straightly. With the great deal of feedback data collected by the MoCap, it’s natural to the regard parameter tuning as a data fitting problem. We simply assume that the trajectories of robot straight movement are ideal lines, so just the displacements between the start positions and the stop positions need to be recorded by MoCap (ignoring the orientation). After the parameter r is determined, we command the robot to spin and collect the orientation measurements, then wheels distance d also can be computed with the same method.

4.2 Mapping, Localization and Navigation

Mapping Technique. The basic requirement of participants in Stage II is to navigate in the competition field autonomously. Before this, a presentation of the competition area should be built, hence the mapping technique is introduced. The particle filter based simultaneous localization and mapping (SLAM) [4, 5] methods have been proven to be effective and pragmatic in robotic applications, and many mature implementations are available online. These mapping techniques work well in our case in general, and some changes are made in accordance with the practical situation. The range of the RPLIDAR laser is limited (6 m), which is often let the robot to be “blind” in open area. Owing to the accuracy of the well-tuned odometry, even if the laser data provide no sufficient information to ascertain robot pose, our robot still could keep a confident estimation of its position for certain long distance.

Besides the 2D grid map, we also created the 3D map of the environment with Kinect. RGB-D mapping have been a hot research subject recently [2, 6], many algorithms are proposed. Here, we don’t focus on making new progress on RGB-D mapping domain, but try to apply the existing approaches to our competition work. The mapping method from RTAB-MAPFootnote 3 [9] is employed to align the point cloud frame to global coordinate, the outcome is the point cloud map of environment. The drawbacks of the point cloud map are that the sensor noise and dynamic objects can’t be handled directly and that it is not convenient to integrate with navigation module. After obtaining the point cloud map, we convert it to the OctoMap proposed by [14], which use a tree-based structure to offer maximum flexibility and updatability.

These two maps are created using different techniques and in the unified coordinate system, and in normal conditions, they are matched well with each other. Both maps describe the primary objects that rarely change in the environment, and the local map of navigation will be copied from the static maps and updated with the sensor data, which will be detailed in the next section.

Localization and Navigation. The localization is the prerequisites of accurate navigation. Our localization module is based on adaptive Monte Carlo localization method [3], which uses self-adapted particle filter to track the robot pose against a known 2d map. To acquire more precise pose, we add a scan match post-process with all the particles, which could eliminate the sampling error. The localization precision also depends on the resolution of the map, the resolution is usually set to 2–5 cm for common indoor environment. In consideration of the measurement accuracy of the cheap laser (\(1\,\%\) error within the range of 6 m), resolution lower than 2 cm is unnecessary for our application.

The major challenge of navigation module is to deal with the dynamic obstacles that can’t be perceived only by planar laser. With the 3D map of the environment built previously, we project the spatial obstacles onto a plane with regard to the height of the robot [7]. Similar to the previous researches, our navigation module is combined with global and local planners. The local planner is operated on a moving local map centered with robot, at the very start the local map is copied from global static map, then updated with the coming of laser data and kinect data. With all these techniques, our robot is capable of avoiding all kinds of dynamic obstacles and even pass through narrow “tunnels” – not to mention the particular double-arch doors in the BSR competition.

4.3 Coordinate Transformation Between MoCap and Maps

The purpose of Stage II is testing the precision of the robot’s stopping positions, which should be only affected by localization and navigation modules. But in fact, different teams have their own methods to build the maps of the competition area, it’s impractical to force all maps to be in a same coordinates with MoCap. Thus, 10 coordinate values (in the MoCap coordinate) of landmarks are given to the teams (shown in the Fig. 6), all the landmarks are apt to discern in their own maps.

Fig. 6.
figure 6

The red points are the 10 selected landmarks (Color figure online)

Once the coordinate values are provided, the transformational relation between MoCap and robot’s map can be uniquely identified by at least three pairs of matched points. In the real case, the mapping errors are not linearly distributed within the realistic scenarios. So, we should take full advantage of the 10 pairs of points to decrease the errors in the conversion.

As described above, we give a mathematical formalization of this problem. Let \(P_i = [x_i, y_i, 1]\) represent the i point in the MoCap coordinate, the \(P^{'}_i = [x^{'}_i, y^{'}_i, 1]\) indicates the i point in map coordinate, and our aim is to get a transfer matrix T that could minimize the Euclidean distance:

$$\begin{aligned} \hat{T} = \mathop {{{\mathrm{argmin}}}}{\sum _{i}(P_i \cdot T - P^{'}_i)^{2} } \end{aligned}$$
(3)

Given Eq. 3, the conversion error is suppressed fewer than 7 cm on average.

5 Competition Results

5.1 Competition Results

The competition field is shown as Fig. 7, the size of the area is about 7*7 m, covered by 12 distributed optical cameras of MoCap and 4 video cameras at each corner. A triple-marks set (Fig. 8) is installed on the robot, afterward, the robot will be regard as a rigid body attached with the set.

Fig. 7.
figure 7

The competition field of BSR

Fig. 8.
figure 8

The triple-marks set used for tracking robot’s pose

The Stage I. In the Stage I, we chose all three weight of loadings (10 kg, 20 kg and optional 40 kg) and the ultimate results are listed in the Table 1Footnote 4. The linear motion error is very small and neglectable with the well-tuned parameter (i.e., the wheels radius r). As to the rotate motion error, it’s much more intractable. Under the different loading conditions, the same wheels distance parameter d results in diverse errors, which may be caused by the unbalanced weight distribution. Solving this problem, we calculates a set of parameters in different loading conditions, and in the competition, we chosen a proper parameter d from the list according to the actual loading weight.

Table 1. Score statistic of our team

The Stage II and Final. Before Stage II, we controlled the robot to go around the competition to establish the 2D and 3D maps. To overcome the limited range of RPLIDAR, we made the robot to move close to the wall and obstacles. The outcomes of the mapping process are shown in Fig. 10, the resolution of both types of maps is 5 cm (Fig. 9).

Fig. 9.
figure 9

The 2D map of the competition field

Fig. 10.
figure 10

The 3D map of the competition field

Fig. 11.
figure 11

The robot is judging the state of the door

Fig. 12.
figure 12

The robot is passing through the opened door

Our advantage in Stage II and the Final is quite significant: our KeJia-LC robot platform could avoid the objects flexibly and distinguish the state of the double-arch door quickly (Fig. 11). Besides, the hardware superiority played an important rule, the ability of stepping over unevenness brought us extra bonus, making a big lead against all the other teams.

KeJia-LC robot reached all specified waypoints successfully and passed the arch-door twice smoothly, where the average error is about 8 cm, a little higher than the resolution of the maps. On the other hand, a frequently occurring flaw is that the robot has difficulty in making a fine-tuning when already near to the waypoint, sometimes the robot rotated slowly for a long time to find a better stopping position (Fig. 12).

6 Conclusion and Future Work

In this paper, we present our KeJia-LC mobile robot platform, which is specially designed for the demo challenge on BSR in RoboCup 2015. In order to achieve high score in competition, related modules (including mapping, localization and navigation) were developed and integrated according to the rules. Relying on the stable and splendid performance of our robot in competition, out team won the first place with a big advantage.

Although the contradiction between the performance and cost is inevitable, while it’s still possible to make a trade off. Our KeJia-LC robot is a try in this direction, the restriction of single sensor can be compensated with the data fusion from multiple low-cost sensors. How to adapt the mature robotic algorithms to new constrains is rarely explored and worth studying.

Inspired by the odometry parameters calibration, in the future, we could make a further step on the problem of parameter calibration, which is a universal issue, but it’s often solved by manual measuring presently. With the sufficient measurements provided by MoCap, at least all the kinematic parameters would be determined automatically.