Navn på robotsystemAwes’un Solaireity (udtales “our sun, Solaireity”).

Navne på gruppemedlemmerLuca Casa, Tobias Jensen, Jamie Møller Christensen.

Robottens udseende og opbygning

Robotten er opbygget i dele, som passer sammen for at skabe den endelige robot. Der er fire hoveddele: Foden, platformen, armen og sensorpanelet.

Opbygningen er valgt med udgangspunkt i, at robotten skulle være i stand til at dreje 360 grader. De første konstruktioner havde et problem med dette, da ledningerne risikerede at blive viklet rundt om robotten. Konstruktion blev derfor lavet for at overkomme dette, da al elektronikken kører med rundt, når robotten roterer. Derudover var det et ønske, at robotten kunne rette sig ind i to planer.
Derfor blev der arbejdet med to motorer, hvoraf den ene sammen med gearing, kunne dreje sensor panelet, men samtidig skulle holde det fast, når det ikke kørte. 

Robottens ene motor er gearet, sådan at vinklingen af fladen LDR-sensorerne foregår i et passende tempo. Dette fremgår på billedet af robotten længere oppe i blogindlægget. Der er brugt et snekkegear til at forhindre fladens bevægelse, medmindre motoren er tændt, rykker fladen sig altså ikke.

Motoren, som bruges til at dreje robotten mod solen, er sat for enden af en arm/stang. Denne arm har samme formål som gearingen til vinklingen af robottens sensor-flade.

Vores system har to motorer, en til rotering og en til tiltning af den øverste platform med LDR-sensorer.  

  1. Motoren, der styrer rotationen, er monteret på en lang stang, der er fæstnet på robotten. Motorens egen rotation går ud i et hjul, som kører rundt om robotten. Den primære grund for denne opsætning er at robotten ikke vikles ind i sine egne ledninger. Samtidigt tilbyder denne løsning en naturlig gearing. jo længere stangen er, des mere gearing vil der forekomme.
  2. Motoren, der tilter den øverste platform, skal sikre lysets indfaldsvinkel på LDR-sensorerne er vinkelret. Den øverste platform må derfor ikke kunne ramme ind i de øvrige dele, når den tiltes. Det anses derfor nødvendigt at tilpasse den øverste platforms højde over det resterende for denne problemstilling. Ligeledes har det givet anledning til at kunne indsætte passende gearing heriblandt snekkegearet.

Vi har benyttet 4 LDR-sensorer. De er placeret på et breadboard på toppen af robotten, hvor de står i hver sin kvadrant af denne. Imellem dem er vægge, som kaster skygge over LDR-sensorerne hvis lysets indfaldsvinkel ikke er rimelig tæt på vinkelret på alle sensorerne.

Motoren for rotationen af platformen har skiftet placering af flere omgange gennem udviklingsprocessen. Første gang var fordi den ikke kunne bære robottens vægt efter montering af hele modulet for tilt-funktionaliteten. Anden gang skulle vi finde en løsning, hvorpå ledningerne ikke viklede sig ind, når robotten dreje rundt.

Sensorernes placering har ændre sig lidt. Vi indså hurtigt at der var brug for at adskille sensorerne med vægge. Efter en del tid gjorde vi væggene større og rykkede sensorerne helt ind til væggene.

Resultatet heraf var at vægten steg og den øverste platform faldt af, når den tiltede en tilpas mængde.

Robottens hardware

kredsløbstegning:

Til kredsløbet:

– IC1: Er er L293D Quadruple Half-H Driver. Bruges til motor kontrol.
– VCC1: Batterierne er genopladelige, derfor er deres spænding på 1,2V, hvilket giver en samlet spænding på 4,8V til kredsløbet.
– R5: 10kΩ ved indendørs test, 1kΩ ved udendørs test.
– R6: 10kΩ ved indendørs test, 1kΩ ved udendørs test.
– R7: 10kΩ ved indendørs test, 1kΩ ved udendørs test.
– R8: 10kΩ ved indendørs test, 1kΩ ved udendørs test.

 

Delkomponenter:

 

Robottens opførsel

Robottens opførsel som overordnet at:

  1. Aflæse og beregne data udfra LDR-sensorernes værdi.
  2. Bestemme om den skal rotere til venstre, højre eller bare blive hvor den står.
  3. Bestemme om den skal tilte op, ned eller bliver hvor den står.

flow-chart for opførsel:

 

koden for Arduino:

//LDR-Sensor pins ----------------------------------------------
const int sensorPin1 = 5; // connect sensor to analog input 0
const int sensorPin2 = 4; //analogInputPin1
const int sensorPin3 = 3; //analogInputPin2
const int sensorPin4 = 2; //analogInputPin3
//LDR-Sensor pins end ------------------------------------------

//Motorpins -------------------
//Technically direction doesn't matter on these, as the wires on the motors can just be flipped to change direction to match the code. Semantics though.
const int motorPinLeft = 5;
const int motorPinRight = 6;
const int motorPinUp = 10;
const int motorPinDown = 11;
//Motorpins end ---------------

//Ranges within which the robot won't tilt/rotate:
const int halfIntervalUpDown = 20; //tilt
const int halfIntervalLeftRight = 60; //rotate

//Minimum speed (voltage to motor) of the rotating motor:
const int minSpeed = 160; //Find a reasonably low value which won't make the motor stop due to friction/resistance.

void setup()
{ 
  pinMode(motorPinLeft, OUTPUT); //MotorPinRight
  pinMode(motorPinRight, OUTPUT); //MotorPinLeft
  //Debugging
  Serial.begin(9600); 
}

void loop()
{
  //LDR1-4 not used for anything but averaging, uses less method calls to analogRead() this way:
  int LDR1 = analogRead(sensorPin1); // read the analog input from the LDR.
  int LDR2 = analogRead(sensorPin2); //LDR2 = sensorPin2 read.
  int LDR3 = analogRead(sensorPin3);
  int LDR4 = analogRead(sensorPin4);
  //Figuring out where the robot gets hit by light, and the intensity of it. Also, figuring out that aligning similar calculations is neat:
  int avgRight =(LDR1+LDR3)/2;
  int avgLeft = (LDR2+LDR4)/2;
  int avgTop =  (LDR1+LDR2)/2; 
  int avgBot =  (LDR3+LDR4)/2;

  //Stop/Don't rotate if within a certain range: 
  if (avgRight + halfIntervalLeftRight > avgLeft && avgLeft > avgRight - halfIntervalLeftRight) 
  {
    analogWrite(motorPinLeft, 0);
    analogWrite(motorPinRight, 0);
  } 
  else 
  {
    Serial.println("Rotation calibrating");
    //Rotate in proper direction:
    //Current:
    int turnSpeed = abs(avgRight-avgLeft)/4; //Det viser sig ikke at være nødvendigt at tjekke retning for at angive hastighed?! HVORFOR? Fortegn kan fjernes :^).
    analogWrite((avgRight>avgLeft ? motorPinRight : motorPinLeft), constrain(turnSpeed, minSpeed, 255)); 
    //minSpeed is adjustable, lower values = lower minimal voltage to motor, 0 makes it stop.  
  }
    
  //Tilting or not:
  if (avgTop + halfIntervalUpDown > avgBot && avgBot > avgTop - halfIntervalUpDown)
  { 
      analogWrite(motorPinUp, 0);
      analogWrite(motorPinDown, 0);
  } 
  else 
  {
    Serial.println("tilt calibrating...");
    analogWrite((avgTop>avgBot ? motorPinUp : motorPinDown), 255);
    //constrain(abs((avgTop-avgBot))/4, 0, 255) - for rotation if 255 always isnt good.  
  }
}

Koden har gjort som forventet gennem hele udviklingen med få undtagelser. Et par gange har vi oplevet at robotten pludseligt ikke drejede eller tiltede som den skulle, eller at den gjorde det i den forkerte retning. Et eksempel er at vores sensor-flade ikke blev tiltet da vi ellers læste værdier der indikerede at den burde. Et andet eksempel er at vores motor til drejning kørte til venstre når LDR-sensorerne på højre side læste de højeste værdier.

I begge eksemplerne var problemet i hardwaren, henholdsvis en løs forbindelse og at ledningerne var vendt forkert til motoren, var årsagerne til disse.

Lige fra starten af udviklingen var det klart at koden var betydeligt sværere at teste og debugge, da vi nu potentielt har hardwareproblemer at tage højde for. Da vi besluttede os for at ville dreje motorerne i to retninger, ville vi lave en H-bro selv, hvilket lykkedes med noget besvær. Udfordringen ved dette var dog ikke kun at lave et kredsløb til en H-bro, men også at benytte den med koden. Vi måtte derfor kigge både kode og hardware grundigt igennem før vi ændrede noget, da det aldrig var helt klart og tydeligt hvor disse problemer opstod og skulle løses.

Et tredje tilfælde af hardware som påvirkede kodens funktionalitet er rækkefølgen af LDR-sensor og modstanden der bruges til spændingsdeling. Disse var vendt forkert på en sensor, hvilket gav os nogle aflæsninger, som koden sagtens kunne bruge, men gav uønsket opførsel i robotten.

Video

IMG_1251

Konklusion

Robotten løser opgaveformuleringen udmærket. Motoren der roterer platformen efter solen, får en varierende strømstyrke alt efter hvor langt den skal dreje. Dertil er der benyttet en stang til at “geare” rotationens hastighed ned. Da vores robot kan dreje 360 grader rundt, vil den altid forholde sig til solens placering. Når solen er gået ned bevæger robotten sig ikke længere. Når solen står op igen vil robotten rette sig efter dette.

Vi har i stedet for en konstant vinkel til fladen brugt endnu en motor til at vinkle denne.

Indendørs opfører robotten sig hensigtsmæssigt, dog har vi haft behov for at skifte modstande når vi går udendørs, da robotten ellers står stille. Efter udskiftningen opfører robotten sig igen efter gruppens intentioner.

Til videreudvikling kunne det være nyttigt at tilføje funktionalitet til dynamisk at justere de modstande, der bruges til spændingsdeling, sådan at robotten kan tage højde for lysintensiteten i de givne omgivelser. Metoden hertil kunne være at benytte en variabel spændingsdeler, som justeres med softwaren i arduinoen. En anden metode ville være at gøre tærsklerne, der styrer hvornår robotten skal bevæge sig, til relative størrelser afhængig af LDR-sensorernes aflæsninger

 

Leave a Reply