Dit protocol is opgesteld vanuit de vraag voor een uniform protocol tussen een computer en een op afstand bestuurbaar robotplatform. Hiervoor werd een vergelijkbaar protocol gebruikt, maar tussen de verschillende implementaties en het protocol zelf zaten per robot verschillen zodat dit niet universeel toepasbaar kon zijn. Het doel van dit protocol is een tot op zekere hoogte een universeel uitwisselbaar communicatiemechanisme te zijn. Dit mechanisme is bedoeld om verkeer tussen een master en een slave vast te leggen. Een master is een systeem dat een slave direct aanstuurt en hier gegevens aan op vraagt. De slave zorgt voor directe aansturing van de robot. Naast directe aansturing wordt vaak op een embedded systeem ook een aantal sensoren aangesloten. Ook deze informatie moet opgevraagd kunnen worden. Een voorbeeld is het Stalker II project: hierbij is een notebook de master en een embedded paralax bord de slave. Een belangrijk uitgangspunt voor dit protocol is dat elk robotplatform verschillend is. Daarom is in dit protocol ruimte over gelaten voor eigen implementatie, welke wel aan een aantal voorgeschreven eisen moet voldoen. Ook moet in de robotica rekening gehouden worden met het veiligheidsaspect. Aangezien communicatie niet altijd goed verloopt, zijn hier in een aantal richtlijnen opgesteld zodat hiermee hopelijk een aantal situaties afgevangen kunnen worden.
2
Controle van het platform
Alle strings (voor controle van het platform en ook statusinformatie) worden afgesloten met een newline \n (ascii 10). Dit wordt verder niet vermeld bij de volgende voorbeelden.
2.1
Standaard voorgeschreven
Schakel de motoren van het platform uit. Hierbij gaat dus de stroom van de motoren af, zodat deze niet meer bekrachtigd zijn. Deze zijn dan ook niet meer aan te sturen via een ander commando. $0 Schakel de motoren in. Dit moet elke eerste keer gebeuren na het opstarten of na een noodstop of na het uitschakelen van het platform. $1
2.2
Voorbeeld platformafhankelijke berichten
De volgende commando’s zijn platformafhankelijk. Aangezien dit op een groot aantal platforms zeker van toepassing zal zijn wordt aangeraden om de volgende implementaties te gebruiken. Overigens is het volgende item van toepassing op een groot aantal platformen. Stuur met wielen, parameters speed en dir. Hierbij worden de wielen zo gedraaid dat er een bocht wordt gemaakt met het platform. Afhankelijk van het platform draaien twee of vier wielen.
3
Figuur 1: Reguliere expressie waarmee de syntax te valideren is. $2,<speed>, Voor het aan sturen van vier losse wielen kan er bijvoorbeeld gekozen worden voor: $3,<speed1>,,<speed2>,,<speed3>,,<speed4>,
2.3
Syntaxregels
De variabele die overgestuurd wordt is een getal welke optioneel met een ’-’ teken kan beginnen (voor gebruik van negatieve getallen). Hierin mogen geen andere karakters in voorkomen dan 0 tot en met 9. Ook punten en komma’s mogen niet verstuurd worden, buiten de scheidingstekens om. De ranges van de variabelen speed en dir moeten zelf gekozen worden. Het wordt aangeraden om deze vast te leggen en op beide systemen (systeem op robot en computersysteem) op input te testen dat de vastgelegde ranges niet overschreven worden. Dit gaat op zowel minimale en maximale waardes. De ranges van een argument zijn platform en implementatie afhankelijk. Deze standaard verplicht niet het gebruik van een absolute waarde of een waarde in een bepaalde eenheid. De ranges moeten afhankelijk van het platform zijn. Het te oversturen bericht moet voldoen aan de volgende reguliere expressie: ^\ $ (!|[0 -8]( , -?\ d +)*|9 ,[ a - z ]+)\ n Zie hier voor figuur 1.
3
Statusinformatie
Het platform kan ook statusinformatie terugsturen. Dit kan bijvoorbeeld het resterende accuvermogen zijn, de snelheid van het platform of het aantal counts
4
van een encoder. Ook kan er gedacht worden aan het stroomverbruik van motoren. Om zo min mogelijk verkeer op de bus te hebben, wordt er gebruik gemaakt van een request vanuit de computer naar het embedded systeem. Daarna wordt de huidige waarde teruggegeven. Dit is ook omdat sommige gegevens niet regelmatig opgevraagd hoeven te worden, terwijl sommige data wel vaak opgevraagd wordt. Een request en een reply begint altijd met een $9 De request vanuit de computer is als volgende opgesteld: $9, ¡naam¿ is de naam van deze parameter, case sensitive. De request kan er als volgende uit zien: $9,speed Vervolgens handelt de microcontroller de request af en stuurt een respons volgens het volgende schema terug: $9,,<waarde> Waarbij de naam van het respons overeenkomt met de naam van de request. De waarde is een getal welke optioneel met een ’-’ teken kan beginnen. Hierin mogen geen andere karakters in voorkomen dan 0 tot en met 9. Ook punten en komma’s mogen niet verstuurd worden. Een voorbeeldresponse: $9,speed,200
4
Uitbreidbaarheid
Dit protocol is nog uit te breiden voor als de standaard commando’s en statusinformatie niet voldoende is voor de gebruikte robot. De statusinformatie is standaard als niet voorgedefinieerd, maar voor een commando kan er het zijn dat er bijvoorbeeld extra parameters verstuurd moeten worden. In plaats van de bestaande regels aan te passen kan er beter gebruik gemaakt worden van een nieuwe regel. Gebruik daar voor ook een $ en vul het nummer zelf aan (welke nog niet gebruikt is bij de implementatie). Leg daar ook van vast wat de beperkingen zijn en hoe de robot daar op dient te reageren.
4.1
Te specificeren door de gebruiker
De volgende punten dient de gebruiker van dit protocol zelf te implementeren en vast te leggen: • Baudrate • Limieten en ranges van de gebruikte parameters • De gebruikte argumenten om gegevens op te vragen • De limieten van de retourwaarden van de opgevraagde gegevens. • De extra vastgestelde regels
5
5 5.1
Overige Bad Line
Bij een slechte communicatie op de lijn, dus als er messages niet goed ontvangen worden of de berichten niet voldoen aan de boven gestelde eisen, moet de slave of de master deze commando’s negeren. Echter moet wel het bericht $9,badline Teruggestuurd worden. Dit zodat de andere partij ook weet dat er iets niet goed gaat en hier actie op kan ondernemen.
5.2
Noodstop
Als er een noodstop moet gebeuren moet dit zowel hardwarematig op de robot zelf kunnen gedaan worden en via de bedienende software. Via dit protocol moet de master het volgende bericht sturen: $! Hierbij dient de slave alle motoren niet meer te laten bewegen en deze niet meer powered te laten. Als de robot weer in bedrijf gesteld moet worden dan moet $1 eerst gestuurd worden. Ook dient van te voren overdacht te worden wanneer noodsituaties op kunnen treden en hoe dit afgehandeld dient te worden, afhankelijk van de situatie.
5.3
Watchdogtimer
Er dient ook over een watchdogtimer en de implementatie hier van nagedacht te worden. Hierbij dient bijvoorbeeld na een bepaalde periode zonder communicatie automatisch de slave de motoren te stoppen. Aangezien dit appli˜ catieafhankelijk is, dient dit zelf vastgelegd en geA¯mplementeerd te worden en is dit niet vastgelegd in dit protocol.
