Modelleren ROS2 architectuur

Voor het besturen van mobiele platforms, en industriële robots, is veel software nodig. Bijvoorbeeld voor de communicatie van een padgenerator naar de motoren, of van sensoren naar een centrale processor-unit. Hiervoor maak ik gebruik van het Robotic Operating System 2 (ROS2) dat voorziet in een nieuw communicatie-middleware DDS. Gaandeweg meer ervaring hiermee is opgedaan ben ik tot de conclusie gekomen dat ik heel veel tijd bezig was met het schrijven van bijna dezelfde code in een net andere vorm, omdat de functionaliteit net op details anders was. Tevens is de ROS2-stack vrij nieuw, er wordt door de ROS-community veel werk verzet om de code voor ROS 1 om te zetten naar ROS 2. Dit is een proces wat nog bezig is en voor de verschillende versies van ROS2 tot andere oplossingen heeft geleidt; sommige constructies zijn al weer veranderd in de tijd. Om het regelmatig herschrijven van code te voorkomen (en het testen en debuggen wat hiermee gepaard gaat) heb ik een programma gemaakt dat de code kan genereren vanuit een model. In de afbeelding is dit model te zien, met de verschillende bouwblokken van een ROS2-stack. De code wordt automatisch gegenereerd en daar zit door de gemaakte generators nog best wel wat slimmigheid in. Hiervoor gebruik ik het programma MetaEdit+ die je essentieel een grafisch meta-model laat maken. Een meta-model is een model van een model, dus feitelijk geef ik aan waaraan de model-blokjes aan moeten voldoen, welke relaties ze mogen hebben tot andere entiteiten, welke randvoorwaarden (constraints) ze hebben, en ik geef in generators aan hoe de C++17 code eruit ziet die wordt gegenereerd. Zo wordt een hele project-structuur gegenereert die direct te compileren is.

Op deze manier wil ik bereiken dat het maken van code sneller gaat en dat fouten worden voorkomen wat het ontwikkel-proces versnelt. Hierbij kan ik me focussen als architect op de complexiteit van het probleem, en niet ook nog eens op de complexiteit veroorzaakt door gebruik te maken van het software-ecosysteem. Dit wordt door Fred P. Brooks in zijn artikel “No Silver Bullet – Essence and Accident in Software Engineering” de ‘accidental complexity’ genoemd: statement “minimize accidental complexity, only essential complexity remains”.