presentation @ miniscuola woa 2015

Experiences in programming robotic systems for competitions: approaches, languages and tools

Experiences in programming robotic systems forcompetitions: approaches, languages and tools

Corrado Santoro

ARSLAB - Autonomous and Robotic Systems LaboratoryDipartimento di Matematica e Informatica

Universita di Catania, [email protected]

Miniscuola WOA 2015 - Napoli, Italy, Sept. 19, 2015

Corrado Santoro - Programming Autonomous Robots - Miniscuola WOA 2015 1


Outline

1 Robotic Competitions: AnOverview

2 UNICT TEAM: a show reel

3 Architecture of the Robots

4 Robot Behaviour Basics

5 The Erlang/ERESYE Era

6 The Python/PROFETA Era

7 The C++/GOLEM Era

8 References



Robotic Competitions: An Overview

What are “robotic competitions”?

Robotic Competitions are challanges in which participantsare asked to design and build one or more robots which mustperform specific tasks, according to certain pre-defined rules.

They are games inspired from real-life situation and(possibly) with real-life applications.

Several kind of robotic competitions:

Real robots vs. Virtual robotsFixed rules vs. New rules at each editionFixed robotic platform vs. Free robotic platform




Are “robotic competitions” worth?

They are ... funny!

They make some courses more attractive by means of theapproach practice-and-learn

They make research more attractive and productive sincethey are a concrete testbench for new solutions andalgorithms (not a simple “case-study” for the papers)

They stimulate students and research institutions to comparesuch solutions and algorithms

They help to spread knowledge and improve knowledge andpeople exchange




A very famous example: RoboCup

Several competition types with several leagues:

Soccer, soccer championship with teams composed by severalrobotsRescue, find and rescue a “victim” in a hard and complexenvironment@Home, perform assistance tasks of typical home environmentenvironment@Work, perform assistance tasks of typical work environmentenvironment

Real robots, fixed rules, both fixed and free robotic platforms

Pros: you always know what to do, you can reuse robots,after a startup phase, you can focus on software alone

Cons: high budget required (at least in the team startupphase), experienced teams are hard to beat




A less famous example: Eurobot

Competition based in Europe (but open to the rest of the world),born as an evolution of the “Coupe de France de robotique”

Real robots, new rules at each edition (based on a specific “theme”chosen by organizers), free robotic platforms

Two teams per match, 90-seconds per match

One or two robots per team

Aim:

retrieve specific objects placed in the playing arenasometimes stack themput them in certain zones of the playing arenaperform additional specific actions

Pros: low budget possible, easy to gain experience

Cons: robots must be re-though at each edition, skills inmechanics, electronics and (of course!) programming are required




UNICT and Eurobot

University of Catania started participation in Eurobot in 1998 with ateam of students of Automation Engineering course

Since 2008, a “University Team” (UNICT TEAM) has been formed,made of students coming from

Computer EngineeringAutomation EngineeringElectronic EngineeringMechanical EngineeringComputer SciencePhysicsMathematics

A robotic lab is started, at the Dipartimento di Matematica eInformatica: ARSLAB (Autonomous and Robotic SystemsLaboratory)

Aimed at education and research activities in therobotic/autonomous systems area



UNICT TEAM: a show reel

UNICT and Eurobot

UNICT TEAM: a show reel of some competitions



Architecture of the Robots

Basic Architecture

Drive StructureTwo independent wheels, with DC motorsTwo passive feedback wheels, with quadrature encodersOne or more passive omniballs as additional points of contact

SensorsPhotoelectric, IR, Laser, Utrasound, color sensors for gameelement and opponent detection

ActuatorsServo-motors to drive arms of various kind or end-effectorCompressors for vacuum suckersAir-tank for air-compressed actuations




Basic Architecture—Electronics

A real distributed system: several CPU-based small specialisedperipheral boards, interconnected through a communicationline, plus a main “brain” board, running the“intelligence/strategy”.

Peripheral boardsMotion Control (one)Servo Driver (several)Remote I/O (several)Opponent detector (one)

Peripheral board platformMicrochip dsPIC33F Microcontroller family40 MIPS @ 80 MHz clockProgrammed in C/C++ with microchip XC16/XC++16 inbare metal




Basic Architecture—Electronics (II)

A real distributed system: several CPU-based small specialisedperipheral boards, interconnected through a communicationline, plus a main “brain” board, running the“intelligence/strategy”.

Communication SystemRS485, with ad-hoc master-slave protocol (until 2011)CAN BUS (since 2012)

Main board platformEmbedded-Linux (Debian) system w/Cyrix CPU (until 2009)Embedded-Linux (Debian) system w/ARM9 CPU (2010, 2011)dsPIC33F, bare metal (since 2012)FPGAs (near future!)




Software Platforms

Embedded-Linux (Debian) systemw/Cyrix CPU (until 2009)

Erlang with ERESYE tool

Embedded-Linux (Debian) systemw/ARM9 CPU (2010, 2011)

Python with PROFETA tool

dsPIC33F, bare metal (since 2012)

C++ with GOLEM tool

Why don’t we use Java???—Nothanks, I prefer to remain alive! :-)

Basically for performance reasons—notso high speed clocks, low amount ofmemory



Robot Behaviour Basics


Given a goal to accomplish....

1 Sense the environment

2 Check/evaluate own state

3 Determine the actions

4 Execute the actions

Step 3 is the most important: how actions are chosen isfundamental to successfully and effectively reach the goal.




Determine the actions

Roughly speaking, determining the actions implies to execute aseries of “if” with conditions on sensor outputs and robot’sstate.�for (;;) {

...

if (state == CAPTURE && object_caught () && number_of_objects == 3) {

state = DEPOSIT;

move_to(DEPOSIT_POINT );

}

else if (state == DEPOSIT && current_position == DEPOSIT_POINT) {

release_all_objects ();

...

}

...

}� �While programming in such a way is possible, it is not worth!.

Different (and better!) abstractions are needed.




Robot Behaviour and Implementation

We need ...

How to represent the environment

How to represent robot’s state

How to represent sensed data

How to express the way in which to determine the actions



The Erlang/ERESYE Era





Logic-based Robots

A possible know solution is to use a logic-based approach,borrowed from the world of expert systems:

Facts to represent:

the environmentrobot’s statesensed data

Production rules on fact to determine new facts and theactions to do

Given the model, we must do the implementation ...




The Erlang Language

Erlang is a functional and concurrent language developed by Ericssoninitially to program telecommunication apparatus.

Currently employed in many production environment, in the field ofdistrbuted/networked system, with high fault-tolerance requirements.

Characteristics:

Prolog-like syntax

Functional semantics: different function clause with nativeclause-matching mechanism

Functional datatypes:

BigintsListsAtomsTuples




Erlang: Some Examples

�fact (0) -> 1;

fact(N) when N > 0 -> N * fact(N - 1).

dup_list ([]) -> [];

dup_list ([H | T]) -> [H * 2 | dup_list(T) ].

area({square , Side}) -> Side * Side;

area({triangle , Base , Height) -> Base * Height / 2;

area({rectangle , Base , Height }) -> Base * Height.� �




Erlang: from functional to logic

Facts: atomic forumlae with ground terms or free variablesrepresented as Erlang tuples, e.g.

{position, 1050, 1000}{position, X, Y}{number of objects, 3}{object got}

Production rules, represented as erlang function clauses:�behaviour ({ in_capture}, {object_caugth},

{number_of_objects , 3}) ->

...

behaviour ({ in_deposit}, {position , 1050, 1000}) ->

...� �Corrado Santoro - Programming Autonomous Robots - Miniscuola WOA 2015 20



Towards ERESYE

�behaviour ({ in_capture}, {object_caught},


...

behaviour ({ in_deposit}, {position , 1050, 1000}) ->

...� �While Erlang tuples, atoms, and function clause syntax helpsa lot in expressing facts and productions rules, a futher step isrequired:

Facts must be stored and handledFunction clause, to be treated as rules, must be selected onthe basis of the facts stored

The ERESYE system (ERlang Expert SYstem Engine) hasbeen designed for such a purpose.




ERESYE

ERESYE is an Erlang library to write and execute InferenceEngines.

It provides:

A fact database with an API for its manipulation (assert,retract, replace, etc.)An introspection engine, to analyse Erlang function clausesrepresenting rules in order to build a matching tree, accordingto the RETE algorithmAn execution engine which, each time a fact isasserted/retracted/changed, matches the proper functionclauses (by exploiting the RETE algorithm) and prepares it forexecution as a normal Erlang function.ERESYE adds logic capabilities to Erlang: user can add aninference system to an Erlang application by using the samelanguage.




ERESYE and our robot

Sensor data and environment representation is done by meansof facts;

Behaviour is modeled by means of a finite-state machine;

For each state, a single function (whose name is the name ofthe state) with multiple clauses is employed;

To change state we deactivate a certain function and activateanother one.




ERESYE and our robot�in_capture(E, {object_caught} = X,


eresye:retract(E, X),

eresye:deactivate_rule(E, in_capture),

eresye:activate_rule(E, in_deposit),

robot:move_to (1050, 1000);

in_capture(E, {object_caught} = X,

{number_of_objects , N} = F) when N /= 3 ->

eresye:retract(E, X),

eresye:replace(E, F, {number_of_objects , N + 1}).

in_deposit(E, {position_got} = P) ->

robot:deposit_objects (),

eresye:retract(E, P),

eresye:replace(E, {number_of_objects , 3},

{number_of_objects , 0}),

eresye:deactivate_rule(E, in_deposit),

eresye:activate_rule(E, in_capture ).� �Corrado Santoro - Programming Autonomous Robots - Miniscuola WOA 2015 24


The Python/PROFETA Era





The evolution of ERESYE....

In 2009 we got an interesting result:We won the Silver Medal at the InternationalCompetition!! So it’s time to change!!

Seriously...

We decided to move to a ARM9-based embedded board,mainly for power consumption reasons (power changed from12W to 2.5W)

The chosen board run ARM-linux but an ARM-based ErlangVM was not available (and a porting work appeared too hard)

We evaluated some other solution, but we wanted to try tokeep the same approach of Erlang/ERESYE




...from Erlang to....

We analysed other programming language/platform, able torun onto ARM-linux

Python appeared a good solution

As for the agent model... is the pure-logic approach enough?

The Belief-Desire-Intention model appeared very interesting

And we looked at AgentSpeak/JASON with interest




(Overview of AgentSpeak)

In AgentSpeak, an agent has a knowledge, made of a set ofbeliefs and a program is a set of plansEach plan has the following structure:

A trigger event: belief assert/retract, goal achievementrequest, goal failureA condition: a first-order logic predicate on beliefs knownA list of actions: which can be a simple atomic action, beliefassert/retract, goal achievement request, goal abandon�

+object_caught () : number_of_objects (3) <-

move_to (1050, 1000);

+object_at(X,Y) : object_got(no) <-

move_to(X, Y),

~pick_object ();� �An implementation of AgentSpeak is provided in Java withJASON




... Python!

Could we write declarative AgentSpeak constructs “a la”Erlang + ERESYE in another language? And what language?

By exploiting OO features, and in particular operatoroverloading, we noticed that we could write expresson as:�+object_caught () / number_of_objects (3) >>

[ move_to (1050 , 1000) ]

+object_caught () / number_of_objects("X") >>

[ "X = X + 1", +number_of_objects("X") ]� �This is a valid python expression and, if data type areproprely chosen, it can be interpreted and executed by aPython-based system.




Towards PROFETA

PROFETA (Python RObotic Framework for dEsigningsTrAtegies) is Python tool for programming autonomoussystems (agents or robots) using a BDI-based declarativeapproach.

It provides an “all-in-one” environment supporting bothimperative (algorithmical part) and declarative (behaviouralpart) programming models:

A set of classes to represent basic BDI entities, i.e.

Beliefs ⇒ KnowledgeGoals ⇒ States to be achievedActions ⇒ Things to do to reach the Goals

A declarative language—dialect of AgentSpeak(L)—to expressagent’s behaviourAn engine executing that behaviourA Knowledge base storing the beliefs




PROFETA Declarative Syntax

A PROFETA behaviour is a set of rules in the formEvent ′′/′′Condition′′ >>′′ set of Actionwhere:

Event can be: belief assert or retract, goal achievementrequest, goal failure.Condition refers to a certain state of the knowledge base.Action can be: belief assert or retract, goal achievementrequest, user defined atomic action.

Example:�+object_at("X","Y") / object_got("no") >>

[ move_to("X", "Y"), pick_object () ]� �Such expressions are managed thanks to operatoroverloading




Beliefs

A belief is defined as a subclass of Belief

In a rule, it is referred as an “atomic formula” with:

one or more ground terms, e.g. object at(123, 456)

one or more variables, e.g. object at("X", "Y")

A variable is expressed using a string starting with capitals

Within the set of actions:

+bel(...) asserts a belief in the KB-bel(...) retracts a belief from the KB

As trigger event:

+bel(...) triggers the rule when the belief is asserted-bel(...) triggers the rule when the belief is retracted




Actions

An action is defined as a subclass of Action

The execute() method has to implement the computationwhich concretely performs the action; such a computation isexecuted atomically

In a rule, it is referred as an “atomic formula” with:

one or more ground terms, e.g. move to(123, 456)

one or more variables, e.g. move to("X", "Y")

A variable is expressed using a string starting with capitals

In method execute() terms can be accessed asself[term index]




Goals

Goals are (according to AgentSpeak(L)) “states of thesystems which an agent wants to achieve”, but indeed ...

... a goal is something like a “procedure plan” which expressesthe things to do to achieve the goal itself.

In PROFETA, a goal:

is first defined as a subclass of Goalit is expressed, in the plans, as an “atomic formula”, with zeroor more terms.




Sensors

While Actions can be used to intervene onto theenvironment, to sense it, a Sensor class is provided.

A Sensor class allows the programmer to write the propercode to sense the environment and generate the proper beliefs.

The programmer has to:

subclass Sensoroverride the sense() methodinform the Engine that a new sensor has been added in theprogram.




Example: An “Object Picker Robot”

A wheeled robot living in an environment

Equipped with a camera able to identify the objects to bepicked

Able to carry at most 10 objects in its tank

Behaviour: find the object, reach it, pick it, and, when youhave 10 objects in the tank, go to release them.




An object picker in PROFETA

�from profeta.lib import *

from profeta.main import *

# Beliefs

class object_at(SingletonBelief ): pass

class objects_gott(SingletonBelief ): pass

class target_got(Reactor ): pass

class robot_position(SingletonBelief ): pass

# Goals

class find_next_object(Goal): pass




An object picker in PROFETA�...

# Actions

class activate_camera(Action ):

def execute(self):

# ... activate the artificial vision system

class move_to(Action ):

def execute(self):

# ... perform movement to x,y

class drive_arm(Action ):

def execute(self):

# drive the arm to pick object

class release_objects(Action ):

def execute(self):

# drive the arm to release objects





�...

# Sensors

class CameraSensor(Sensor ):

def sense(self):

# do object sensing

class MovementPerformedSensor(Sensor ):

def sense(self):

# check if a movement has been performed

...� �




An object picker in PROFETA�...

PROFETA.start ()

find_next_object () / objects_got (10) >> [ move_to(0, 0) ]

find_next_object () / objects_got("_")) >>

[ activate_camera () ]

+object_at("X", "Y") >> [ move_to("X", "Y") ]

+target_got () / (object_at("X", "Y")

& robot_position("X", "Y")

& objects_got("N") >> [ drive_arm(),

"N = N + 1",

-object_at("X", "Y"),

+objects_got("N"),

find_next_object () ]

+target_got () / robot_position (0,0) >> [ release_objects (),

+objects_got (0),

activate_camera () ]





�...

PROFETA.assert_belief(objects_got (0))

PROFETA.add_sensor(ObjectSensor ())

PROFETA.add_sensor(MovementPerformedSensor ())

PROFETA.achieve(find_next_object ())

PROFETA.run()� �




A futher step

In 2011 we got an interesting result:We won the Silver Medal at the Swiss Championship and atInternational Competition!! So it’s time to change again!!

Seriously...

We decided to move to a dsPIC33F-based board, mainly for spacereasons

The board is programmed in C/C++ in bare metal, so no Python!

Moreover... is that agent model enough?

Weak notion of goal: is it a simple “procedure”? If we havemultiple goals, is there a preferred order of scheduling? Howcan I handle goal failure?Weak notion of intention: can I have multiple intentions forthe same goal? If yes, how can I select which intention toexecute?



The C++/GOLEM Era

Towards an “autonomy aware” Model

Which object picking first? Always first A and then B? Whynot the oppostite?

And if an action fails, how to recognize the failure, try torestart it or decide to adopt countermeasures?

The basic idea is to give an agent/robot:

A better awareness of “autonomy”A higher deliberation abilityA higher ability to face to failures



The C++/GOLEM Era

The GOLEM Framework

We consider a robot liviing in an environment aimed at accomplishspecific tasks in autonomy

The robot behaves by means of a set of (interdependent) goalswhose order of achiement is not fixed but autonomouslydeliberated at run-time by the robot.

A goal “g” is defined as a delibration unit which represents thetasks that the robot must do to achieve a certain state.

A goal can be:

Simple

Composite



The C++/GOLEM Era

Simple Goals

Simple goal, “sg”: a goal which requires no specific furtherdecision on the actions to perform.

Represented as sg ::= (f , p, act) where:

f , feasibility function, returns a boolean stating whetherthere are the conditions to reach the goal with success;

p, opportunity function, returns an integer stating the“importance” of the current goal w.r.t. other goals; the higherthe value the higher the importance;

act, computation to perform to reach the goal.



The C++/GOLEM Era

An Example

A robot which must pick two objects A and B has two simplegoals, {pick A, pick B}, where:

pick A ::= (is pos of A known?,−distance from A,

[move to A, activate grip for A])

pick B ::= (is pos of B known?,−distance from B,

[move to B, activate grip for B])



The C++/GOLEM Era

Goal Action Semantics

When a goal has to be achived (should f be true), thecomputation is act is executed sequentially.

The outcome of the execution (act return value) can be:

ACHIEVED, everything went well, the goal has beensuccessful achieved;

T FAIL, a temporary error has been identified (e.g. the gripfor A didn’t catch the object), but the goal could be retriedlater on;

P FAIL, a permanent error has been identified (e.g. theobject has not been found and there are no more objects oftype A), the goal failed!



The C++/GOLEM Era

Composite Goals

A Composite goal, “cg” is a set of other goals.

It is represented as cg ::= (rel , g set) where:

g set is the set of sub-goals; each sub-goal can be simple orcomposite as well;

rel is a relationship condition, chosen among:

ALLALL SEQAT LEAST(k)SEQ UNTIL



The C++/GOLEM Era

Composite Goals Semantics

cg ::= (rel , g set)

ALL: gc is achieved if ∀g ∈ g set, g is achieved (no matterthe order).

ALL SEQ, gc is achieved if ∀g ∈ g set, g is achieved (orderdoes matter).

AT LEAST(k), gc is achieved if at least k goals ∈ g set areachieved (no matter the order).

SEQ UNTIL, if first goal of g set is achieved, then gc isachieved, otherwise try second goal, then third goal, etc.



The C++/GOLEM Era

The picker example

A robot which picks both of the two objects A and B, with noprecedence, and then puts the picket object in a basket, has the followingGOLEM program:

main goal ::= (ALL SEQ, {pick object, put in basket})

pick object ::= (ALL, {pick B, pick A})





put in basket ::= (true, 0, [move to basket, release object])



The C++/GOLEM Era

The picker example (II)

A robot which picks one of the two objects A and B, but withprecendence to B, and then puts the picket object in a basket, has thefollowing GOLEM program:

main goal ::= (ALL SEQ, {pick object, put in basket})

pick object ::= (SEQ UNTIL, {pick B, pick A})





put in basket ::= (true, 0, [move to basket, release object])



The C++/GOLEM Era

GOLEM Abstract Machine

A GOLEM program P is executed by the GOLEM AbstractMachine (GAM), whose behaviour is the loop:

1 Evaluation of feasible goals

2 Evaluation of their opportunity values

3 Selection of the feasible goal with the highest opportunity.

4 Execution of the selected goal.

The GAM stops when the main goal of P either:

succeeded, or

permanently failed.



The C++/GOLEM Era

GOLEM Implementation

A preliminary implementation of GOLEM has been provided inC++ (not all sub-goals relationships).

It has been successfully used in the competitions of 2012, 2013,2014 and 2015.�class Goal {

public:

Goal(const char * name);

~Goal ();

virtual t_feasibility is_feasible () = 0;

virtual t_priority priority () = 0;

virtual t_goal_outcome execute () = 0;

};

class CompositeGoal : public Goal {

...

};� �Corrado Santoro - Programming Autonomous Robots - Miniscuola WOA 2015 53


The C++/GOLEM Era

GOLEM Practical Results

The intense use of GOLEM in four years of activity has provedits effectiveness

Robots programmed with GOLEM really exhibited a verygood degree of deliberation and autonomy

The implementation is light, very easy to use but ...



The C++/GOLEM Era

GOLEM Practical Issues (and Future work suggestions)

GAM performances are not so good

At each scheduling step, all the (undone) goals must beanalysed, by verifying the feasibility and opportunity.In our context, for example, opportunity is determined bymeasuring the distance w.r.t. a target point using Dijkstrashortest-path algorithm.A non-negligible delay is exhibited during goal selection.

Goal actions are coded in C++ in imperative form, howeverthe code must handle environment sensing, knowledge, eventdetection

May we include the concepts of events, beliefs or first-orderlogic reasoning inside goal execution code?

Is a next step with GOLEM + PROFETA + ERESYEworth?



References

References

http://sourceforge.net/projects/eresye/

A. Di Stefano, C. Santoro. Designing Collaborative Agents with eXAT. InProc. of 13th IEEE Intl. Workshop on Enabling Technologies:Infrastructures for Collaborative Enterprises (WETICE 2004).

A. Di Stefano, C. Santoro. Supporting Agent Development in Erlangthrough the eXAT Platform. Whitestein series book on Agent Platformsand Applications, M. Calisti, M. Klush, R. Unland eds., 2005.

A. Di Stefano, C. Santoro. Using the Erlang Language for Multi-AgentSystems Implementation. In Proc. of 2005 IEE/WIC/ACM Intl.Conference on Intelligent Agent Technology (IAT 2005), Compiegne,France. Sept. 19–22, 2005.


http://sourceforge.net/projects/eresye/


References

References

C. Santoro. eXAT: Software Agents in Erlang. In Proc. of 11th

International Erlang User Conference, EUC’2005, Stockholm, Sweden.Nov. 10, 2005.

V. Nicosia, C. Spampinato, C. Santoro. Software Agents for AutonomousRobots: the Eurobot 2006 Experience. In Proc. of Workshop on Objectsand Agents (WOA2006), “Best Paper Award”, CEUR-WS Publisher,ISSN 1613-0073, Vol. 204, Catania, Italy, Oct. 26-27, 2006.

C. Santoro. An erlang framework for autonomous mobile robots, Erlang’07: Proceedings of the 2007 ACM SIGPLAN workshop on ErlangWorkshop, ACM Press, Freiburg, Germany, Oct. 05, 2007.

A. Di Stefano, F. Gangemi, C. Santoro. ERESYE: Artificial Intelligence inErlang Programs. In Proc. of 4th ACM SIGPLAN Erlang Workshop,Tallin, Estonia. Sept. 25, 2005.



References

References

http://github.com/corradosantoro/profeta

L. Fichera, D. Marletta, V. Nicosia, C. Santoro. Flexible Robot StrategyDesign using Belief-Desire-Intention Model. In Proc. of InternationalConference on Research and Education in Robotics (EUROBOT 2010),Spriger CCIS Series, Rappreswille, Swizerland), May 27-30, 2010.

L. Fichera, D. Marletta, V. Nicosia, C. Santoro. A Methodology toExtend Imperative Languages with AgentSpeak Declarative Constructs.In Proc. of Workshop on Objects and Agents (WOA2010), CEUR-WSPublisher, ISSN 1613-0073, Rimini, Italy, Sept. 5-7, 2010.


http://github.com/corradosantoro/profeta


References

References

G. Fortino, W. Russo, C. Santoro. Translating Statecharts-based into BDIAgents: The DSC/PROFETA case. MAS&S Workshop @ MATES 2013.

F. Messina, G. Pappalardo, C. Santoro. Integrating Cloud Services inBehaviour Programming for Autonomous Robots. CSmart-CPSWorkshop, LNCS, 2013.

F. Messina, G. Pappalardo, C. Santoro. A Goal-centric Framework forBehaviour Programming in Autonomous Robotic Systems. IEEE/ASMEInternational Conference on Mechatronics and Embedded Systems, 2014.

F. Messina, G. Pappalardo, C. Santoro. Designing Autonomous Robotsusing GOLEM. In Proc. of Workshop on Objects and Agents(WOA2014), CEUR-WS Publisher, Catania, Italy, Sept. 2014.



References

Experiences in programming robotic systems forcompetitions: approaches, languages and tools

Corrado Santoro

ARSLAB - Autonomous and Robotic Systems LaboratoryDipartimento di Matematica e Informatica

Universita di Catania, [email protected]

Miniscuola WOA 2015 - Napoli, Italy, Sept. 19, 2015


presentation @ miniscuola woa 2015

Education

tools robotic competitions

programming robotic

kind of robotic competitions

robotic competitions

robots rescue

tools experiences

free robotic platforms

virtual robots fixed