Serial and Thread/CoAP message implementation for the Slam Robot

Abstract

Spørsmålet som startet og veiledet arbeidet på denne master oppgaven er det samme spørsmålet som skal konkludere oppgaven. Vil en thread/CoAP implementasjon være fordelaktig for dette prosjektet? Igjennom arbeidet på prosjektet har det vært oppdaget en måte å kommunisere serielt mellom en windows maskin som kjører C++ serverapplikasjonen og en seriell "gateway" som er koblet til windows maskinen via en USB kabel. Det har blitt gjort mye arbeid i å modifisere den nåværende serverapplikasjonen fra å bruke MQTT som dens meldingsprotokol, til å bruke bruke serielle meldinger, samtidig som at kildekoden er modulær, "backward compatible", testbar og stabil.

Det samme "tråd" systemet som brukes til å behandle meldinger og GUI for serveren har blitt brukt til å ekspandere serverens evne til å kunne bruke flere, ulike meldingssystemer. På grunn av at det endelig systemet ikke nådde en ferdig, fungerende versjon, ble det ikke mulig å gjøre ordentlige tester av systemet der serveren kontrollerer roboten. Det ble alikevell gjort flere tester for å måle evnen til spesifike ledd i det påtenkte systemet. Testene kunne antyde til flere fordeler ved det nye systemets enkle oppsett og lave kompleksitet, mens det gamle systemet sin effektive ytelse, "loose coupling" og hastighet når den sender meldinger, vil kunne vippe fordelsbalansen noe. Det vil kunne bli en stor fordel for prosjektet hvis det blir funnet en måte å avkoble relasjonen mellom lese- og skrivefunksjonaliteten til den serielle implementasjonen.

Begrensningene til nRF52840 dongelens evner har blitt prøvd og tested, noe som resulterte i en endring i den orginale oppsetningen av det påtentkte prosjektet; en endring fra å bruke nRF donglenen til å bruke en ekstra nRF52840 "Development kit". Dette gjorde videre progresjon på det serielle arbeidet lettere, og medførte en måte å kommunisere direkte med C++ Serveren. Det påtenkte videre arbeidet på DKen som en seriell-"gateway" har møtt et stoppepunkt, der to av de kritiske elementene, seriell kommunikasjon og thread/CoAP, ikke ser ut til å kunne kjøre i det samme utviklingsområdet. På grunn av manglende tid igjen på arbeidet til denne masteroppgaven, ble det ikke funnet en annen passende metode for å fikse dette problemet. Dette betyr at prosjektet ikke blir å ha et fullstendig fungerende sluttprodukt, men heller en samling av individuelle moduler, som er brukbare for midre tester. Reduseringen av antall behøvde noder i systemet for å sende meldinger har netto sett ut som et positivt sluttresultat av arbeidet.

I forsøket på å svare på problemstillingen, forsøkes det å fremheve fordelene av den nye løsningen, samtidig som de potensielle forbedringspunktene skal observeres. Den totale kompleksiteten av prosjektet har blitt forminsket, samtidig har antall moduler blitt redusert som et resultat av mindre komplexe protokoller og et alternativ for seriell komunikasjon for serveren har blitt framvist. Det er enda problemer med sluttresultatet; Det fungerer ikke som en helhet, det har oppsettsvansker og ytelsesproblemer. Systemet er heller ikke like "reliable" som den tidligere implementasjonen. Til slutt, det er mulig at løsningen som er funnet er en forbedring, men dette gjenstår fortsatt å bli vist med fiksing av problemer og mer gjennomførte tester, noe som gjør at den tidligere implementasjonen kan sees på som mer attraktiv inntil videre.

The question that started and guided the work on this master thesis is the same question that will conclude it. Will an implementation of thread/CoAP be beneficial for the project? During this work, there was discovered a way of communicating serially between the windows machine running the C++ server application and a serial gateway connected to the windows machine using a USB cable. Work has been put into modifying the current server application from using MQTT as its communication protocol, into using serial messaging, while keeping the application modular, backward compatible, testable and stable.

The same thread system used to manage messages and the GUI has been used to expand the servers ability into using multiple messaging systems. As the complete system never finished, proper tests in using the server application to control the robot could not be done. Some test where done to test the limits of the serial messaging, and the results suggested the setup and low complexity of the serial implementation is better while the performance, loose coupling and speed outweighs the gains of the current implementation of the serial messaging system. If a way was found to decouple the read and write functions, this implementation will gain a lot.

The limits of the nRF52840 Dongles capabilities has been tried and tested, resulting in a change of the original setup, with changing the Dongle into a nRF52 Development Kit. This did make the serial communication with the windows machine work. The further work on the DK as a gateway reached a dead end, where the two critically important features, serial communication and thread/CoAP, did not seem to be able to compile and run in the same environment. As this happened at the end of the work on the master, no time was left to find another fitting solution with time for implementation. This meant the project would not have a full working end product, and rather separate working modules, useful for measuring individual performance. The reduction of the numbers of nodes needed to in theory send a message from the robot to the server might be looked as a positive outcome of the work.

Now trying to answer the problem statement, we try to isolate the gains of the current solution, as well as observing the potential improvements. The complexity of usage has gone down, the amount of modules has been but, the chance for complex and hard to find errors has been reduced as a result of less complex protocols and an alternative communication method from the server has been showcased. There are still problems with the end result, one that it does not work fully, it has setup and performance issues on all of the modules and it is not as reliable as the previous system. In the end, a solution might have been found, but it is yet to be shown to be worth continue developing, as there are a number of factors that works against it in its current implementation.