Remotely Controlled Robot via Internet –
Anatomy of A Cross Atlantic Collaborative Project
Reinhard Schiedermeier , Ph.D
Department of Computing Sciences, Munich University of Applied Sciences
rs@cs.fhm.edu
Christopher Leung
Department of Computing Sciences and Information Systems, Kwantlen University College
Christopher.Leung@kwantlen.ca
Abhijit Sen, Ph.D
Abhijit.Sen@Kwantlen.ca
Department of Computing Sciences and Information Systems, Kwantlen University College
Abstract: The Remotely Controlled Robot project was initiated as part of The Canada-
EU Consortium on Computer Networks and Network Security Studies Program
established under the auspices of International Academic Mobility Initiative (IAM) [1]
- The Canada-European Community Program for Co-operation in Higher Education
and Training- , which encourages joint academic projects among higher education
institutions, training establishments and other organizations on both sides of the
Atlantic. The objective of the Remotely Controlled Robot project is to guide a mobile
robot operating in an unknown terrain to a given target location at a landing site from
a remote site via internet. The Canadian group controls the operation of robot in
Munich using software running in Vancouver, whereas the German group controls the
operation of robot in Vancouver using software running in Munich.
The project is developed, tested, and implemented cooperatively by student groups from
Kwantlen University College, Vancouver, and the Munich University of Applied Sciences.
The paper provides an overview of the project, discusses the strategies used in system
development and integration, outlines the challenges encountered in the application
development, and describes the successes that have been achieved.
Keywords: collaboration, internet, Java Programming, mobility, networks, RCX
Programming, robot.
1. INTRODUCTION
This collaborative project is sponsored by Canadian-EU Consortium on Computer
Networks and Network Security Studies. The aim of the project is to foster enhanced
global communication and cooperation and to lay foundations for students to participate
and learn the dynamics of developing projects with colleagues and partners based in a
geographically dispersed location. It is carried out cooperatively by student groups from
41
two institutions (Munich University of Applied Sciences, and Kwantlen University
College).
The German students undertook this project as a part of the course that is equivalent to a
"Projektstudium" (FWP-Fach, 4-stündig, mit Praktikum). The Kwantlen students
developed this project as a part of Web Programming with Java Course (INFO 3210).
The project was started in September 2004 with nine B.Tech (IT) students from Kwantlen
and about twenty students from Munich and completed in December 2004. The live
demonstration was done in January 2005.
2. LEARNING OBJECTIVES
Students who participate in the successful completion of the project will have reliably
demonstrated the ability to:
Design and code, and test applications that require network-programming
Understand and apply basic robotics algorithms
Design and implement fault-tolerant software
Plan and manage a non-trivial software project
Cooperatively work in teams distributed over the world
3. PROJECT OVERVIEW
This project involves the construction of mobile robots that can explore and navigate their
way under software control to target location, avoiding and extracting themselves from
any obstacles it encounters during its journey. The robot is remotely controlled via
internet. This project is very similar to the NASA Mars Lander. The objective is to guide
a mobile robot through unknown terrain from a landing site to a given target location. The
robot operates on a remote world ("Mars"), and is not physically accessible. For each
team, Mars is on the other continent.
The control software runs locally (on "Earth"). Each student group designs a mobile
robot, and each student group creates control software that directs the robot. The system
is required to run autonomously – no human interaction is permitted, once the robot is
deployed. The Canadian group's robot operates in Munich and is controlled by software
running in Vancouver. The German group's robot operates in Vancouver and is controlled
from Munich. The robots are designed using construction kits manufactured by Lego.
Major goals of the project are to:
work out a common design of the robot to be used in both Kwantlen and Munich
and construct the robot using the Robotics Invention System 2.0™;
discuss and agree on common technical conditions and interfacing requirements;
design and implementation of a mobile robot controllable through a network
interface;
42
design and implementation of control software, that evaluates sensor readings,
plans actions, and sends commands to the robot via internet; and
perform live testing with Remote Sites
.
The students build everything from the scratch: They design and construct robots, as well
as the software. The building material for the robots and compilers including standard
libraries for the software are provided. No other components are available.
4. TEACHING STRATEGY
In the beginning of the term, students were briefed about the scope and complexity of the
project. In order to provide students with basic knowledge in programming Robots, series
of mini lessons are organized [2]. The purpose of the mini lessons is to bring all
participants up to the same level of knowledge in important technical topics of
programming Robots. No hints or solutions specific to the project were provided. Instead,
these hands-on examples and procedures were provided to avoid students wasting time
and effort in unnecessary research and testing. The mini lessons covered the basic topics
of
Network programming including socket communication in Java; and RCX Programming
systems and their specific strengths and weaknesses.
5. TECHNICAL SPECIFICATIONS
The robot is built using two LEGO MINDSTORMS robotics sets. The sets allow
maximum freedom for design at a reasonable cost. The teams agree on a common basic
design. The design of the robot is kept as simple and robust as possible. To simplify
things, Mars is reduced to a square area of 3x3 meters size. The area is surrounded by a
wall. The objective is to move the robot from one corner of the area to the opposite
corner, and to stop there. Within the area a number of obstacles is scattered at random
positions unknown to the robot. However, it is guaranteed that there is some path from
the starting corner to the target corner. This eliminates any discrepancies involved in
turning. The brain of the robot, which is powered by the Lejos [3] operating system, is
called the RCX. The Lejos operating system provides API which is used with Java. The
robot communicates with the server via an infrared tower.
Software Architecture:
The architecture of the system is based on three software components:
Robot program: Within the robot a small program is running, that controls the
motors and reads the sensors. This program is constrained by the very limited
processing power of the LEGO RCX. The RCX, powered by the Lejos operating
system, serves as the brain of LEGO MINDSTORMS inventions. RCX is an
autonomous LEGO microcomputer that can be programmed using a PC. The
43
program developed on PC can be downloaded to the RCX using a special infrared
transmitter. RCX uses sensors to take input from its environment, processes data,
and generates output signals to turn motors on and off. Users first build their robot
using the RCX and LEGO elements. They then create a program for their
invention using RCX Code [4]. Their creation can now interact with the
environment, fully independent from the computer. This program runs on remote
university (Mars).
Proxy program: This program is required, because the LEGO RCX has no direct
connection to the Internet. This proxy program is running on a machine located
physically near the robot and maintains direct contact to the robot. The proxy
software forwards message from the Internet to the robot and vice versa via LEGO
IR tower. Its main task is to forward messages between the robot and home. This
program runs on remote university (Mars). The proxy program has two interfaces:
(1) It connects to the robot via the IR tower. The design of this interface is up to
each team and is independent from the other team.
(2) The proxy program offers a network server port, accepts requests on this port
and sends responses from this port. This protocol is common to all teams and is
agreed upon in the negotiation phase. Changes have to be endorsed by all teams.
Apart from the common protocol, the details of the design and implementation of
the robot proxy is up to each team.
Control software: The most demanding software component is running at the
home campus ("on Earth"). The control software has a permanent network
connection to the robot proxy on Mars. It receives sensors readings from the
remote robot via the proxy program and across the Internet, decides what to do
next and sends motion commands back to the robot and requests more sensor
readings. The control software will have to build a map of Mars and to do path
planning for the robot. The details of the design and implementation of the control
software is entirely up to each team.
From a network point of view, the robot proxy is the server (passively responding to
requests), and the control software is the client (actively emitting requests and processing
responses).
The above three software components should be as portable as possible. Ideally, they
should be independent of other tools, libraries, and of the operating system.
These components may be implemented in different programming languages, as each
team sees appropriate. Because the proxy and the robot program are loaded and run by
the Mars team, several thousand miles away, they have to be simple, stable and should
require only a minimum of maintenance.
44
Figure 1: Project Architecture
45
Physical set up:
Munich University and Kwantlen University College provide for the other side
a robot built according to the common design;
a Mars area about 3x3 meters size. The area is surrounded by fixed walls;
two opposite corners of Mars are designated as "landing site" and "target area".
Each is about 40x40 cm wide;
Mars is initially empty. Obstacles are placed at random on Mars;
a proxy computer, equipped with a LEGO IR tower, with a dedicated connection
to the Internet. Mars is completely within the IR tower's range; and
the proxy computer has a login for the remote team.
6. BENEFITS TO STUDENTS
The development and implementation of this project provided many benefits to the
students as they:
were able to design, build, and program robots collaboratively;
acquired skills in tools and technologies that could be used effectively in
future to develop distributed robotic applications;
effectively used different communication mechanisms , such as e-mail, chat to
coordinate activities of project teams of the two institutions;
appreciated the range of issues one has to deal with in planning the
architecture and technical requirements for application project that integrates
communications networking, programming, and controlling of embedded
systems;
reinforced technical and communication skills, integrated subject areas across
the computing curriculum and were motivated to improve their areas of
weakness;
learnt how to work collaboratively with other students to achieve a common
goal, manage time efficiently, work towards a deadline, and solve problems.
Students learned a lot about international cooperation, especially with a
remote group that can only be reached by email and video conferencing.
Additionally, it became obvious that theoretical knowledge of a topic is not
enough to reach a practical solution; and
obtained rich cultural and technical knowledge, improved team work, IT and
communication skills, through their interactions with faculties and students of
a different country, that could enhance their chance for future employability in
a global environment.
46
7. CHALLENGES
The students faced many challenges during the development and implementation of the
project:
Design and Building of robot: It took some time to design and build a robot
with the required features. Students faced issues with the robot’s speed,
movement, clearance, and infrared tower communication. After few rebuilds,
a rather exotic construction is chosen.
Software issues: Students found it demanding to solve a problem that spans
different levels of abstraction. On the low end the students had to invent a
protocol on single bits and bytes. On the other end they had to implement path
planning by using the Dijkstra A* algorithm. Many of the theories and
concepts the students had learned in earlier semesters were needed and put
into practical use.
Organisational Issues: The students first had to organize their teams. They had
to identify the various sub-tasks and assign them to team members. To make
progress, everybody had to take over a part of the problem that best matched
his level of experience and knowledge. This required an honest judgment of
everybody's own capabilities. Another problem is the tendency of some team
members to tackle problems all on their own, without proper communication
with the rest of the team. This went away after a while, as it became clear that
only a team as a whole can succeed, and that no single team member can solve
all problems alone.
Communication Issue: Email is the only means of communication among the
teams of each institution to resolve any problems during design and
implementation. Because of 8 hours time difference between the two cities
where the institutes are located, scheduling of test runs has been problematic.
Kwantlen students have to gather at 7:00am in the morning to execute test
runs with the Munich team at 3:00pm local time.
Project expectation: Students have to spend excessive amount of extra time
not only to get themselves familiarize with technology, but also to define the
scope of the project in cooperation with the team at each institution.
Restricted time frame: The semester at each institution start at different times.
The restricted and overlapping time frame of twelve weeks in the semester for
completion of the project forced the students to limit the functionalities that
could be deployed and delivered.
Student Learning Curve: As with any new and unfamiliar environment, there
are questions about the learning curve and skills required to get students up to
speed. Students have to spent considerable time initially to get the skill sets
required to develop the project. However because of previous programming
and networking background, students became productive within a short period
of time, and were able to develop components of project gradually.
47
Lack of prior experience: Students did not have experience in working in a
project of this magnitude and collaborating with teams spanning
geographically dispersed location. Many of the team members initially lacked
confidence, and felt they were inadequately prepared for such a significant
collaborative undertaking.
8. RECOMMENDATIONS
The teams of both institutions demonstrated their implementation successfully in front of live
audiences. The objective of the project was to provide students with opportunity to acquire
experience in collaborative project management, project design and implementation
involving teams based on different parts of the world.
However, there are number of issues that must be considered for the success of a
collaborative project of this kind:
The design and implementation of the project with teams from different
continents requires elaborate planning. The planning process must take into
account the operational diversity of each participating institution- differences
in semester start and end times, duration of a semester, examination schedules,
reading breaks, and holidays at these institutions.
The students lacked sufficient knowledge of all the available tools required for
the project. Adequate lecture time needs to be allocated in the beginning of the
semester to discuss the details of scope of the project and application
development environment, and to familiarize the students with the application
development tools and operating system for the Robotics Invention System
2.0™.
The faculties require sufficient time before the start of the project to perform
more initial experiments on their own with the Robotics Invention System
2.0™, thus enabling them to anticipate any technical problems that may arise
during design and implementation. Some of the erratic behaviors the systems
demonstrated during implementation may have been foreseen if more
experimentation is done by the faculties before project starts.
Students find it challenging to design, develop, and implement such a complex
project over a 12-week semester. Students have to put in many extra hours a
week outside of class researching, designing and testing for this project. They
have to solve many technical problems on their own. Although it has been a
great exercise for problem solving, students did not anticipate the degree of
personal commitment required to undertake this type of project when the
project teams are initially formed. The success of the project depends on our
ability to engage the most able and motivated students, and thus one should
seek out those who have broader technical interests.
48
Although students gain valuable experiences working on real projects in an
unfamiliar development environment, students need specific and detailed
guidelines in the beginning of the term outlining the expectations of the
project outcome. As the term progresses, instructors also need to monitor the
projects on a more frequent basis.
9. CONCLUSION
The Remotely Controlled Robot project gave students valuable exposure to tools,
techniques and constraints associated with designing and implementing embedded
system. Although the project has substantial requirements in terms of functionalities, the
simplicity with which one can develop distributed applications using LEGO®
MINDSTORMS™, enabled the project teams to implement the system within stipulated
time. There was some steep learning curve in the beginning of the project as members
were not familiar with tools and technologies of programming robots. No substantial
difficulties were encountered by the project team after the initial training.
There are unique challenges associated with enabling geographically distributed
development teams to collaborate on the same software project. The students involved in
the project have in general provided positive opinion about their experiences. The
emphasis on developing practical application with cross cultural global component has
positive impact on the students learning experience, and provided valuable skills. The
deployment of this collaborative project provided students opportunities to gain an
appreciation on diversity and exposure to global perspective in their field of study.
Moreover, this project helped students to expand their understanding and awareness of
another culture. Students are no longer limited to implement projects within the
boundaries of our classroom – they can now be involved in joint collaborative ventures
with others around the globe.
10.ACKNOWLEDGEMENT
We are very appreciative to all our student members of both Munich University of
Applied Sciences and Kwantlen University College who spent enormous amount of time
and energy to this collaborative project. Without their dedication and commitment, the
project would not have come to a successful conclusion.
49
11.REFERENCES
[1] International Academic Mobility Initiative
http://www.hrsdc.gc.ca/en/gateways/nav/top_nav/program/iam.shtml
http://www.kwantlen.ca/calendar/learning.html
[2] Mini Lessons
http://www.informatik.fh-muenchen.de/~schieder/robot/slide0008.html
[3] Legos Operating System
http://lejos.sourceforge.net/
[4] LEGO® MINDSTORMS™
http://mindstorms.lego.com/eng/products/ris/index.asp
Questions may be addressed to:
Dr.Abhijit Sen
Chair, Computing Sciences and Information Systems, &
Bachelor of Technology in Information Technology
Email: Abhijit.Sen@kwantlen.ca
Phone: (604) 599-2488, 599-2506
Fax: (604) 599-2279
Kwantlen University College
12666 – 72nd Avenue
Surrey, BC V3W 2M8
50