Hardware and software architecture for Plexil-based, simulation supported, robot automation H´ector Fabio Cadavid Rengifo1 and Javier Alberto Chaparro Preciado2 Abstract—Some obsolete -but common- practices in the application of fertilizers and pesticides are causing serious environmental problems in Colombia; a situation that could be addressed by combining robotics and modern farming management principles, for example, the Precision Agriculture. This paper describes a novel application of Plexil -an experimental synchronous programming language developed by NASAfor robot automation in agriculture, supported by a simulation platform that allows quick prototyping of an automation plan, and a transparent integration of it on a physical robot. As a result, a methodology for evolutive robot development, and a case study with a real six-wheeled multipurpose agricultural robot are presented. Further applications of the simulation platform as a mean to easily introduce robotics engineers to alternative -and less error prone- programming models are also discussed.
I. I NTRODUCTION Colombia, when compared with more developed countries, could be considered as a modest one when it comes to advances in robotics applications. This may be due to several problems ranging from the small amount of research groups in the field and the lack of cooperation among them, to the lack of private investment in national technology. The departments of Computer Systems Engineering and Electronic Engineering of the Colombian School of Engineering have been working collaboratively in two strategic topics that could contribute to the above problem: Applied Robotics in the context of problems relevant to the country, and robust software technology for robotic automation[13], [14] that could lead to faster and safer production lines of automation solutions. This paper describes the results of one of the most recent projects created by both departments which aimed to the implementation of tools to support a revolutionary farming management concept: Precision Agriculture. Precision Agriculture, as literature indicates[2], is a farming management principle which aims at reducing the environmental load and the long-term sustainability of the agricultural production by applying fertilizers and pesticides only where they are needed, when they are needed. This concept is very relevant for Colombian agriculture, especially considering the reported impacts of the traditional fertilizers and pesticides application practices [7], [11] in this country. By considering that a precision agriculture automation solution requires making decisions concurrently with several 1 H´ ector Fabio Cadavid Rengifo is with Faculty of Computer and Systems Engineering, Colombian School of Engineering (ECI), Bogot´a, Colombia
[email protected] 2 Javier Alberto Chaparro Preciado is with Faculty of Electronic Engineering, Colombian School of Engineering (ECI), Bogot´a, Colombia
[email protected] c 978-1-5090-3787-2/16/$31.00 2016 IEEE
sensor readings and then take actions -also concurrently- with actuators, we evaluated a concurrent reactive programming language as a mean to define deterministic, clean (free of synchronization primitives) and robust automation plans: Plexil. The proposed Precision Agriculture solution is a sixwheeled rover with an active four-wheel steering system (see figure 1), which by the combination of sensors and visual stimulus, could -depending on which actuators are attached to the robot’s body- perform precision tasks over a terrain such as optimal seed planting, weed removal or pesticides dosage. By now, the proof of concept was the dosage of pesticides on a flat terrain, an so the prototype includes, as an actuator, a basic pesticide doser. Besides the developed control platform, and the robot itself, there were three important outcomes of the project’s research and development process described in this paper: • A Plexil-based control layer with a software architecture that allows to transparently switch the software components from a simulation environment to a real one. • A full-featured, cloud-based -and thus multi-platformdevelopment and simulation environment (supported by the software architecture mentioned above) for Plexilbased automation plans . • A streamlined process that, based on the loosely coupled control software architecture and the simulation platform, permitted the distributed and evolutive development of the hardware and software components of a Plexil-based automation solution. 6 1 3 4 2
5
Fig. 1. Precision Agriculture Robotic Prototype. (1) Pesticide doser, (2) dsPIC (actuators and sensors micro-controller), (3) Intel Edison SOC- System on a Chip- running Plexil’s Universal Executive, (4) Cameras for stereo vision, (5) Sonars for basic obstacle detection, (6) Laser scanner for indoor-360◦ . obstacles detection.
Listing 1. Sample PLEXIL Plan
SamplePlan :{ Concurrence { I n t e g e r x =10 , y = 2 0 ; ActionOne { s t a r t Lookup ( s e n s o r O n e >100) x=y ; } ActionTwo { s t a r t Lookup ( s e n s o r O n e >200) y=x ; } } }
In this example, the occurrence of an event like ’sensorOne==201’ would lead to a concurrent execution of ActionOne and ActionTwo. In a traditional asynchronous, threadbased programming language, this would lead (unless a proper synchronization is performed) to an unpredictable outcome
III. P RECISION AGRICULTURE P LATFORM DESCRIPTION A. Hardware and low-level control components
30º
The robotic prototype shown in figure 1 was built on the top of the SuperRover Kit 6x6 chassis, from MINDS-i, including R HS-485HB Metal Gear servomotors, a gearbox, two Hitec an electronic 300A ESC speed control and a 5000RPM DC engine. The two key features of this chassis for the intended application were: an independent suspension system with 2.5 inches of travel -to overcome small rocks in the field-, and a 4-wheeled steering system, which allows maneuvers with much smaller turning radius, as is depicted in figure 2.
cm
44
cmb
88
44cm
The Plan Execution Interchange Language PLEXIL is a synchronous reactive language developed by NASA to support autonomous spacecraft operations. It has been used on applications such as robotic rovers, a prototype of a Mars drill, and to demonstrate automation capabilities for potential future use on the International Space Station. Programs in PLEXIL, called plans, specify actions to be executed by an autonomous system as part of normal spacecraft operations or as reactions to changes in the environment. The computer system on board the spacecraft that executes plans is called the Universal Executive. A Plexil plan consists of a hierarchical set of nodes which represents a hierarchical decomposition of tasks. The leaf nodes represents primitive operations (variable assignment, command execution) whereas the intermediate nodes defines a control hierarchy of their descendants (e.g., concurrent or sequential execution). Each node is equipped with a set of conditions that trigger its execution, and -at any time-, it offers information about its execution state: inactive, waiting, executing, iterationend, failing, finishing or finished or -in case the node already finished its task-, the termination status: success, skipped, or failure. When events are reported by the external environment (sensors, timers, etc), the nodes triggered by such events are executed concurrently, updating local variables in the process -which could, in turn, lead to the change of status of other nodes-. However, although several events could be reported simultaneously, given that the Plexil semantics -and therefore the Universal Executive- are designed to consider the synchronous hypothesis [12], all the parallel operations will be perfectly synchronized and so will not arbitrarily interleave. The listing 1 illustrates a simple Plexil plan, defined as a tree (where the root is ’SamplePlan’) with two child nodes (’ActionOne’ and ’ActionTwo’) whose execution is defined to be performed concurrently when the environment variable ’sensorOne’ reaches a certain value:
due the race condition in the mutual assignment of x and y. However, a synchronous programming language like Plexil, accordingly with the Synchronous hypothesis, guarantees a consistent variable swap: when SamplePlan is FINISHED, x==20 and y==10. Besides this synchronous nature of Plexil, which avoids the need of synchronization primitives in the language, and guarantees determinism (in the absence of external events), another important property of this language is its relative validation and verification easiness. Unlike the conventional asynchronous/multi-threaded languages (C++, Python, Java, etc.), whose complexity makes formal verification and validation very difficult, Plexil was designed -from the beginningwith verification and validation in mind, which has led to a significant amount of scientific production in the field of formal methods. Such production ranges from the proposal of techniques for automatic validation and verification [6], [1], [3] to the elaboration of complete validation environments [14], [1], [13].
30º
II. P LEXIL AND U NIVERSAL E XECUTIVE OVERVIEW
a
35cm
Fig. 2. Kinematic model of the robot with the curvature radius of the robot trajectory using (a) only front steering at its maximum angle, and (b) both front and rear steering at its maximum angle.
A custom circuit board, powered by a dsPIC33FJ128MC802 micro-controller, was developed as a RS232-compliant interface for low-level commands such as sensors data polling and engines activation. As an environment for high-level control platforms, a X86 Intel EDISON-Arduino computer-on-module was mounted and connected with the circuit board through its UART serial interface. B. Software - high level control components. One of the goals of this project, as mentioned before, is the evaluation of the PLEXIL as a control technology for
Heading Latitude Longitude LeftSonarMeasure CenterSonarMeasure RightSonarMeasure BatteryLevel ...
StateValues PLEXIL-ADAPTER
Decoder
PLEXIL UNIVERSAL EXECUTIVE
Input
Output
MoveForward(power) MoveBackwards(power) OpenSprinkler() CloseSprinkler() TurnFrontWheels(angle) ...
Commands
Fig. 3. Loose coupled, general purpose Plexil Adapter, with an abstract I/O interface.
Sensors Pooling & encoding
Tx
PLEXIL UNIVERSAL EXECUTIVE
Rx
dsPIC
INTEL EDISON (X86) - Linux Yocto
PLEXIL-ADAPTER
conventional robotic tasks. In order to integrate this platform to the hardware elements mentioned above, and to speed up the process by permitting de development of control components when the robot is still not ready or not available, the following software arteficts were developed: 1) A low-level protocol module for the hardware microcontroller. This protocol defined to encode values read from the sensors in a sequence of smaller chunks of data (whose size is compatible with firmware’s serial communication capabilities), while identifying and handling potentially corrupted during its transmission. 2) A Plexil’s adapter that allows the interoperability between the high-level execution plan with the rover’s low level interface. This adapter wrap firmware’s features (e.g. actuators activation signals) as External Commands and sensor readings as Environment Variables that could be consulted (or fire actions) through Lookups. 3) A simulation platform that supports the development of the two previous items. 4) A set of Plexil plans that, based on the External Commands and Environment Variables supported by the adapter, allows the calibration of the simulation environment and the evaluation of the language elements and its semantics in relation with the hardware features.
Actuators Firmware
SERIAL GPIO INTERFACE
IV. S OFTWARE D ESIGN A. Loose-coupled Plexil Adapter In order to decouple the adapter’s development from the eventual testing environments that could be required during the robot development, the Plexil adapter developed for this project handles an abstraction of I/O operations, as is depicted in figure 3. In this case, the Inputs are sensors measurements and the Outputs are actuators activation requests. With this I/O decoupling strategy, it is possible to use the same adapter with Input/Outputs of different kinds, for different purposes. By now, two I/O interfaces were developed: - An I/O interface implementation that handles I/O from UNIX pipes. This interface allows for a basic Plan execution testing using STDIN or STDOUT (keyboard and screen) as I/O, but -most important- allows the communication with any third-party program that could evaluate and generate a Plexil plan’s inputs and outputs. - An I/O interface for RS-232 serial communication through Intel Edison’s GPIO1 . This is the interface used with the real robot configuration (as seen in figure 4), and with a replica of the robot’s firmware circuit (that uses LEDs instead of real actuators) that is used for communication testing purposes.
Plexil Plan
Edison File System
Fig. 4. The Plexil adapter using the Interface Implementation configured to communicate with the firmware in the dsPIC through Intel Edison’s GPIO, using the RS232 protocol.
real robot, but using the UNIX PIPEs’ adapter instead of the RS-232 I/O. With this configuration, and by connecting the adapter’s I/O PIPEs’ with WebSockets I/O channels, a communication with a simulation running in any web browser is established. At the client side, there is a HTML5/Javascript development and simulation environment that includes -by now-: • •
•
B. Universal Executive and Simulation Environment On the basis of the loose coupled Plexil adapter described above, a complete Cloud-based, multi-platform development and simulation environment was created. As can be seen in figure 5, the core of the simulation is based on the same binaries (Universal Executive and Plexil adapter) used by the 1 General
Purpose Input/Output
•
A Javascript port of the Box2D [5] physics engine. A online Plexil editor (figure 6) with syntax checking. The syntax evaluation is provided by the compiler included in the Plexil’s distribution used by the server-side software. A simulation of the real robot features (geometry and steering capabilities) defined as a Box2D element. An equivalent of the real robot’s firmware, translated to javascript. As mentioned before, such firmware includes: logic of signals encoding/decoding/checking and actuators activation requests. Based on this ’simulated firmware’, once the Plexil plan is executed, the expected behavior of the robot is shown from a 2D, top view perspective (see figure 7).
•
A simulation of proximity sensors by using raytracing’s features of the physics engine (as depicted in figure 8). IAAS
Client A Process Client B Process
WebSockets Controller
ST D IN
UNIX PIPES INTERFACE
ST D
PLEXIL UNIVERSAL EXECUTIVE
PLEXIL-ADAPTER
O U
T
Web Application Container
Internet
PHYSICS ENGINE ROBOT ENVIRONMENT
Client N Process SERVER FILESYSTEM
Sensors Pooling & encoding
Actuators Firmware JS
SIMULATION ENVIRONMENT CLIENT A
Plexil Plan
Fig. 7. Simulation environment that, while running the currently opened Plexil plan in the server side, shows the expected robot’s behavior. The white dots represents a pesticide application, and the two squares a simulated obstacle (which should be detected by robot’s sensors).
CLIENT B CLIENT N
Fig. 5. A high-level schema of the simulation architecture, based on the same adapter binaries used by the real robot. Instead of the RS-232 I/O adapter, the UNIX PIPEs adapter, connected to a Web clients through WebSockets channels is used. The client (the simulator) includes a web-based-physics engine, a simulated robot, and a JavaScript equivalent of robot’s firmware. Fig. 8. Simulation of the robot’s proximity sonars by physics engine raytracing capabilities.
•
Fig. 6. Plexil plans editor with an online syntax check.
The need to avoid unsafe/untested control code in the real robot that could lead to the damage of expensive (and some times irreplaceable) devices.
The activities diagram of the figure 9 describes how Hardware and Software development teams could start working, in a distributed way, with general specifications (robot geometry and features). In this process, the teams join when the control layer (software) has passed several low level communications (e.g. data encoding and transmission with a physical firmware replica) and behavioral (through simulations) tests, in order to perform a field test (in a real terrain). With the field test outcomes, both teams divide again in order to start a new development cycle to adjust the simulation parameters (to make it more precise) and make the required hardware adjustments.
V. S IMULATION - SUPPORTED ROBOT DEVELOPMENT PROCESS
VI. E XPERIMENTS AND RESULTS
An interesting outcome of the retrospective of several months of work in this first attempt to integrate a real robot with a control technology that has been evaluated mostly theoretically, is a methodology for the evolutive and incremental development of future Plexil-based automation solutions. This methodology, which is supported by the proposed software architecture and the simulation platform emerged from two important project constraints: • The need to avoid dependencies between hardware and software development teams to reduce scheduling risks and prevent idle resources.
In order to calibrate the simulation and make it closer to the real robot’s behavior (simulation parameters and robot geometry setup, in the process described above), a basic four-steps plan -where each step is performed for a fixed amount of time- was mounted on both the real and the simulated robot. Once the robot- after several mechanical and electronic adjustments- described the trajectory depicted by the simulator in the figure 10, parameters such as robot geometry, wheel steering limits and relative speed where tuned until a good approximation (less than 10 cm in each measure) was achieved.
Δh Δv
Δs
Fig. 10. Expected behavior of the tuning plan, and the measurements used to compare and adjust the simulation parameters. Distance traveled in a straight line for a fixed period of time: ∆s. Distance traveled in a relative x and y axis during a heading recovery, after the front wheels are kept rotated to the left, and then to the right for a fixed time:∆v and ∆h.
ObstacleDodgeAnd PesticideDosage
Heading
CenterSonar MeasuredDistance
Concurrence
Fig. 9. Retrospective of Robot development process HeadingLeft Fix
Once the simulator was calibrated, the automation plan depicted in figure 11 was loaded into the robot. This plan considered two environment variables: a heading value (angle relative to earth’s magnetic field’s north direction) and the sonar (proximity sensor) mounted on the front of the robot. As can been seen in the figure, the goal of this plan was to apply a substance trough a straight line, equidistantly. In order to move in straight line, and given that the wheels are not always perfectly aligned, the plan uses two concurrent ’fix’ nodes that corrects robot’s trajectory when is moving too much to the left or too much to the right. Although the sprinkler was not operational in the real robot when this test was performed, the measured distances between each pause were used to validate the equidistance property.
TurnFront Wheels
HeadingRight Fix TurnFront Wheels
Start
Obstacle Manouver
Move Forward
Wait
Sequence
Environment Variables Commands
LeftTurn TurnFront Wheels
Collision Detection TimedDosage
Timing Wait
OpenSprinkler
FrontWheel Recovery TurnFront Wheels
Fig. 11. Schematic representation of one of the Plexil plans created for field testing and the expected behavior. Full program listing is available at http://github.com/ECIRobotics/PlexilPlans/blob/master/DodgeAndTimedDosage.ple .
VII. R ELATED WORK AND D ISCUSSION Webot[10] was one of the first commercial 2D/3D simulation environments for robots development. It was created by Cyberbotics and up to today new versions has been continuously released. This simulator is focused on the simulation of robotics whose control is defined with the C, C++ or Java programming language by providing a a library of predefined actuators and sensors that could be cross-compiled between the simulation or the real environment. Gazebo [8] is another simulation package with a long trajectory in the field of robotics that aims to development of realistic worlds for
the robots by combining the Open Dynamics Engine (ODE) with the open source OGRE rendering engine. Recently, its popularity has risen after enabling its interoperability with ROS[9] -a popular robotic software development framework-, as it allows the simulation of robotic models whose control is supported by ROS’ components. The simulation platform described in this paper has a similar approach of the Gazebo/ROS platform, given that (1) it uses a simulated environment as the source of events and as the receiver of the generated actions, and (2) the actions are
generated by the same high-level software components (in this case, ROS drivers) that will be used by the real robot, but using a web based architecture. The simulation platform described in this paper, offered two specific advantages compared with similar works- during the development of the precision agriculture robot: • Given that the robot uses a custom firmware programming (instead of standard drivers, like the ones provided by ROS), and the fact that such firmware’s logic (low level commands and communication protocols) is defined in the simulation using an interpreted language (javascript), it was relatively easy to test and adjust such logic when it was needed. • During the development of the project, the web based architecture of the platform (which hides all the software installation and configuration complexity in the server side) allowed for quick and easy way to share and perform plan demonstrations among team members, and a ready-to-use environment where engineers could be introduced -through experimentation- to Plexil’s syntax and the reactive-synchronous programming model. • Although the simulation platform is still restricted to 2D, in this early stages of the evaluation of Plexil technology for precision agriculture -where the precision and efficiency of the displacements is a must-, it will result perfect for experimenting with most of the four-wheel steering control strategies proposed in literature[4], [15]. VIII. C ONCLUSIONS At this stage, the project was focused mostly in the development of the proof-of-concept of a hardware and software architecture supported by PLEXIL -a high-level synchronous programming language-. It is expected to continue this work in cooperation with an agriculture research group for the development of real precision-agriculture solutions, which will require the integration of specific soil-sensors (e.g. pH and conductivity), the development of more complex Plexil plans, and more static and dynamic -simulated and in-field- tests. However, it is important to mention that the proposed simulation platform is, by itself, an interesting contribution, as it is the first user-friendly, ready to use simulation environment for Plexil (Plexil distribution includes the RoboSim2 project, but it does not currently support the input of complex Plexil plans into its simulations). This platform could lead to a more friendly introduction -for researchers in robotics- to automation technologies like Plexil, and therefore, to the synchronous-reactive programming paradigm as an alternative for a simpler and safer robots automation. This platform could also be, in the future, a convergence point for all the theoretical work that has been done around Plexil and the current advances in applied robotics. This project is expected to continue evolving in parallel with the development of new precision-agriculture prototypes, so 2 http://plexil.sourceforge.net/wiki/index.php/Example
application: RoboSim
features like on-line robot customization, environment design, and even support to ROS drivers, will be included in future releases. It is also expected that this platform will support the Plexil’s developers community, by -for example- enabling the user to choose beta-releases of Plexil for the simulation, as this could be useful to simplify beta-testing and illustrate, with fully simulated scenarios, new features or potential problems. ACKNOWLEDGMENT The authors would like to thank the support of the Colombian School of Engineering (Escuela Colombiana de Ingenier´ıa) in the development of this phase of the project with resources of the 2014/2015 internal research call. R EFERENCES [1] Jason Biatek, Michael W Whalen, Mats PE Heimdahl, Sanjai Rayadurgam, and Michael R Lowry. Analysis and testing of plexil plans. In Proceedings of the 2nd FME Workshop on Formal Methods in Software Engineering, pages 52–58. ACM, 2014. [2] Rodolfo Bongiovanni and Jess Lowenberg-DeBoer. Precision agriculture and sustainability. Precision agriculture, 5(4):359–387, 2004. [3] G Brat, M Gheorghiu, D Giannakopoulou, and C Pasareanu. Verification of plans and procedures. In Aerospace Conference, 2008 IEEE, pages 1–8. IEEE, 2008. [4] Christophe Cariou, Roland Lenain, Benoit Thuilot, and Michel Berducat. Automatic guidance of a four-wheel-steering mobile robot for accurate field operations. Journal of Field Robotics, 26(6-7):504–518, 2009. [5] Erin Catto. Box2d physics engine. World Wide Web electronic publication, 2009. [6] Gilles Dowek, C´esar Munoz, and Camilo Rocha. Rewriting logic semantics of a plan execution language. arXiv preprint arXiv:1002.2872, 2010. [7] Juan Pablo Gonz´alez, Brigid Pacheco, Fernanda Viasus, and Karen Ayala. Movilidad de pesticidas en aguas superficiales empleados en agricultura y riesgos para la salud humana en la zona centro del departamento de boyac´a-colombia. L’esprit Ing´enieux, 3(1), 2012. [8] Nathan Koenig and Andrew Howard. Design and use paradigms for gazebo, an open-source multi-robot simulator. In Intelligent Robots and Systems, 2004.(IROS 2004). Proceedings. 2004 IEEE/RSJ International Conference on, volume 3, pages 2149–2154. IEEE, 2004. [9] Thomas Linner, Alaguraj Shrikathiresan, V Maxim, Bernhard Ellmann, and Thomas Bock. Modelling and operating robotic environments using gazebo/ros. In Proceedings of 28th International Symposium on Automation and Robotics in Construction (ISARC), June 2011, Seoul, Korea, 2011. [10] Olivier Michel. Webotstm: Professional mobile robot simulation. arXiv preprint cs/0412052, 2004. [11] P Orozco et al. Impacto ambiental de los fertilizantes en la agricultura con e´ nfasis en el cultivo de la papa. Technical report, 1995. [12] Dumitru Potop-Butucaru, Robert de Simone, and Jean-Pierre Talpin. The synchronous hypothesis and synchronous languages. The embedded systems handbook, pages 1–21, 2005. [13] Camilo Rocha, Hector Cadavid, Cesar Munoz, and Radu Siminiceanu. A formal interactive verification environment for the plan execution interchange language. In Integrated Formal Methods, pages 343–357. Springer, 2012. [14] Camilo Rocha, Cesar Munoz, and Hector Cadavid. A graphical environment for the semantic validation of a plan execution language. In Proceedings of the Third IEEE International Conference on Space Mission Challenges for Information Technology, SMC-IT ’09, pages 201–207, Washington, DC, USA, 2009. IEEE Computer Society. [15] Sachin Saxena, Vinay Kumar, Sarabjeet Singh Luthra, and Alok Kumar. 4 wheel steering systems (4was). 2014.
