Det finns flera nivåer av programvarukontroll som måste finnas i alla, förutom de enklaste robotarna. Mikrokontrollenheter (MCU) och system på-chip-lösningar (SoC) som är ansvariga för att hantera sensorer och manöverdon kommer i allmänhet att använda ett realtidsoperativsystem (RTOS) eller kärna.
Maximering av systemresurser med RTOS multitasking
Fördelen med att använda ett realtidsoperativsystem är stödet för multitasking. Det ger ett förhållandevis enkelt sätt att schemalägga många aktiviteter på en enda mikroprocessor för att maximera resurserna och systemets förmåga att reagera på yttre händelser. Till exempel öppnandet av säkerhetskorgen måste utlösa ett uppehåll i aktiviteter på ett sätt som minimerar risken för robotar och personal. Att bara stänga av strömmen är potentiellt osäkert. Ett realtidsoperativsystem (RTOS) kan utlösa alla de åtgärder som behövs för att placera roboten i ett stillastående tillstånd men se till att den inte tappar tunga föremål eller orsakar skada på något annat. Detta till exempel kan uppnås genom att växla till en programvarutråd som instruerar starkströmskretsar att hålla motorerna i fördefinierade positioner.
I kombination med ett lämpligt utformat tillämpningsprogram kan ett realtidsoperativsystem (RTOS) ge fasta garantier för den tid det tar att reagera på kritiska händelser, vilka vanligtvis signaleras av ett externt avbrott i mikroprocessorn. Detta hanteras vanligtvis genom en avbrottshanterare som kan initiera en programvarutråd som kan vidta åtgärder. Genom prioriteringsbaserad förebyggande schemaläggning garanterar realtidsoperativsystemet den kortast möjliga latensen för denna typ av respons på de viktigaste frågorna.
ROS: Robotoperativsystemet
I en robot med flera mikroprocessorer och hårdvaruacceleratorer, vilket alltmer blir fallet, behöver varje aktuatornod styras av ett överordnat system som tar hand om uppgiftsplanering och beteenden på hög nivå. Detta är en roll som vanligtvis utförs av mellanprogramvara som robotoperativsystemet (ROS) som körs på en högpresterande mikroprocessor.
Idag är ett robotoperativsystem utformat för att köras på ett operativsystem som Linux, snarare än att vara ett självständigt operativsystem. ROS kräver inte heller RTOS-beteende från det underliggande operativsystemet eftersom det utför uppgifter som är mer långsiktiga än sådana som behöver responstider på mikrosekunder. Det pågår emellertid arbete med att utveckla ROS 2.0-implementeringar som kommer att köras på RTOS-plattformar för att de ska kunna erbjuda högre reaktionsförmåga.
Mellanprogramvaran som robotoperativsystemet utgörs av tillhandahåller många olika tjänster. De inkluderar hårdvaruabstraktion av enheter på låg nivå och stöd för överföring av meddelanden mellan processer för att möjliggöra arkitekturer med flera processorer samt hantering av programvarupaket. Vanligtvis representeras processer med hjälp av grafer som länkar noder för att beteckna var bearbetning sker och hur processerna kommunicerar med varandra. Implementeringar av robotoperativsystem är ofta paket med öppen källkod och använder Linux-plattformar för att underlätta hanteringen av beroenden mellan projekt med öppen källkod. Fördelen med detta är att ROS-programvaran blir lättillgänglig.
I robotoperativsystem är noder processer eller programmoduler som hanterar en eller flera relaterade uppgifter. Till exempel kan en kamera och bildbehandlingsnod behandla visuella data från en eller flera bildsensorer. För att möjliggöra användning av nätverksinfrastruktur för att koppla samman noder, en arkitektur som är vanligt förekommande i fordonssystem, stödjer ROS TCP/IP och UDP för överföring av meddelanden. De olika noderna och anslutningarna kan beskrivas med hjälp av det universella robotbeskrivningsformatet (URDF), som är ett XML-filformat.
För att möjliggöra effektiv delning av sensordata och kommandon använder ROS en mekanism för publicera och prenumerera där noder registreras för att bli informerade om specifika ämnen. Alla uppdateringar om varje ämne skickas till alla prenumererande noder. ROS Master håller reda på alla tjänster och ämnen. Den hanterar registrering av noder och driver en parameterserver för att tillåta noder att lagra och hämta gemensamma konfigurationsdata.
En stor fördel med mellanprogramvara som robotoperativsystem är återanvändning och delning av kod. Koddelning ger alla användare möjlighet till en gemensam grund för programvara, vilket hjälper till med testning och övergripande tillförlitlighet för programvaran. Robotoperativsystem är inte begränsade till fysiska robotar.
De stöder även simulerade robotar.
Simuleringens roll inom robotutveckling
En grundläggande förutsättning för robotdesign är förmågan att simulera dess beteende i en virtuell miljö innan implementering i hårdvaran. Simulatorn gör att robotprogram kan skrivas och felsökas offline. Det tillåter utveckling av programvara i en riskfri miljö och undviker problemet med att skada roboten eller robotens omgivning om det föreslagna programmet innehåller allvarliga fel. Den slutgiltiga versionen av programmet kan sedan testas på en faktisk robot.
Det finns ytterligare fördelar med simulering. Designers kan utveckla i faser, där man börjar med enkla högnivåmodeller, vilket är fördelaktigt för komplexa projekt. Denna typ av simuleringar kan användas i ett tidigt skede för att fastställa om ett system är genomförbart eller inte. Simuleringsmiljöerna som har utvecklats för robotteknik är designade för att vara kompatibla med ett brett utbud av programmeringsspråk, vilket stöder enkel utveckling. Simulering kan även minska utvecklingstiden eftersom den tillåter korrigering av misstag i programlogiken innan de implementeras i hårdvaran och därmed blir mycket svårare att åtgärda.
Det finns ett antal metoder för simulering av robotar. Traditionellt har simulering fokuserat på robotrörelsens kinematik för att visa om vägar och banor är genomförbara och praktiska.
Denna typ av simulering placerar en virtuell robot i ett tredimensionellt rum och demonstrerar hur lederna troligtvis kommer att röra sig i den fysiska världen. Simuleringen kan också hjälpa till att avgöra om en robot kommer att kunna lyfta och hantera tunga eller skrymmande föremål utan att förlora stabilitet.
Vissa kinematiska simulatorer använder en förenklad uppsättning beräkningar och fokuserar främst på hur ett program kan rotera och flytta objekt för att säkerställa att de inte kolliderar med gränserna för en säkerhetskorg eller en arbetscell. Andra involverar mer komplexa fysiksimuleringar för att mäta påfrestningar och andra problem som kan påverka robotens prestanda i fält.
Simulering av robotinteraktioner i dynamiska miljöer
När robotar rör sig ut från kontrollerade miljöer som skyddas av säkerhetskorgar och in på områden där människor och andra robotar kan röra sig fritt, behöver designers ta hänsyn till möjliga interaktioner. Vid design av mobila robotar gör simulatorer som hanterar beteende att designers kan skapa virtuella världar med en hög abstraktionsnivå som innehåller andra objekt. En enkel beteendesimulering tar bara hänsyn till en robots rörelse bland en uppsättning fasta objekt. Mer komplexa simuleringar involverar användning av flera mobila agenter eller avatarer. Dessa beteendebaserade simulatorer hjälper till med designen av program där roboten troligtvis kommer att möta komplexa miljöer. De kan lära sig från kollisioner och andra interaktioner för att bättre hantera hinder. Fysiksimuleringar är viktiga för att fastställa att robotens kinematik återges korrekt.
Att välja rätt fysikmotor för din robot
Simuleringsmiljöer som Gazebo-paketet med öppen källkod kan generera realistiska sensordata som kan vara korrupta med varierande nivåer av brus. Gazebo gör det möjligt att anpassa simuleringen till applikationens specifika krav, till exempel genom att använda olika fysikmotorer. Vid simulering av rörliga miljöer väljs ofta en maximal koordinatlösare som ODE eller Bullet. En lösningsmekanism baserad på Featherstone-metoden, som DART eller Simbody, hittar fler tillämpningar i artikulerade system som humanoida robotar eller komplexa tillverkningsrobotar. Alla fysikmotorer nås via samma applikationsprogrammeringsgränssnitt (API).
Det finns emellertid begränsningar vid simuleringar. En applikation kan endast simulera egenskaper och händelser som den är programmerad för. Interna eller externa faktorer representeras inte och kommer inte att simuleras, vilket kan leda till problem när designen överförs till hårdvara. Det är också ofta svårt att bygga tillräckligt representativa scenarier, särskilt när det gäller att utvärdera komplexa situationer och beteenden. Erfarenheten av att överföra simulerade designkoncept till den fysiska miljön kan emellertid återföras i framtida projekt, vilket kommer att minska felen över tid.
Som ett resultat förblir simulering ett av de mest kraftfulla verktygen i robotingenjörens verktygslåda.
