Engineering the software of robotic systems - 3 - Underwater robots [ICSE 2017 - technical briefing]

UNIVERSITY OF L’AQUILA
Federico Ciccozzi1, Davide Di Ruscio2, Ivano
Malavolta3, Patrizio Pelliccione4, Jana Tumova5
1Mälardalen University (Sweden)
2University of L’Aquila (Italy)
3Vrije Universiteit Amsterdam (The Netherlands)
4Chalmers University of Technology | GU (Sweden)
5KTH Royal Institute of Technology (Sweden)
Engineering the software
of robotic systems
UAV VASA

Federico Ciccozzi, Davide Di Ruscio, Ivano Malavolta, Patrizio Pelliccione, Jana Tumova
What is VASA?

Underwater robot with following characteristics:
• 5 thrusters, omni-directionality
• other actuators: torpedoes, two arms (grab/release, push/rotate)
• complex control routines due to very variable underwater
conditions
• equipped with stereo-vision system (two separate cameras taking in
individual image streams which are merged into one stereo-image)
What is VASA?

• Decisions based on input from stereo vision system
• Mission-oriented and mission-critical
• Software roughly divided in three parts:
• Control software – for thrusters and other actuators
• Vision software – input image streaming, image recognition,
image storing (big data processing)
• Application software – needed for the robot to exploit image
streaming/recognition and control software to perform missions
Peculiarities

Control software
• + Well-established best practices – we know how to optimize the
software for a thruster, we know how to manage the interplay
between thrusters operating on different axes
• - Usually engineered through platform-specific coding, low
reusability, low adaptability to replacement of heterogeneous
parts
Engineering Software for vision-based UAVs

Vision software
• + Well-established common libraries (e.g. OpenGL) with
algorithms for object detection, colour detection, image
recognition, filtering, etc
• - Underwater environment is extremely variable, due to weather
conditions, streams, depth, turbidity
o this makes it hard to reuse SW from aerial and terrestrial robots
o this software must be engineered so to allow an extremely wide spectrum of
different environmental situations in order to be able to recognize, e.g., colours

Application software
• Up to now not given as much as attention as to the previous two
• Big parts of the missions are hard-coded (e.g., known distances)
o + Less calls to time-consuming vision software
o - Low adaptability
• Mission-specific (and often platform-specific)
o + High optimization
o - Low reusability
o - Low adaptability

• International AUSVI RoboSub Competition, yearly, held in San Diego,
open to students only (http://www.robonation.org/competition/robosub)
• VASA team, Mälardalen University
• Mission-based tournament (like a World-cup for UAVs)
Application scenario

Typical RoboSub missions

• No communication with the robot allowed after put in water
• Outdoor pool with turbid water
• Unknown environment (size, colours, weather conditions)
• Missions know in advance but several details unknown (order, colours)
Challenges

• No communication with the robot allowed after put in water
• Outdoor pool with turbid water
• Unknown environment (size, colours, weather conditions)
• Missions know in advance but several details unknown (order, colours)
Heavily relying on vision
Challenges

Example on varying visual conditions underwater

Control software
• Issue: replacement of actuators managed by platform-specific
control code
• Solution: reverse-engineering control code to executable (UML)
models from which different target platforms can be hit
Engineering Software for RoboSub

Vision software
• Issue: too low adaptability to weather conditions (too high response
time when adding a larger number of ”known” colour nuances)
• Solution: created a unique board with CPU, GPU and FPGA able to
cooperate in order to allow for much faster object and colour
recognition and heavier processing of larger amounts of data
• The side-effect was that vision SW had to be re-engineered almost completely
• How to effectively make heterogeneous processors to interact is still an open SW
engineering issue

Application software (1)
• Issue: some parts of the missions were hard-coded (e.g., known
distances between obstacles and/or objects)
• Solution: we removed all mission-specific hard-coding and made all
missions independent from each other independency led to much
higher adaptability to changed order of missions and higher fault-
tolerance (the robot does not get stuck in one mission when it can not
carry it out)

Application software (2)
• Issue: engineered ad-hoc for specific missions. Changes to one
mission could affect other missions
• Solution: a DSML by which we could model and simulate missions.
From the same model, different platforms (even different types of
robots) can be targeted (recall FlyAQ?)

• Tool for simulating variability of the underwater environment
• Collaborative missions with UAVs and other types of autonomous
vehicles
• Improvement of performance of vision software through effective
exploitation of FPGA capabilities
• Improvement of image filtering through more efficient
minimum-volume enclosing ellipsoids algorithms
Current work

Engineering the software of robotic systems - 3 - Underwater robots [ICSE 2017 - technical briefing]

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Engineering the software of robotic systems - 3 - Underwater robots [ICSE 2017 - technical briefing]

Semelhante a Engineering the software of robotic systems - 3 - Underwater robots [ICSE 2017 - technical briefing] (20)

Mais de Ivano Malavolta

Mais de Ivano Malavolta (20)

Último

Último (20)

Engineering the software of robotic systems - 3 - Underwater robots [ICSE 2017 - technical briefing]