Use Hardware In the Loop (HIL) testing rather than wait for a final hardware

Guideline Information

Item	Value
Guideline Number	16
Guideline Responsible (Name, Affiliation)	Sebastian Monka, Aleksej Buller, Fraunhofer IOSB
Guideline Reviewer (Name, Affiliation)	Timoteo García Bertoa, Sundance
Guideline Audience (Category)	HW designers, System architect
Guideline Expertise (Category)	TBD
Guideline Keywords (Category)	testing, drones, project management, time management

Guideline advice

Use Hardware in the loop (HIL) testing with early prototypes rather then wait for an fully integrated hardware[1].

Insights that led to the guideline

How the drone (new Tulipp platform) communicates with the outside world please look at guidline 17 [1]: "How to get EMC2 Board communicate with an UAV"

Recommended implementation method of the guideline along with a solid motivation for the recommendation

If you use a drone simulation to test your algorithms you can do this in parallel with the integration work and save time. This also gives you the advantage of a higher testing density as your are not limited to the Weather or risks of drone crashes.

There are a couple of software tools that replicate a UAV in a computer (HIL [3]). All properties of the drone (communication, flight parameters) are displayed in the simulation. It is also possible to control a UAV in the simulation via a manual remote control (flight simulator).

It is correct to test the new software-algorithms not immediately on the drone, but in the simulation. A small mistake can have a big impact. On a land robot you can install a wireless emergency stop, but on a UAV an emergency stop function does not work in a fault condition. Made a mistake and the drone can fly away or crash. The big effort would have been for nothing.

With AIRSIM [2] the MAVLink communication between the Tulipp platform and the flight controller was tested. The algorithms for the video evaluation were tested in the QT Creator [4] with openCV library [5].

Instantiation of the recommended implementation method in the reference platform

Obstacle detection on the Tulip reference platform was implemented. The safe flight of the obstacles only with the help of the depth maps is currently not possible.

In the last phase of development, the "hardware in the loop" helps us very little, because we want to evaluate the pictures from the real world and deal with real obstacles.

Evaluation of the guideline in reference applications

We could not change a parameter for the altitude above ground. The drone in the simulation has been rising higher and higher. Software compilation in SDSoC took about 2.5 hours. There are many other unexplainable issues that sporadically appear and slow our progress.