Improved Pose Control of SLAM Robots

Abstract

Dette prosjektet hadde som form ̊al ̊a bidra til en forbedret kjøreevne av SLAM-robotene gjen- nom ̊a ta en nærmere kikk p ̊a posisjonsestimatoren samt posisjonskontrolleren i programvaren installert p ̊a Nordic Semiconductor sitt mikrokontrollerkort nRF52840DK ombord roboten. For- bedringspunktene hadde enda ikke blitt identifisert, annet enn at det i det forløpende fordypning- sprosjektet ble bekreftet at de kan relateres til posisjonskontrolleren, heller enn estimatoren. Med uspesifiserte forbedringspunkter ble det definert en mer generell problemstilling for ̊a hjelpe med ̊a lede form ̊alet med arbeidet i riktig retning. Den valgte problemstillingen ble til slutt formulert slik: Hvordan kan kjøreevnen og kontrollsystemene til SLAM robotene videre optimaliseres til ̊a forholde seg p ̊alitelige og holde seg til lineære kjøreegenskaper? Den generelle formuleringen av problemstillingen tillater prosjektet ̊a gjennomføres p ̊a et mer dy- namisk vis, med mulighet for snevring eller utvidelse av arbeidsomfanget avhengig av hvilke oppda- gelser som gjøres underveis i løpet samtidig som det fremdeles kan overholde det samme sluttm ̊alet. For ̊a besvare spørsm ̊alet vil først hele arbeidsomfanget undersøkes for ̊a finne tegn til feil eller for- bedringspunkter. N ̊ar de er funnet, vil testomfanget kunne snevres inn for ̊a finne flere indikasjoner. Denne iterative tilnærmingen viste seg ̊a være en effektiv metode for ̊a isolere ̊arsakene i de høyere niv ̊aene for ̊a grave dypere ned i systemet med form ̊al om ̊a ha isolert problemet til slutt. Prosjektet opplevde en treg start grunnet variert kodekvalitet og oppsettsanvisninger som ikke var helt komplette. Dette førte til en samarbeidsinnsats mellom de fire studentene som jobbet p ̊a robotene, for ̊a rydde opp i koden og implementere ordentlig versjonsh ̊andteringsverktøy. Etter denne omstruktureringen gjennomgikk jeg en flytting som resulterte i at jeg ikke lenger hadde tilgang p ̊a MQTT serveren som var satt opp p ̊a lesesalen. Av denne ̊arsak ble omfanget ogs ̊a utvidet til ̊a inkludere oppsett av en ny Raspberry Pi-enhet til ̊a støtte MQTT-infrastrukturen slik at det kunne igjen overføres data. I tillegg ble noen gamle python-script tilpasset og utvidet for ̊a støtte dataoverføringen for ̊a gjøre analysene. Etter disse digresjonene, kunne den iterative testprosessen endelig igangsettes. Utdata fra b ̊ade posisjonskontrolleren og motorfartskontrolleren ble analysert, og det ble fort sett at utdataverdiene overgikk en verdi ansett som motorens maksimale kapasitet, noe som etterlot reguleringseffekten ute av rekkevidde ettersom alle overg ̊aende verdier ble kuttet av ved hjelp av en kode som er satt til ̊a begrense disse verdiene. Motorene ville derfor kun vise en generell 100% effekt, forovermatet oppførsel. Introduksjonen av en skaleringsverdi p ̊a utdataen for hjulhastighetsreferansen s ̊a ut til ̊a gjøre en forskjell p ̊a oppførselen til systemet, ettersom det ble sett at roboten fremviste endringer i kursen som tegn p ̊a en reguleringseffekt. Jo lavere skaleringsverdien var, jo tydeligere kom dette frem, noe som fulgte til at roboten dro mindre og mindre mot venstre, og etterhvret ville ogs ̊a systemet begynne ̊a kompensere for feilen ved ̊a trekke roboten tilbake mot riktig kurs og stoppe nær m ̊alet. Det var en ting som derimot forble uendret, hvilket var at roboten trakk mot venstre i begynnelsen av kjøringen, noe som skjedde ved enhver kjøring. En ferdig implementert løsning kom ikke i havn, men fra oppdagelsene har det absolutt blitt lagt grunn for ̊a kunne besvare problemstillingens spørsm ̊al og tydelig definere det videre arbeidet. For ̊a kunne beskytte motorene befinner det seg en kodestyrt avgrensning som kutter ned alle overskridende verdier fra kontrolleren. En skaleringsverdi burde implementeres i forkant av denne avgrenseren for ̊a forsikre om at reguleringsegenskapene til kontrolleren faktisk kommer seg gjen- nom, ettersom det ble observert at disse for det meste ligger i omr ̊adet over avgrensningsverdien. Det er sett og bekreftet at dette tillater roboten ̊a justere kjøreretningen tilbake etter den første svingen og kompensere for andre feil. Denne svingen som fremdeles forekommer, synes ̊a skyldes utstyrskarakteristikken i motorene, da den ene motoren er observert ̊a trekke et mye høyere p ̊adrag i seksjoner der kjøringen holder seg lineær. Motorene mottar likt p ̊adrag ved oppstart, noe som kan forklare svingen ettersom de krever forskjellige p ̊adrag. En utskiftning av motorer eller kompensas- jon av p ̊adragsdifferansen m ̊a introduseres for ̊a mitigere dette, som i tillegg til skaleringsverdien vil kunne etablere mer fornuftige kjøreegenskaper

This project carried the purpose of contributing to an improved driving performance of the SLAM robots by analyzing the pose estimator and pose controller of the software installed on the Nordic Semiconductor Micro-Controller Unit nRF52840 DK onboard the robot. The points of improve- ment were not yet identified, other than verifying that they were related to the robot control functionality, rather than the estimator, which was done in the specialization project leading up to this. With the points of improvement not specified, a problem description with a more general nature was chosen in order to direct the purpose of the work. The specified problem statement ended up stating: How can the driving performance and control systems of the SLAM robots be further optimized to conform to reliable operation and linear driving properties? The general nature of the statement allows the project to be more dynamically performed, open to narrowing or extension of the scope as discoveries were made along the way, while still maintaining the same goals and purpose. To answer this question, the whole scope would need a general analysis to find any signs of errors or improvement factors. Once found, the scope would narrow down and look for new designations. This iterative approach was an efficient way of eliminating the higher level causes and dig deeper, with the end goal of having isolated the problem. A slow project start was caused by varied code quality and startup manuals that weren’t all complete. This prompted a cooperative effort between the four students working with the robot, to perform code cleanups and implement proper version handling tools. After the restructuring, I relocated cities and was no longer able to use the MQTT server which was set up in the shared workspace of the students. Hence, the work would also include setting up another Raspberry Pi unit to support the MQTT infrastructure of the system, allowing for transmission of data. Some old python scripts were adapted and repurposed, along with some extensions to the robot code, to support data transmission of the desired types to help analyze the system behaviour. After the sidetracking, the iterative test process could commence. The output from both the pose controller and the motor speed controller were analyzed, and it was quickly seen the output values would exceed the maximum duty capabilities of the motors, leaving the effect from the regulators out as the regulated values would all be limited by saturation and the motor would just display a 100% duty feed-forward behaviour. Introducing a scaling factor on the speed reference output from the pose controller would seem to change this behaviour, seeing as the robot would start showing signs of regulation in its movement. The lower the scale, the less the robot would deviate from the course, and at some point it would even readjust the heading back towards the target. One thing that would not be corrected by this scaling factor would however be the initial turn towards the left, which occurred on each test run. This project did not reach all the way to implementing a proposed solution, but from what was gathered an answer to the problem statement could be formulated and a clear path could be laid for further work. In order to protect the motors, the code has a limiter that cuts off any exceeding values. A scaling factor should be implemented ahead of this limitation in order for the control values to pass through, as they mostly lie above the limit value. This is seen to allow the robot to readjust for its initial turn and compensate for the error. The initial left turn that still remains, is likely due to hardware properties of one of the motors as it is seen that the left motor requires a much higher output than the right to generate a straight trajectory. During the first few steps when the robot is accelerating they accelerate at the same rate until a certain point, which may be why the robot turns before the regulation kicks in. The motors should be investigated evaluated whether a replacement should be done, or whether the controller can be adjusted to compensate for this offset, as an addition to the scaling factor, in order to achieve a sensible driving.