Lego Lab 18

Project conclusions

Date: 13 - January - 2011
Duration: 5 hours
Participants: Everyone

Goals for the lab session

• Discuss about the learning outcome of the project.
• Discuss how we have covered the course contents and fulfilled the learning objectives in the project.
• Discuss about the project presentation.
• Comment on further work, possible expansions and improvements to the current system.

Further work

In this section we have summarized the thoughts we have discussed after finishing the project. Some of these ideas could easily require an entire new 7-weeks project, but they are definitely interesting to highlight. We believe as well that our ideas for further work are tightly connected as well with the theory covered during the first part of the lectures. This makes them interesting inputs for further editions of the course.

• Improved simple navigation applying customized odometry or techniques like dead reckoning. We have seen that some errors were introduced while navigating and that had a relevant impact in the overall robot performance (especially in the finder robot). We believe that it is possible to create a simple and accurate positioning method using odometry and the readings provided by the tacho counters. An alternative approach would be to use inertial navigation (seen [5]) like dead reckoning. This technique consist on determining the position by considering an initial coordinate and computing the distance traveled by using speed estimates over elapsed time and course. We found how to implement dead reckoning for specific differential based robots in [1]. In expression 1 it can be seen how incremented position can be computed in terms of wheel radius (Rw), heading (tita), encoder ticks recorded for each motor (T1 and T2) and total number of ticks (Tr).

Expression 1: Dead reckoning expressions for a differential drive based robot. Source [1]

• Coded IR beacons to identify different objects. A possible approach to identify the objects is to emit a unique signal through the IR diodes attach to them. This would require a microcontroller responsible for coding the data and modulate it at a higher frequency (making transmission more robust to external IR signals). Robots should be equipped with an IR transducer and an additional logic to decode the signals. Whether this logic should be implemented in the NXT software or in a separate microcontroller attached to the robot is something that should have to be considered. In figure 1 two different IR beacons can be seen.

Figure 1: Simple coded IR beacons using 38kHz modulated pulses. Image source [2] and [3].

• Improved object signaling by adding several IR diodes to the sphere. At this point we have embed one IR unit in the objects (as shown in figure 2). This is a good solution if the robot is facing always the diode when it is approaching it. But what happen if the collector robot is approaching the object from behind? Since the IR beam is directed towards the other side of the object, it will be impossible to locate properly the object. The solution to this problem is to create a ring of IR diodes and place them around the objects body, as shown in figure 2. Covering the different object angles with separate diodes will allow the collector robot to approach the target from any angle.

Figure 2: Sketch showing the current and optimal arrangement of the IR diodes.

• Improved object gripper for the collector robot. The currently mounted gripper is purely mechanical. It is working properly most of the times, failing when the object is gripped in the extreme side positions. Improvements in the mechanics would avoid these problems. Different alternatives, like electromagnet based grippers (see Lego lab report 15) could be used to solve the problem in the case small magnets are attached to the object. In that case the collector robot would just need to approach the object and sweep the area with the gripper. Eventually the object would be attracted by the arm. This even solve the problem of requiring fine grained positioning techniques.

• More reliable and easily deployable  and expandable communication interface. The communication technology that we are using in this project is bluetooth. That technology was chosen because the NXT already integrates a bluetooth modem in the brick. We think that, even though it is a widely expanded technology, it is not the best communication interface for our robotic system. We found out that it is not easy to get the bluetooth connection up and running, and we had to spend a lot of time pairing and configuring the devices. A limitation on the number of bluetooth devices exists as well, since the maximum number of devices in a piconet bluetooth network is 8. An advantage of using bluetooth is that the TDM technique could be useful in real time applications, making access to the medium predictable, something that is not required in the project. As an alternative to this interface we have considered simple 802.15.4 modems, that could act as a transparent serial line between different robots. This technology was successfully used in one of the previous projects for the Lego lab course see [7]. A cheap modem that could successfully have been applied in this project is the Serie 1 Xbee modem from Digi, shown in figure 3.

Figure 3: Xbee modem with a serial input implementing 802.15.4 Image source [6].

• Use of calibrated light sensors. One of the problems that we detected was that the light sensors were presenting different and variable sensitivities (see lab report for session 14). A key improvement would be to substitute those sensor with more stable ones that retrieves the same reading given the same light intensity and conditions (ambient light, orientation, etc...).

• Positioning error correction. IR, light or color beacons with a small spot could be deployed in the arena (see figure 4). These spots would be reference points with a unique ID number, and known position by the robots deployed in the arena. Once the spots are detected by the robots, they will be able to look for the spot known coordinates in memory (see figure 5) and readjust robot position. This technique will help to cope with the accumulated error in the navigation.

Figure 4: Spot positioning deployment.

Figure 5: Coordinates look-up table.

• Consider cooperation at task level. At this point the system is implementing cooperation at goal level, which is collecting the objects. The robots are cooperating to achieve this goal by carrying out one task each: one finds and a second collects. A possible expansion to this project would be to involve a several robots to carry out the task of finding or collecting.

• Energy efficient robot. At this point the robots have been programmed with accomplishing the goal without considering any kind of energy optimization. Both finder and collector robots could be programmed with the energy saving issue in mind. Some of the ideas in this line would be:
• Deactivate unused sensors: turn of the light sensor and the ultrasonic sensor when the robot is returning with the object.
• Detect that the battery level is low so the robot can return to a charging or off point, without dying in the middle of the arena.
• Slowing the motor speed if low battery levels are detected. By applying this dynamic configuration the amount of time the robot can be operating is increased.

Conclusions

We have demonstrated how autonomous embodied agents [9] can be constructed and designed in terms of robots that cooperates in solving a specified task. We have succeeded to realize the selected project idea of a robot 1 finder and robot 2 collector that collaborates to identify objects in a marked arena and carries the objects to a location specified by a remote computer.

The robot design and implementation covers many subtopics from the course like: Sensors, Actuators, Localization, Navigation, Communication, PID Control, Subsumptional Architectures, Sequential and Reactive control strategies. We have learned that a reactive strategy composed by a number of behaviours in a subsumptional architecture [10] is good in case a plan cannot easy be made in advance for how to achieve a certain goal. This is the case for the robot 1 in finding the object inside the arena. The sequential strategy as described by Fred Martin [8] is good in the case a plan is given as for the robot 2 collector. It moves to the location of the identified object communicated by robot 1 and carries the object to a location communicated by a remote computer.

We are specially proud of:

• The way we solved how robot 2 could approach the object being able to grip it. This problem took us two lab sessions to solve. A solution was found when we made an active object and realized that the robot was following a flame much better than a normal light source. That lead us to create the IR beacons and using light sensors and a PID controlled regulator to get close to the object.

• The variety of the topics from the curriculum of the course that we have covered in the project and we succeed to complete the goal or our assignment within the time frame of the project.

What could be improved:

• Fix the bugs and issues listed for robot 1 and 2 in last lab session in making the solution more stable and reliable

• Being able to handle dynamically correction for drift of the position especially for robot 1

Since our robots are deployed on a physical environment and the purpose is to interact with it, the way the agents do this has been a key part of our work. This idea was part of the learning objectives of the course and it has been thoroughly exercised in this project. In previous lab reports we have elaborated on that, some examples could be how the readings coming from the sensors have been filtered and evaluated, how the environmental conditions have been compensated to offer good performance or how the gripper interface have been adjusted depending on the fixed position.

Most of the concepts introduced in the course lectures have been applied in this project. We have paid special attention to the control strategies thinking carefully whether sequential or reactive strategies should be used. We have applied as well the PID regulator concept in one of the robots in order to approach an object with fine grained precision. Additional concepts like communication or navigation have been used as well. We are particularly satisfied since this project, even though it might look simple, has served us to exercise the topics we have learned in this course.

We have learned that changes on the mechanics requires changes on the software that controls them. The changes could range from small repositioning of sensors or gearing modifications to more complex structural changes.

For each software modification, no matter how small it is, a new test in the arena is required. The idea is similar to the testing principles applied in the normal software construction field. The difference is that new tests in the robotics context imply a physical test setup and more time to evaluate whether the modifications have been successful or not. An additional difficulty to evaluate the changes and trace errors is that there is no way to debug code deployed in target while it is running. This is something straightforward in ordinary programming circumstances, but in this case additional software and hardware would be required (plus modifications at the electronics level of the NXT to support debugging interfaces like JTAG). Even though the idea is technically possible it is not feasible in this course.

We have found several limitations in the NXT platform. For example, the limited number of sensors that can be connected without using sensor multiplexers. In the case we would have had a more flexible platform, a more precise robot could have been developed. A similar problem appears with the number of actuators, which is reduced to three. All in all we have been able to create a system composed by two agents that fulfills the initial goal.

We have realized that experiments have been especially relevant while testing the robots and their performance. Therefore, carrying out measurements, designing the experiments considering environment and state of the device and analyzing data are valuable procedures. In a more complex project, statistics of the robot performance and percentage of success depending on object situation could have been an interesting analysis.

Reflecting upon the course and putting in perspective the project, we believe that this course could act as a meeting point for different fields and disciplines. We realized that ideas and techniques used in this project are coming from different courses followed so far by us. For example, embedded software architectures like state machines were studied in the course Embedded Real-Time systems. Different considerations about the positioning techniques have been taken from the course Pervasive Positioning. Different ideas about robot control were taken from Artificial Intelligence courses. Reflections about the communication interfaces available for the robots were made considering the knowledge we got from the Wireless communication course. As a general idea, it can be stated that robotics is a multidisciplinary area in which knowledge about different fields can be combined.

References

[1] Dead reckoning article in wikipedia. http://en.wikipedia.org/wiki/Dead_reckoning
[2] IR transmitters / virtual wall http://sites.google.com/site/irobotcreate2/createanirbeacon
[3] Mini IR beacon http://letsmakerobots.com/node/6737
[4] How we can make IR beacons with unique ID. http://diydrones.com/profiles/blog/show?id=705844%3ABlogPost%3A39610&commentId=705844%3AComment%3A56644
[5] Inertial navigation systems http://en.wikipedia.org/wiki/Inertial_navigation_system
[6] Xbee modems from Digi http://www.digi.com/products/wireless/point-multipoint/xbee-series1-module.jsp#overview
[7] Video showing ZigBee devices applied in a flock or robots. Project in the Embedded agents and digital control in a physical world course. January 2010 http://il.youtube.com/watch?v=gbet__yAOP8&feature=related

[8] Fred G. Martin,Robotic Explorations: A Hands-on Introduction to Engineering,vPrentice Hall, 2001.

[9] Embodied Agents (Wikipedia).
[10] Subsumption architectures (Wikipedia).