I dette projekt har vi lavet en SegWay, som holde sig opretstående vha. en PID kontrol. Derudover er der implementeret et interface til SegWay’en, som kan konfigurere PID kontrollen, styre SegWay vha. af en xbox controller samt streaming af udregninger fra NXT’en til PC. Alt dette har foregået via bluetooth.
Opnåede resultater:
SegWay’en kan holde balancen i længere tid, hvis bare der ikke kommer for mange påvirkninger udefra. Langt det største problem vi havde, var motor stall problemet. Det tog en del af vores tid, at finde ud af hvorfor det sker. Vi fandt løsningen i NXT hardwaren, som har nogle begrænsninger (se End course project session 3+4 - Motor stall). Det var meget tilfredsstillende at finde roden til problemet. Vi kunne af gode grunde ikke løse problemet, så motor stall ikke kan ske, da det er en hardware begrænsning. Men vi kan tage højde for det i vores software, og på den måde leve med begrænsningerne i hardwaren.
Det har været meget svært at tune PID’en, da det er meget svært at gentage forsøgene 100%. Vi havde mest succes med at bruge wikipedias fremgangsmåde for manuel tuning af en PID kontrol.
I starten skulle vi re-compile, hver gang vi ændrede på nogle af PID konstanterne, dette gjorde det meget bøvlet og tidskrævende at tune PID’en. Så vi lavede et interface til SegWay’en, så vi via bluetooth kunne konfigurere disse parametre live. Det hjalp en hel del på fintuningen, og vi opnåede at få SegWay’en til at holde balancen indtil den blev stoppet eller løb tør for strøm.
Vi lavede en fjernstyring af SegWay’en vha. en xbox 360 controller, som via PC og bluetooth kunne styre frem/tilbage og dreje. Det er implementeret, og viker perfekt, men det er ikke til megen nytte så længe SegWay’en har problemer med at holde balancen, når den påvirkes udefra.
Vi kommunikere mellem PC og NXT vha. bluetooth. Vi har ikke lavet nogen datasikring af denne kommunikation, dvs. det er et svagt punkt, da der ingen garantier er for overførelserne. Data bliver streamet i begge retninger, med den eneste garanti, at de data der kommer frem, er rigtigt formateret.
Fremtid:
Brugen af lyssensorer er ikke den optimale løsning for dette problem. Da de er meget afhængige af underlaget samt lyset omkring dem. Det var også derfor vi ville prøve med gyro sensoren, men den viste sig ikke at være nok. Så en fremtdig løsning ville være at bruge gyroen kombineret med f.eks. et accelerometer. Dette vil give en løsning som ikke er afhængig af underlaget, og dermed vil være mere anvendelig.
Konklusion:
Vi er tilfredse med det endelige resultat. Vi opnåede det vi ville. Nemlig at få nogle erfaringer med, hvordan en så ustabil konstruktion kan gøres stabil. Vi har fået en del erfaring med PID kontrollen, som vi også tager med herfra og arbejder videre med. Vi skal i det kommende semester, lave en full size SegWay som afgangsprojekt på ingeniørhøjskolen. Så det har været en meget værdifuld erfaring vi har fået gennem dette projekt.
Mål for denne session: Få sat SegWay’en op og testet at det hele virker. Ellers se de andres projekter.
Plan: Finde et sted at være, finde et ensfarvet underlag, teste evt. tune PID’en til de nye forhold
Resultat: Problemer med PID’en, SegWay’en vil ikke balancere pænt! Vi prøvede at tune og tune, fjerne tårnet osv. Men lige lidt hjalp det, SegWay’en kom aldrig til at stå ordentlig stille!
Vi ved ikke helt om det var pga. lysforholdende eller hvad det var. Eller om SegWayen var en smule eksamensangst…
Men efter præsentationen, prøvede vi lige på kontoret med de værdier vi vidste der virkede, og jep - det virkede?!
Konklusion: Utrolig irretterende at det ikke vil virke til præsentationen, men så måtte vi jo bare forklare nogle af de ting vi var kommet frem til. Især baggrunden og løsningen på motor stall problemet, som der helt sikkert er nogen der kan få glæde af i fremtiden.
Ellers var det en rigtig spændende og sjov dag. Det var meget spændende at se, hvad de andre havde fundet på at lave.
Mål for denne session: Få gjort SegWay’en klar til præsentation i morgen
Plan: Få tunet PID’en så godt ind som vi kan. Tjekke at BT kommandoer fungere begge veje.
Resultat:
Vi fik de sidste detaljer af PC brugerfladen på plads, så den nu fungere. Der er dog ingen fejlhåndtering, så den vil kunne gå i stå, hvis f.eks. forbindelse forsvinder midt i en transmission eller lign.
Der er heller ikke nogen form datasikkerhed/retransmission i transmissionerne mellem PC og NXT. det er en stream protokol der er lavet, noget ala UDP. Dvs. det eneste der er garanteret, er at dataen er formateret rigtigt, men ellers ingen garantier. For at være sikker på at NXT’en har modtaget nye PID parametre, udstøder den et lille beep, når en kommando er modtaget og forstået.
Sidste tuning af PID’en blev foretaget. Vi kører på bagsiden af en plakat, for at opnå ensfarvet underlag. Vi fik den indstillet så den kører til batteriet løber tør, eller indtil vi skubber for meget til den.
Mål for denne session: Fortsætte med PID tuning. Tilføje bluetooth[BT], så det er muligt at skrue på konstanterne live, samt få streamet de udregnede data til PCen, derudover også implementere xbox controller styring.
Plan: Få hul igennem på BT. På PC-siden har vi valgt at benytte C#, da vi senere ønsker at tilføje en xbox-controller, så det er muligt at styrer SegWay’en. Og vi har en tidligere implementation til controlleren, som er kodet i C#, så her kan vi spare lidt tid.
Lave en simpel protokol, så det er muligt at sende forskellige kommandoer til SegWay’en fra PC’eren
Vi vil kører BT og PID controlleren i hver deres tråd, så PID’en ikke skal vente på BT-kommunikationen.
Resultat:
Der kom hurtigt hul igennem til NXT’en via BT. Og vi fandt hurtigt ud af, at det ikke dur, at åbne/lukke forbindelsen heletiden. Så forbindelsen holdes åben, indtil en af enderne afbryder forbindelsen. Vi fik lavet en lille kommando-protokol, så det er muligt at vurdere informationerne der kommer fra PC’en og handle derefter.
Overstående kommadoer er tilrådighed. Kommando-strengen er udformet som følgende
[Command][Value];
f.eks. P50; vil give en proportional gain faktor på 0,5. P, I og D sendes over som en integer med en faktor 100. Dette er gjort, for at simplificere overførelsen af kommandoerne.
For at kunne følge bedre med i hvad der sker i PID’en. Har vi lavet mulighed for, at NXT’en kan streame forskellige parameter til PC’en. De sendes som en samlet streng, som PCen så klipper op i forhold til en kendt formattering af strengen
Strengen er formatteret som følgende:
E;[value];V;[value];L;[value];R;[value];$
Når denne streng bliver modtaget på PCen, klippes den op, og præsenteret på brugerfladen, som noget forståeligt, samt smidt direkte i en tekstbox, så det er muligt at smide måledata direkte i et regneark.
PC GUI
Xbox controller:
Vi har valgt at tilføje en xbox 360 controller for at kunne styre SegWay’en. Controller har 6 analoge inputs, som give bedre mulighed for at lave en remote control, fremfor f.eks. et tastatur. Microsoft har lavet det meste af implementation for os, igennem XNA frameworket, som er et framework til spiludvikling. Vi har i et tidligere projekt benyttet os af denne controller, og har derfor en implementering vi ved der virker. Så den skal “bare” flettes ind i dette projekt. Controlleren er ikke et krav, og kan deaktiveres i PC GUIen. Dvs man behøver ikke en controller for at kunne bruge programmet.
Oversigt over controller mapping.
Muligheden for at deaktiver PID’en, er en panik-knap. Altså den kan bruges, hvis SegWay’en er ved at køre ud over en kant eller lign. Den giver så også mulighed for at starte op igen, uden at skulle genstarte softwaren på SegWay’en.
Forward/backward flytter på vores mål-offset, så SegWay’en naturligt får overbalance til den ene eller den anden side. Meningen er så, at den gerne skulle kunne rette sig selv op igen, men det har den lidt problemer med.
Left/Right bliver henholdsvis lagt til og trukket fra pwm_left og pwm_right. Så SegWay’en ville kunne rotere omkring sin midterakse.
Konklusion: Vi nåede ikke så meget tuning af PID’en, da det tog længere tid, at få de andre ting op at køre. Men nu fungere alle kommandoerne, og der kan sendes en log stream fra NXT til PC. Så nu kan vi også følge lidt med i hvad der egentlig sker i SegWay’en.
Vi har fået lavet en tråd til BT og en til PID’en, og det fungere umiddelbart fint. Vi var lidt bekymret for, om BT tog for mange resourcer, men det ser ganske fint ud. I hvert fald det vi lige nåede at teste. Det er noget vi skal kigge lidt mere på imorgen.
Kommandoer fra xbox controlleren til SegWay’en fungere, nu kan vi styre SegWay’en remote. Dette er dog ikke særligt anvendeligt, før den er blevet bedre til at balancere. Da den pt. bare vil vælte hvis vi ber den om at køre frem eller tilbage.
Propotional term - Er den propertionale respons i forhold til den nuværende afvigelse. Output er 0, når afvigelsen er 0. Vha. Kp-konstanten, kan der skrues på, hvor stor denne respons skal være.
Integral term - Dette led integrere afvigelsen over tid. fastholder sit output når nuværende afvigelse er 0. Dette kan både løse og give et offset problem. Kan skyde over målet (overshoot). Vha. Ki-konstanten kan der skrues på dette led.
Deriviative (Differential) term - Forholder sig til retningen på afvigelse, er afvigelsen stigende bliver D positiv, er afvigelsen faldende bliver D negativ. D er en differentiering af nuværende og tidligere afvigelser. D kan dæmpe I’s overshoot, og dermed øge stabiliteten af systemet. Men er også følsom overfor støj på afvigelsen, og for meget D, kan give et ustabilt system.
Ligesom ved manuel tuning, starter man med at sætte Ki og Kd til 0, og skruer på Kp indtil den når sit critial gain Kc, dvs. når den oscillere stabilt. Herfter regnes Pc - som er oscillerings periodetid. Og skemaet ovenfor udfyldes. Det prøvede vi så og fik følgende resultat. Pc er fundet ud fra aflæsning af beregnede værdier. Denne er dog ikke helt pålidelig, da det bare er en estimering udfra en graf over de aflæste værdier.
Resultat:
Utrolig bøvlet, og meget svært. Vores konstanter er hardcoded i softwaren, så hvergang vi skal ændre på vores konstanter, skal vi downloade det “nye” program til NXTen, dette er utroloigt bøvlet. SegWayens ustabile natur gør det meget svært at gentage forsøgende 100%. Men vi endte dog med en acceptabelt fungerende SegWay. Den holder balancen, når bare man ikke påvirker den for meget (læs: ingen påvirkning). Selv en skygge under en sensor, kan få den til at vælte! Så der skal vist tunes lidt mere.
Vi prøvede Ziegler-Nichols metode også, men det var ikke med nogen succes. Som det ses, er der en stor forskel på de fundne gain konstanter i de 2 metoder. Der skal vist et mere stabilt system til, for at Ziegler-Nichols kan bruges hensigtmæssigt.
Løse vores motor stall problem. Problemet kan skyldes en af flere forskellige faktorer, eller en kombination af disse, vi har disse faktorer som mistænkte:
1. Garbage collectoren.
2. Strømbegrænser i NXT lith-ion batteriet.
3. Strømbegrænser andetsteds i NXT hardwaren.
Så vores mål i denne session er vha. af diverse testopstillinger, at finde årsagen til stall problemet.
Til beskrivelse af motor stall problemet lavede vi denne lille video, der viser en test hvor motor stall bliver fremprovokeret:
(om motor, osv.) sætte ud - Pludselig satte motoren ud
Plan:
1. Test af garbage collector: Vi vil fjerne muligheden for garbage collector fejl, på en simpel men effektiv måde, ved at installere et par forskellige c orienteret OSer på NXTen. Vi vil benytte ROBOT-C samt leJOS-OSEK operativ systemerne. Herefter vil vi skrive et lille testprogram som vil stressteste motorene ud fra hyppigheden af retningsskift og med forskellig PWM-værdier. Hvis motorene stadig efter denne test staller, må årsagen til problemet findes andetsteds, end i garbage collectoren.
2. Test af strømbegrænser i lith-ion batteriet: Til denne test er løsningen ret simpel, vi vil anskaffe os 6 stk. almindelige AA batterier, og afvikle vores motor testprogram, og observere om motorene staller.
3. Test af strømbegrænser andetsteds i NXT hardwaren: Hvis ikke de to overstående tests fanger årsagen til problemet, må den med al sandsynlighed ligge i NXT hardwaren. Vi vil se om ikke det er muligt at fremskaffe printdiagrammer over NXTen, og vha. af disse finde årsagen. Kan dette ikke lade sig gøre, må den sidste udvej være at skille NXTen ad. Og vha. af vores softwaretest, kombineret med et multimeter, forsøge at måle os frem til årsagen.
Resultat:
1. Test af garbage collector:
Opstillingen:
Koden: (Koden vi benytter i vores tre tests)
//********************************************************************************
// TEST Forward then Reverse
// ROBOTC on NXT
//
// This program allows your robot to move forward and reverse at assigned
// pwm. Shifting direction every delay(ms).
// Purpose of this test is to narrow down the current cut-off problem in the
// IC-driver, driving the motor-port B&C.
// - Jesper & Daniel
//
// Motors & Sensors
// [I/O Port] [Name] [Type] [Description]
// Port A none Motor Right Motor
// Port C none Motor Left Motor
//********************************************************************************
Som det ses, kan man hurtigt ændre de to parametre som indgår i testen, delay og pwm. Vi lavede et testsenarie hvor vi altid startede med et delay på 100ms samt en konstant pwm, vi hævede så løbende delayet til 200, 300 og 400ms. Vi lod hver test kører i 60 sekunder, hvis ikke motorene stallede indenfor dette tidsinterval fik testen et OK, stallede motorende, fik testen et ****. Vi noterede os at der var en sammenhæng mellem delay og pwm, jo større delay des svære var det at få motorene til at stalle. Samtidig så vi også, at en mindre pwm værdi gjorde det sværere at få motorene til at stalle. Se nedenstående skema, hvor disse tests er skemaført.
2. Test af lith-ion batteriet:
Indsamlede data:
Denne test var hurtigt overstået, vi skiftede lit-ion batteriet ud med 6 duracell alkaline batterier. Herefter kørte vi overstående ROBOT-C testprogram. Resultatet var at motorene stallede, i samme mønster som overstående skema viser. Vi kan således konkludere, at en eventuel strømbegrænser i lith-ion batteriet intet har med vores motorproblemer at gøre.
3. Test af strømbegrænser andetsteds i NXT hardwaren:
Indsamlede data:
Så er der “kun” hardwaren tilbage, vi har via legos egen dokumentation anskaffet os print diagrammer over systemet:
Includes documentation and schematics for the NXT and related sensors. The documentation enables you to design and develop your own sensors and actuators that can interact with and control the NXT through the various digital and analog interfaces.
I printdiagrammet over systemet noterede vi os, at Motor B og C bliver styret fra den samme motor-controller chip(LB1836M). En bi-directional motordriver til to styk steppermotorer. I dokumentationen for denne driverchip(LB1836M) kunne det læses, at den selv cutter strømmen hvis der bliver trukket mere end 800mW. Samt at man i sit design skal være opmærksom på, at der ved retningsskift for motorer genereres et ekstra strøm dræn. Dette ekstra dræn skyldtes, at du skal have vendt momentet i motorens rotor, samt gearingen. Dette får rotoren til kortvarrigt at stå stille, mens den står stille, nærmer strømdrænet sig det, der mest af alt kan betegnes som en kortslutning. Så for at driverchippen ikke skal brænde af, er den beskyttet således, at den selv cutter for strømmen. Dette er lige præcis vores senarie…
Diagrammet over de to driverkredse nedenfor:
Løsning(er):
Nu skulle man tro at løsningen så bare ville være at flytte den ene motor over på motorport A, således at man nu enten benytter motorport A&B ell. A&C istedet for B&C - Desværre var dette ikke løsningen, da der blot dukkede et nyt motor relateret problem op. Når man benytter f.eks. 90% pwm på begge motorene, viser det sig at der er forskel på hvor hurtigt de to motorer kører, på trods af at de har den samme dutycycle. Motor A køre væsentligt langsommere end motor B ell. C. Forskellen var så stort at det let kunne ses med det blotte øje. Nu havde vi reelt to valg for at omgå stall problemet:
Løsning 1 - Benytte A&B ell. A&C ved at lave en skaleringsfaktor således at motor A’s manglende rotation bliver kompenseret. Dette burde kunne lade sig gøre, dog kan det være ret svært at finde den korrekte faktor, faktoren er ikke nødvendigvis linær. Et andet problem som ville opstå med denne løsning er at du er nødt til at sætte et pwm loft på motor B&C. Da det jo ikke er fysisk muligt at pulse med mere end 100%, f.eks. hvis skalerings faktoren, når motor B bliver pulset med 98% er 5%. Så skal motor A pulses med 98*1.05 =~ 103% som jo ikke kan lade sig gøre.
Løsning 2 - Benytte B&C dog med vores nye viden i baghovedet. Vi kan gribe denne løsning an på to måder. Enten ved, at vi i vores software sætter et loft på max_pwm, som kan vælges nogenlunde fornuftigt ud fra vores delay vs. pwm skema… Det ses at motorene slet ikke staller på noget tidspunkt med 55% som max pwm. så med 55% som max_pwm ville man være sikker. Denne løsning er dog ikke optimal, man kan sagtens forestille sig at man engang imellem havde brug for alle 100%. Det viser sig at løsningen rent faktisk kommer af sig selv, dette kræver “blot” at man har en god PID i balance. En god PID, har nemlig ikke de voldsomme udsving omkring dens balancepunkt. Som en dårlig(for voldsom) PID har, eller eks. Brian Bagnalls “bangbang” control fra SejwayBad. Disse former for styring vil man derfor aldrig kunne benytte.
Konklusion:
Vi har med succes via vores forskellige test og testopstillinger, først fået “kogt” problemet ned, herefter isoleret det til motordriver chippen. Dette resultat er vi godt tilfredse med, da det virkelig har været til stor gene og irretation for projektet. Dette er også grunden til at vi tillod os at bruge 2 sessioner på problem knusning. Med vores nye viden kan vi endelig håndtere stall problemet, og komme videre med vores Segway projekt.
Prøve nogle forskellige sensorer, og vælge en at arbejde videre med.
Plan:
Prøve at lave nogle indledende målinger på de 3 sensorer vi har fået fingrene i.
Gyrosensor
RCX anglemeter
NXT Lyssenor
Først vil vi lave nogle målinger på lyssensorerne, for at se hvordan de opfører sig. Disse data vil give os et praj om hvordan vi skal tolke dem. Herefter vil vi prøve at lave exercise 4 igen, men denne gang med en rigtig PID…
Resultat:
Gyrosensor: Denne sensor giver os en vinkelhastighed grader/sek max 360 grader/sek. Dette lyder jo perfekt til at finde ud af, hvor meget motorene skal pulses med, for at kompensere for bevægelsen. Men problemet med dette er vores nulpunkt! Vi kan ikke med sikkerhed sige, hvor vi er. Da gyroen giver os en vinkelhastighed. Dvs. hvis SegWay’en står stille nok, længe nok, vil værdien fra gyro nærme være nul. Og så har vi problemet! SegWayen er nu ikke i balance, men det mener gyroen. Dette kan omgås hvis vi benytter et accelerometer i samspil med gyroen, dog har vi ikke adgang til dette pt. I første omgang dropper vi gyroen, med mindre vi kan fremskaffe et accelerometer.
RCX anglesensor: Med denne sensor prøvede vi at lave et rigtigt pendul, som monteres i et tårn på SegWay’en. Og ud fra positionen der læses fra anglesensoren, vil vi have et tal for afvigelsen fra lodret. Det største problem med denne sensor, var at der ikke rigtigt er implementeret noget til den i leJOS. Så vi prøvede at læse på dens rå værdier. De giver bare ikke rigtigt mening, enten læser vi forkert, eller også virker det ikke. Vi kunne tilmed også notere os at man ikke kunne læse hurtigt nok fra den. Så vi besluttede ikke at bruge denne opstilling.
Lyssensor: Vi lavede en lille testopstilling og et program, som samplede så hurtigt som muligt, og gemte de samplede data i en txt fil på NXT’en. Når programmet kørte påvirkede vi sensorerne, og bagefter hentede vi de gemte data og plottede disse ind i en graf.
Opstillingen for Lyssensor:
Koden:
public void doTest(){
data.writeSample(”Sensor 1″);
data.writeSample(”Sensor 2″);
Jo tættere sensoren er på et objekt des større er den samplede værdi.
Jo længere væk fra sensoren er fra et objekt, des mere upræcis bliver målingerne. Dette ses på grafen ovenfor. Jo mindre værdi, des tykkere er stregen, dvs. at når sensoreren kommer langt væk fra et objekt, så svinger de samplede værdier meget mere, end hvis sensoreren er tæt på et objekt.
Ud fra disse indledende målinger, kan vi konkludere, at jo tættere sensoren er på et objekt, des mere pålidelig er den enkelte sampling. Dette er lidt et problem, når man laver en SegWay. Da den bevæger sig frem og tilbage. Vi har derfor besluttet, at bruge 2 lyssensorer, en foran og en bagpå. I softwaren benytter vi så den sensor der er tættest på jorden hele tiden. Da dette, ud fra vores målninger giver de mest pålidelige data.
SegWay’en:
Selve konstruktionen har vi fået inspiration til, fra NXTWay-GS projektet
Vi har lavet et par små ændringer, NXT’en er monteret lidt lavere, og der er monteret et tårn.
Tårnet giver en smule stabilitet, den gør at der skal mere energi til at flytte SegWay’en. Dette gør at SegWay står bedre stille, men tilgengæld også falder “hårdere”, hvis den vælter. For store udsving, gør det umuligt at holde balancen.
Men det virker ikke! SegWay’en stall’er med det samme. Vi kan ikke rigtigt gøre noget. Den står og prøver at holde balancen, men efter 3-4 sek stall’er den. så går der et lille sekund, så “vågner” den op igen. Men herefter går der kun 1-2 sek, så stall’er den igen. Det er et problem! Efter snak med nogle andre grupper og noget surfen rundt på nettet. Er vi kommet frem til, at det kan være Garbage Collector’en i leJOS, som kan være problemet. Dette skal undersøges noget mere.
Konklusion:
Stall-problemet blev den overskyggende faktor i dag. Vi nåede ikke målet i dag! Og ved stadig ikke helt hvad vi skal gøre med stall-problemet. Vi kan jo se på nettet, at andre har fået det til at virke. Så det må være en forklaring og en løsning på problemet. Så det må vi undersøge videre i næste session. Dog har vi fået lavet en konstruktion vi er tilfredse med. Vi har også lagt os fast på hvilken sensor vi vil benytte, nemlig 2 lyssensorer.
Goal:
Don’t make others mistakes… Get experience from other projects like this.
Plan:
Surf the internet, find similar projects, read their documentations, and see if we can use that for anything.
Result:
We quickly found, that not everybody thinks that the gyro-sensor is the saviour. There is some split oppinions about the sensor best suited for the job, Gyrosensor, Lightsensor, Accelerometer, proximitysensor. So we decided, with a littlte help from Caprani, to try out some different sensors, to find out which one that is best suited for the job of keeping a segway upright.
Then there is the control algoritm, what type should that be? As with the sensors, we searched the internet to see if there was any experience we could draw from. And again, different people had different ways to do it! But we will use a PID control.
The sensors
NXT light sensor
NXT Ultrasound sensor
NXT Gyro sensor
NXT Accelerometer sensor
RCX Proximity sensor
RCX Tacho counter
Ad 1: We will start with this sensor, or we will use two. Becourse their are availible right away. And we have seen it work on youtube! So with this approach we can concentrate on making the control algoritm. See further down.
Ad 2: Is out! The ultrasound sensor is to slow, the ping pong with sound just takes to long.
Ad 3 and 4: We have to buy both sensors, if we want to test both. But we only have money for one, so we choose the gyro sensor. We have found a solution called NXTway-G, that uses this gyro sensor from hitechnic, so again, this can be done. We have contacted the micro sweatshop (mikro værkstedet) to hear if they have one we can buy.
Ad 5: We got two RCX proximity sensor and should i theory be better for the job than the light sensors. If they work like we think. But we have to look into how they work later on.
Ad 6: The SegWay is an inverted pendula, so with the tacho counter, we will try to make a normal pendula suspended in the the SegWay, and the use it to measure the angle it’s tilting. But this contruction has its downfalls. The pendula should have some sort of dampening to stop it from oscillating. But we will look into that later in the project.
Conclusion:
We will use the two light sensor setup to perfect a PID control, and then try the other sensor with this control. So we can get an idea of the sensors, and not the control algorithm. So next step is make the SegWay balance with two light sensors and a PID control.
Goal:
The purpose of this labsession is to make an initial effort to come up with a description of the end course project..
Plan:
Discuss either each project in the list of projects or consider new suggestions. For each proposel that you discuss consider the hardware/software platform needed, e.g. number of NXT’s, program on a PC, sensors, actuators, … Furthermore, for each proposal figure out the overall software architecture and the software architecture on each component, e.g. a behaviour-based architecture on each NXT and a server architecture on a PC. Use the course litterature as reference.
list of projects considered with a short description of each.
for each project describe the hardware/software platform and software architecture of each component.
try to point out the most difficult problems to be solved in each project.
for each project we will describe what we would expect to be able to present at the end of the project period.
The choosen project will be described more detailed.
Result:
Possible projects
Self parking car
Racing game
Tic-Tac-Toe
Rubics cube solver
SegWay line follower
First weeding…
The remote controlled tic-tac-toe game, rubics cube solver is out, too much lego constructions.
Making a car that is able to make a parallel parking, and able to figure out whether the parking space is big enough for it.
a Self parking car would consist of one NXT, one or more ultrasonic sensor(s), two motors.
The software will consist of three software modules: An obstacle detection module.
Behavior-handling module with respect to each behaviors priority value.
Lastly the behavior(s) module(s).
Racing game Game for inspiration f1
Inspired from games like the one above. The diffecult part of this project, is making the remote control. This could be build with lego and another NXT, or an application on a PC. beside that, the car should be able to detect if it is on the verge and simulate that by restricting the motor output. This means that the car should have a sensor that can detect changes in the surface. And the race track has to have clear difference between road and verge. We could use lego road elements to construct the racing track.
A racing car will consist of 1 NXT, 1 Light sensor, 2 motors.
The remote control will consist of 1 NXT, 2 motors
The software in the car will consist of a communication module to the remote control, a module to analyze the surface of the road and a restrictor module to restrict motor output when the car is in the verge.
Remote control will consist of a communication module to the car, a module that analyzes the position of the motors with tacho count, and translate it to forward/backward and left/right movement.
Segway line follower
Combination of lab 4 and lab 5-6
We will make the balancing part as a PID-control and the following part as another behaviour that adds to the output of the balancing part.
We will start by making the robot able to balance and then making it able to follow a line.
Result:
We will make a line following Segway. This means that we need an accelerometer… We will start by experimenting with the accelerometer, to get an idea of how it works and the precision of it. Then we will begin to contruct the PID control, and make the robot stand.
When the balancing part is perfected, we will start to add line following behaviour to the robot.
Make the following experiments with the BumperCar to investigate the functions of the Arbitrator: Press the touch sensor and keep it pressed. What happends ? Explain.
we looked at the arbitraitor code, we could see that the code didn’t allow a behavior to run more one til i a row, see lejos.subsumption.Arbitraitor.java line #51
if(i != currentBehavior) // Prevents program from running same action over and over again.
Therefore our BumperCar runs the hitwall behavior once and then does nothing if we keep the bump-sensor activated.
Both DriveForward and HitWall have a method takeControl that are called in the Arbitrator. Investigate the source code for the Arbitrator and figure out if takeControl of DriveForward is called
when HitWall is active.
It doesn’t because the arbitrator handles the behaviors in a priorioty organized mannor, that is decided by the index of the behavior-array
Behavior b1 = new DriveForward();
Behavior b2 = new HitWall();
Behavior [] bArray = {b1, b2};
as we notice Hitwall is index as 1, wich is of higher priority than DriveForward( which is indexed 0). Therefore Driveforward won’t take control.
Implement a third behavior, Exit. This behavior should react to the ESCAPE button and call System.Exit(0) if ESCAPE is pressed.
Exit should be the highest priority behavior. Try to press ESCAPE when HitWall is active (hint: set the back up time to 10 sec to be sure HitWall is active when ESCAPE is pressed). The Exit behavior is not activated immediately. Why (hint: look in the Arbitrator) ?
When ESCAPE is pressed while HitWall is activated the buttom press will not be registered, since DriveForward.takeControl() returned
true at last visit. the arbitrator will hang at:
if(currentBehavior >= i) // If higher level thread, wait to complete..
while(!actionThread.done) {Thread.yield();}
“jamming” the possibllity for registering a ESCAPE.isPressed. So the Exit behavoir is NOT activated at all.
Can it happend that HitWall continues controlling the motors even after the suppress method has been called from the Arbitrator (hint: the answer is yes, explain)
The answer is NO, because the supress method for the current-behavior IS beeing called from the Arbitrator, and the method is invoked, which also fits with our tests, since the motors was stopped when we pressed ESCAPE.
Implement a fourth behavior PlaySound that react to the ENTER button and play a sound when the ENTER button is pressed. Insert an instance of this behavior in the Behavior array between the instances of Drive Forward and HitWall. Now Drive Forward has the lowest priority, PlaySound is next, then comes HitWall and Exit has the highest priority. Activate HitWall by a touch sensor press. While HitWall is active press ENTER and then ESCAPE. What happens ? Explain.
Because of the nature of the lejos arbitrator, we will wait for the the HitWall to finish, and the move forward. Because right after the action-thread with the HitWall-action is started, the main loop will run thru the behaviors again, to see if any is ready to take control. DrivingForward will always return true, so it will be ready to take control at first run thru the behaviors, and because DrivingForward has a lower priority than the CurrentBehavior, it will wait for the current behavior to finish before doing anything. This behavior then blocks any future attempts to take control from higher prioritiesed behaviors.
#53 if(currentBehavior >= i) // If higher level thread, wait to complete..
#54 while(!actionThread.done) {Thread.yield();}
So nothing but moving forward will happend.
But if DrivingForward didn’t block, the PlaySound would, because it, like DrivingForward, has a lower priority than the CurrentBehavior. So it will then again block (Line #53 and 54 in lejos.subsumption.Arbitrator.java) for more inputs. So after HitWall it will PlaySound, and not act on the escape, bacause it didn’t see the escape-button being pressed.
We tried to make our own abitrator, that uses javas interrupt mechanism. And now behavior of the agent was much better, we where now at all time able to i.e. Exit the program. Now the program wasn’t “hanging” in the HitWall action anymore, so much more useful. See sourcecode at bottom of page.
We tried to make a motivation-factor version, but the arbitrator isn’t finished yet. In this version we added a eagerFacctor variable to those behaviors where it made sense. This factor can be counted up everytime takeControl on that behavior is called and f.ex. the ESCAPE button is pressed. Then it returns priority+eagerFactor, and thereby the priority will rise. The eagerFactor will be reset, when the beehaviors action-function is called. But as mentioned earlier the arbitrator in the sample-sourcecode isn’t finished yet.
Conclusion:
The lejos arbitrator could be made more smart. The hassel about going from one behavior to an other, when a one is active. With the interrupt-mechanism, the downfalls of from the lejos arbitrator was overcomed, and the behavior of the program was much more useful.
Notes: shorter X-pin for our bump-sensor made it easier for the sensor to register a wall hit.
