| dc.description.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 | |
| dc.description.abstract | 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. | |