Case Study: Distributed Autonomous Vehicle Stimulation Architecture (DAVSA)

Transcription

1 Case Study: Distributed Autonomous Vehicle Stimulation Architecture (DAVSA) Mr Bojan Lovric; Dr William Scott Defence and Systems Institute, University of South Australia Mawson Lakes, South Australia 5095, Australia Mawson Lakes, South Australia 5095, Australia Abstract. Agent-based models are seen as useful to create modular, re-usable simulations. However, these simulations aren t typically created to operate in real-time and engage with elements in the real world, such as hardware-in-the-loop. This paper describes the development of a prototype agent-based model (ABM) that includes Lego NXT robots interacting with the agents. This acts as a case study that highlights the synchronization issues between systems that aren t built as real-time systems and displays the benefits that the agent-based approach provides. Built as a student project, the task for the students was to develop a system of dynamic processes that utilized the available robots to exhibit swarm behaviour in a distributed operational environment. 1. INTRODUCTION The Defence and Systems Institute (DASI) at the University of South Australia is currently engaged in research into the application of agent-based models (ABM) to represent complex systems. This research is intended to determine the benefits of ABM to Modelbased Systems Engineering and part of this research is the development of practical examples that can be used to demonstrate the benefits and exhibit the practice in an experiential manner. The case study described in this paper was developed by a group of final year students from the School of Electrical and Information Engineering. This group was assigned the task of developing a Distributed Autonomous Vehicle Stimulation Architecture (DAVSA) that would use an ABM (in this case Repast Simphony [1]) to control a group of robots. The initial set of robots was a set of Lego NXT robots but the system had to be developed to cater for alternate robot designs. The challenge for the students to overcome was to be able to integrate real-time systems into an agent-based simulation when neither are designed to interoperate. This enhances the two systems by enabling the simulation to interact with real-world events via the NXT robots. This creates a new simulation with hardware-in-the-loop and highlights some of the challenges to overcome. 2. OPERATIONS CONCEPT DAVSA is designed to operate simple robots in a swarm mode [2] to enable the group to achieve more than the sum of the individuals. In this case, the group is comprised of NXT robots and the ABM will control their actions to act in a coordinated manner. A restriction was placed on the design forbidding direct communication between the robots to force the architecture to use the ABM for all coordination and communication. All data must pass through the ABM to be distributed as the ABM considers appropriate. (This feature has the added bonus of allowing the ABM to introduce elements from other sources, such as agents representing virtual elements.) A Search and Recovery example was devised as the illustrating case study. Plastic balls were scattered in a predetermined area and the robots had to determine their locations and then retrieve them. The robot configurations were limited in that only one robot was able to retrieve balls. The other robots had sensors that could be used to determine the location of objects but were not able to retrieve the balls. Hence no single robot could find and retrieve a ball without assistance. The ABM then coordinated their actions to find the balls and retrieve them in the best possible time. The ABM was therefore required to: Coordinate the searching robots, Track the locations of detected balls, and Dispatch the retrieval robot. Success of the ABMs performance was gauged on ability to accurately track and manoeuvre the robots, the time taken to retrieve the balls, and the perceived group awareness shown to the external observers. This simulation enables the user/observer to explore search and rescue options in a virtual environment capable of utilising hardware for further system accuracy and thus be confident that the selected arrangement is both viable and beneficial before system development begins. 3. DESCRIPTION OF THE ABM TOOLKIT The operational concept has the ABM as the central point to the whole architecture. For this task, the group chose to use Repast Simphony as the ABM modelling

2 tool. Repast Simphony is a free to use open source modelling toolkit, developed by the Argonne National Laboratory, Argonne, IL and The University of Chicago, Chicago IL [1]. There are many agent-based modelling tools; however Repast Simphony is carefully designed to allow researchers to rapidly, and quickly develop complex model. This is achieved through the provision of graphical user interfaces, powerful scheduling functions, and rapid point and click modular development, with the option of development by coding directly as well. Quite often it is necessary to employ experienced programmers to develop complex models. This creates an issue for all other non-programming literate modellers as they can have difficulty understanding the implementation and making changes. The result is a gulf between modellers and programmers that needs to be breached. The Repast Simphony user friendly architecture addresses this issue and provides an effective way of developing models by modellers (researchers) with limited programming experience. This feature reduces this distance between modellers and programmers [3]. 4. SYSTEM ARCHITECTURE DAVSA requirements dictated that it must integrate the ABM with the robots. This is done through the utilisation of two communications media: Bluetooth and TCP/IP packet transfer protocols (as shown in Figure 1). The ABM communicates directly via TCP/IP to small robot control programs (one per robot) which then communicate with the NXT robots. This implementation is necessary to achieve flexible distribution of the system without limits caused by the Bluetooth hardware. The design is master/slave architecture with the user acting in a supervisory role. The master is responsible for acquiring information from both slave and supervisor and acting accordingly. The supervisor responsibility is to correct model parameters if unexpected events occur [4]. The ABM is the master with the control of the overall activity. The robot controllers and their associated NXT robots are slaves capable of sending data and executing ABM instructions. Due to the reactive nature of the robot implementation they are classified as a slave component of the system [5]. This type of architecture is well suited for the ABM approach as it allows for each vehicle to be highly autonomous and the ABM to learn how to utilise the robots in the most efficient manner. 5. SYSTEM HARDWARE The Lego NXT sensors [6] were found to be of low quality and precision, therefore third party sensors for the robots were obtained from Mindsensors [7]. Correct movement and orientation of the robots is essential to maintaining synchronisation between the real and virtual representation of DAVSA. To reduce errors associated with the orientation of the robots, electromagnetic compasses were used to track and update the vehicle s bearing. The NXT motors provide tachometer movement information precise to within 1 degree which was used to calculate the distance traversed forwards or backwards. The construction of each of the search vehicles utilised one of a variety of object detection sensors (one per robot). The sensors that were available to use were: A short range infra red sensor, A medium range infra red sensor, A long range infra red sensor, and An ultrasonic sensor. The experimental stages of research found that the infra red sensors proved to be more precise with better range than ultrasonic sensor. In addition to the wheeled search robots, a mapping robot was constructed on a turret (shown in Figure 2) to provide approximate locations of the balls within the field of operation, and this is achieved using an onboard vision subsystem, NXTCam v2 [8]. The subsystem is a self contained unit capable of tracking up to 8 different objects of a pre-specified colour. The main advantage of the vision subsystem is that it requires minimal processing resources from the NXT control brick, thus minimising robot processing requirements. The retrieval robot is also shown in Figure 2. This vehicle is equipped with a compass for orientation control, and a claw to collect and carry the ball. An infrared obstacle detector was added to confirm the final location of the ball for collection. Figure 1: DAVSA Architecture Figure 2: Mapping (above) and retrieving (below) robot

3 Figure 3: DAVSA software architecture 6. SYSTEM SOFTWARE At the top level, the DAVSA software architecture is comprised of two distinct components (as shown in Figure 3) the robot controller and the ABM. The ABM is a high level software component responsible for simulation, decision making and task allocation for the search and rescue scenario. There are three distinct agent types employed within the ABM: A broker agent, A Coordinator agent, and An NXT agent for each robot. The broker agent listens to the TCP/IP interface and spawns an NXT agent when a robot controller connects to the ABM. This enables dynamic creation of the agents without pre-supposing the number of available agents. The coordinator agent coordinates the activities from the available robot agents. Figure 4 shows how the ABM uses a cycle to process and decide on the information available. This is based on the OODA (Observe, Orient, Decide and Act) loop concept [9]. The figure shows that the coordinator agent gathers the information into a consolidated picture and then uses that information to decide the next series of actions for the robots. The coordinator agent is designed to be a collaborative learning agent [10]. It has to collaborate with the NXT robot agents to perceive the environment that is being viewed by them and can only influence the environment through the action through its control of the robots. The coordinator is also designed to be able to utilise learning algorithms to attempt to improve performance. These are yet to be developed but there are two ways the coordinator can be designed to learn. The first is for the overall selection and planning techniques. In this learning and adaptation system, the coordinator agent assesses the success of the methodology used to collect the balls in an attempt to find the most effective method. Techniques such as genetic algorithms can be used to evolve the Figure 4: Course of Action (COA) evaluation for single simulation tick

4 methodology to coordinate the robots over a series of missions to provide a comparative gauge of the available methods. This is useful in the system s application to MBSE as it shows that the ABM provides evidence of which method is the best when implemented in the real system. The second type of learning is to be able to adapt to the uncertainties in some of the robots and sensors data, such as position. Errors in robot movements can be detected and future commands to the robot subsequently modified to better maintain the synchronisation between the ABM and real world. The robot agents retain the latest state information from a robot and provide details to the coordinator agent of the robot s capability. They also communicate to the robot controller to initiate the actions dictated by the coordinator agent. The robot controller is responsible for individual robot control and monitoring. For every robot attached to the model, an instance of the robot controller must be active to bind them together. The secondary function of the robot controller is to display the vehicle status to the user for clarity of the activity along the communication channel. This function was necessary to see where problems resided when testing the combined elements. 7. LESSONS FROM DEVELOPMENT DAVSA posed many integration challenges, and through the development process numerous problems were faced while integrating and synchronizing robots with the ABM. Some of the main challenges were as follows. Integration of components from multiple vendors was a challenge as it took a good understanding of each to enable their use. DAVSA integrated Repast Simphony with Lego NXT robots that had Mindsensors equipment being driven by a dedicated operating system called Lejos [11]. These problems were overcome by appointing a single person from the team to coordinate the integration architecture early in the development who ensured the interfaces were defined and adhered to during the development [12]. These interfaces were designed to ensure that the components would operate properly once integrated. There are numerous lessons learned by the students during the progress of the project. Some that they have expressed that are pertinent include: Start defining a project early on and make sure that all stakeholders are fully engaged in order to maximise the understanding of what is desired and to ensure the best outcome from their perspectives. Through the life cycle of a system, there are hiatuses during the technical development (such as awaiting approvals or parts), which should be used on documentation and research. This keeps the subject fresh in team members minds and progresses the project s less pending aspects. However, caution is needed to keep a good balance between documentation and prototype development. A dedicated lab/workshop environment is an essential component of work as it saves time needed to pack and unpack. Also a dedicated environment is good for testing purposes as the system should be free from random interference sources. Creation of user friendly software installed on the robots that utilises the vendor provided robot buttons can save time as it might lead to easier initialisation of robots, and user intervention during testing procedures. 8. CURRENT AND FUTURE RESEARCH Current DAVSA research is focused on synchronization issues, and improvement in controlling the robot orientation and positioning. As the modelling scenario progresses the robot orientation and position errors experience a cumulative effect where the error (deviation from the issued task e.g. move forward and turn around) rises exponentially. One of the possible solutions in overcoming these issues is the implementation of a more accurate tracking mechanism. DAVSA effectively utilised compass and motor tachometer for robot movement and bearing orientation, and both components were used independently. A possible solution is to combine both compass and tachometer information creating a correlation algorithm in order to minimise practical errors. If the operational scenario allows for outdoor implementation, use of a GPS receiver could be installed to provide additional positioning data, allowing the DAVSA to overcome current real time synchronization and positioning issues. In this instance the GPS receiver could be used in conjunction with the compass and tacho sensors to provide an ideal orientation and positioning solution. The ABM architecture is designed in such a way that it allows for implementation of different robots once the appropriate agents have been developed. It is envisioned that in the future, other robots will be incorporated into the ABM. 9. CONCLUSION This paper has demonstrated how an ABM can be part of a hardware-in-the-loop application creating a practical example highlighting the benefits of using an ABM in conjunction with a small robot swarm. The ABM tool used is a non-real-time system, however this paper has demonstrated that dissimilar system components can be integrated, even though the components were not designed to work together. Overall, the system architecture was designed with a dynamic robot distribution in mind and to accommodate a very dynamic range of resources (robot) availability. It was demonstrated that the Lego hardware was adequate for prototype purposes, however the flexibility of DAVSA architecture will allow for relatively easy changeover to different robots/hardware.

5 10. REFERENCES 1. Repast Simphony Hinchey, M.G.; Sterritt, R.; Rouff, C, Swarms and Swarm Intelligence, Volume 40, Issue 4, April 2007 Page(s): North, M.J., T.R. Howe, N.T. Collier, and J.R. Vos, "Repast Simphony Runtime System," in C.M. Macal, M.J. North, and D. Sallach (eds.), Shoval, S., 2008, Coordinated Tasks Allocation in Dynamic Environments, Proceedings of 2008 IEEE International Conference on Distributed Human-Machine Systems (DHMS 2008), Divani Caravel Hotel, Athens, Greece, 9 to 12 March 2008, pp S. 5. Kudomi S., Yamada H., Muto T., Development of a Hydraulic Master-Slave System for Telerobotics, Proc. of 1st FPNI-PhD Symp. Hamburg 2000, pp Lego NXT Mindstorms: lt.aspx, viewed on 13 January Mindsensors: viewed on 8 January Mindsensors: =pagemaster&page_user_op=view_page&pa GE_id=78, viewed on 8 January Boyd, John "Patterns of Conflict" presentation viewed on 14 January Knowledge Engineering Review, Vol. 11, No 3, pp.1-40, Sept Cambridge University Press, Lejos viewed on 13 January Benjamin S. Blanchard and Wolter J. Fabrycky (2006). Systems Engineering and Analysis. 4th ed. USA: Pearson Prentice hall