Date: 07/03 2014 and 11/03 2014
Duration of activity: 9.15-16.30 and 9.15-12.15
Group members participating: Pætur, Christian og Søren
Goal: At gennemføre ugens opgaver [1].
Plan: Gå opgaverne sekventielt igennem.
Results: Vi har gennemført alle opgaverne.
Self-balancing robot with light sensor
Use the LEGO model suggested by Phillippe Hurbain, [2], and the java program from Brian Bagnall, [3] to start experiments with a self-balancing robot. Under the headline Usage Phillippe Hurbain describes under which conditions the NXTway works best. Try to follow some of his advices.
Vi fandt det svært at få robotten, se figur 1, til at balancere mere end et par sekunder af gangen, uanset under hvilke forhold vi kørte robotten: mørkt rum / rum kun oplyst af lysstofrør med gardinerne trukket for og i forhold til underlag, om det var et uensartet gulvtæppe eller bordplade (se figur 1 for bordplade). Det viste sig hurtigt, at hvis ikke robotten var i 100 % balance når man startede programmet, ville den aldrig komme til at balancere, da den så “lærte” at starthældningen (offset) var det forkerte og dermed forsøgte at nå denne ude-af-balance hældning. Dette førte os til næste opgave, hvor vi igennem et GUI kunne ændre offsettet.
Figur 1 - Robotten vi byggede udfra LEGO model af Phillippe Hurbain [2].
Choice of parameters on-the-fly
During the development of a balancing robot a lot of adjustment of constants is needed. This can be done by editing the Java source code, compile and transfer it to the NXT before the next trial. To speed up this trial and error process a wireless communication could be established between PC and NXT so the constants of the program can be changed on-the-fly.
An example of such a pair of programs, one program for the PC and one for the NXT, is PCcarController.java and BTcontrolledCar.java. The PCcarController is a GUI that runs on the PC. It establish a Bluetooth connection to the NXT and use wireless communication to drive a simple car with different values of power to the motors and for different durations. The BTcontrolledCar waits for a connection to be established, receives the values of power and duration and make the car drive controlled by the received values. When the car stops BTcontrolledCar reads the tacho counters (the Car class from Lesson 2 has been extended with a method counter, Car.java) and sends the value for display in the GUI.
A similar setup can be used to make it possible to choose parameters for the balance controller from a GUI on the PC.
Vi ændrede PCcarController.java så GUI’et kom til at se ud som følger, hvor vi kunne ændre på KP, KI, KD samt offset over bluetooth. For at ændre offsettet indtaster man eksempelvis 2 eller -2 for at ændre offsettet med 2 i den ene eller anden retning.
Figur 2 - Billede af GUI til styring af balanceparametre
I BTcontrolledCar.java instantierede vi en tråd, som hele tiden kørte og tjekkede på, om nye værdier var blevet modtaget:
Selvom vi nu kunne ændre offsettet over bluetooth, havde vi ikke held med at få robotten til at balancere i mere en 2-3 sekunder. Efter at have eksperimenteret med forskellige værdier af KP, KI, KD samt offset uden held, fik vi et hint af en af de andre grupper, som havde prøvet at montere større hjul med stor succes. Vi monterede derfor også et sæt større hjul, og fik straks en mere stabil og selvbalancerende robot. Det krævede naturligvis en rekalibrering af KP, KI og KD værdierne, da de værdier, som lyssensoren målte, havde ændret sig som følge af den større afstand til bordet. Med de større hjul fik vi robotten til at balancere i minimum 3 minutter, link til video.
Figur 3 - Robotten vi byggede udfra LEGO model af [2] men med større hjul.
Eftersom lyssensoren blev hævet nogle centimeter over bordet efter udskiftning af hjulene, blev robotten også mere påvirkelig overfor ændringer i overfladen, hvilket betød, at hvis man holdt sin hånd på bordet blot 10 cm fra lyssensoren, kunne man se en ændring i robottens opførsel. Derfor besluttede vi os for at flytte lyssensoren længere ned mod bordet, således at afstanden igen var den samme som med de små hjul. Det viste sig til vores store overraskelse, at robotten opførte sig på samme måde som med de små hjul: robotten var meget svær at få til at balancere. Hvorfor mon det? Følgende er vores gæt på et svar.
Jo tættere lyssensoren er på overfladen, jo mindre er det område sensoren måler på. Hvis robotten derfor rykker sig lidt når lyssensoren er tæt på overfladen, vil forskellen i gammel bordfladeområde som lyssensoren ‘ser’ vs. nyt bordfladeområde som lyssensoren ‘ser’ være procentvis stor. Hvis lyssensoren er længere væk fra bordfladen vil den procentvise ændring i bordfladeomårdet ved samme udsving være mindre da bordfladeområde-arealet er større, og dermed tror vi at lyssensorværdien vil ændre sig knap så radikalt, som fører til en mere stabil bil.. Se følgende figur:
Fordelen ved, at lyssensoren sidder tæt på overfladen er, at den ikke er så let påvirkelig overfor omgivelserne. Fordelen ved, at lyssensoren sidder længere væk fra overfladen er, at vi dermed får vi en robot som er mere stabil og som forsøger at korrigere mindre da vi flyttede sensoren op. Det skyldes, at området som sensoren måler er væsentlig større når sensoren er længere væk fra overfladen, og dermed skal der større ændringer til i overfladen før robotten lader sig påvirke. Derimod er sensoren lettere påvirkelig når afstanden til overfladen er stor, og derfor fungerer robotten også bedst under mørke, kontrollerede forhold hvor der ikke er noget omgivende lys der kan interferere med det røde lys som sensoren selv udsender.
Self-balancing robots with color sensor
The NXT Segway with rider, [6]. use a color sensor to measure the position of the robot. Try that as an alternative to the light sensor. And maybe the physical structure of this robot is better that the structure in [2] and [3]. Maybe it is worth to try it.
Vi prøvede med color sensoren i stedet for lyssensoren i vores første build af robotten, se figur 1, men til dette build virkede color sensoren ligeså ringe som lyssensoren: vi kunne kun få robotten til at balancere i 2-3 sekunder. Efter at vi ændrede robotten til som den ses i figur 3 prøvede vi af tidsmæssige årsager ikke color sensoren igen.
Self-balancing robots with gyro sensor
Both the robots in [2] and [3] use the light sensor to measure the distance to the surface. In [4] and [5] other more reliable types of sensors are used to measure the tilt of the robot during balancing.
Vi prøvede ikke at bruge gyroskoper til at få robotten til at balancere.
Conclusion:
Vi kom igennem alle opgaver bortset fra den, hvor vi skulle bruge gyrosensoren. Vi fandt ud at det er en nødvendighed at kunne justere konstanterne kp, ki og kd “on the fly” ved brug af Bluetooth, og ligeledes det samme med offsettet, da det ellers ville tage lang tid at uploade programmet på ny for blot korrigere konstanterne. Vi fandt også ud af, at det er meget nemmere at få robotten til at balancere med store hjul end med små hjul. Her var tiden 3 minutter (and counting) vs. 2-3 sekunder.
Der arbejdes hårdt i labbet
References:
[1] Opgaveformulering http://legolab.cs.au.dk/DigitalControl.dir/NXT/Lesson5.dir/Lesson.html
[2] Philippe Hurbain, NXTway
The chapter contains a java program Sejway.java that can be used as a starting point for experiments with a self-balancing LEGO robot.
[4] Robotic Ideas & Instructions, AnyWay - Build a SegWay in under an hour!
[5] HITechnic, HTWay - A Segway type robot
[6] nxtprograms, NXT Segway with Rider
Ingen kommentarer:
Send en kommentar