Få de daglige nyheder fra Version2 og Ingeniøren. Læs mere om nyhedsbrevene her.

close
Ved at tilmelde dig accepterer du vores Brugerbetingelser, og du accepterer, at Teknologiens Mediehus og IDA-gruppen lejlighedsvis kan kontakte dig om arrangementer, analyser, nyheder, job og tilbud m.m. via telefon og e-mail. I nyhedsbreve, e-mails fra Teknologiens Mediehus kan der forefindes markedsføring fra samarbejdspartnere.
steens kælderlab

Robotten ruller!

Så blev det tid til en opdatering af projektet med min selvkørende robot. Se første del HER.

Først og fremmest har jeg valgt at herligheden skal drives af to børsteløse (BLDC) motorer, én per bælte. Jeg har valgt en forholdsvis beefy model på 270kv hvilket i nominelle termer vil sige, at øges forsyningsspændingen med én volt, stiger omdrejningerne med 270 rpm. Motoren er rated til 32V/70A, og yder op til 2,14 Nm. Med en hjulradius på ca. 6 cm betyder det, at hvert bælte 'trykker' med op til ca. 4 kg (hvis ellers jeg havde uendeligt vejgreb)

Illustration: Steen Garbers Enevoldsen

I realiteten er kraften dog noget lavere, da jeg ikke forsyner motorerne med de maksimale 32V. Jeg har valgt at basere strømforsyningen på 2 stk 25V/4AH LIPO batterier i parallel. Motoren har en aksel i begge ender, hvilket gør det nemt at montere en quadraturencoder til positonsfeedback.

Til normal brug i f.eks. R/C biler og fly kontrollerer man BLCD motorer med en ESC (electronic speed controller), men da jeg har brug for positionsfeedback gav det mening at kigge på en lidt mere avanceret controller. Jeg har valgt at bruge en controller fra amerikanske oDrive robotics, som meget belejligt tilbyder simultan kontrol af to motorer. Jeg er ret begejstret for oDrive, som tilbyder ganske avanceret funktionalitet for rimelige penge. Og så er det open source!

Illustration: Steen Garbers Enevoldsen

Quadraturenkoderne giver op til 8192 pulser per omdrejning, så jeg har rigelig opløsning til mit formål - med en hjulomkreds på omkring 35 cm giver det teoretisk en positionsopløsning på langt under én mm.

Nu til det mekaniske! Da motorerne er 'outrunners', hvilket vil sige at motorens klokke drejer rundt med akslen overvejede jeg først om man kunne installere motorerne i hjulnavene. Fordelen ved den metode er, at jeg dermed kan minimere bredden af det færdige design. Ulempen er, at jeg belaster motorlejerne uforholdsmæssigt meget (og potentielt problem med køling?). Da jeg ikke har behov for den minimering af bredden valgte jeg en mere traditionel konfiguration hvor motorerne sidder parallelt med drivakslerne og kraftoverførslen klares med tandremme og skiver. Jeg valgte at lave en smule udveksling mellem motor og aksel da motoren har 20 tænder og akslen 25.

Illustration: Steen Garbers Enevoldsen

Chassiset består udelukkende af 3d printede dele, M8 gevindstænger og en ordentlig røvfuld M8 møtrikker. Oprindelig havde jeg tænkt at jeg ville bygge robotten op på en træplade, men denne løsning ser væsentlig federe ud og da jeg har valgt at designe løs uden en egentlig gennemtænkt plan, er det en stor fordel at have alle afstande justerbare, så de værste bommerter kan justeres væk :) Dernæst får jeg bæltestrammer mekanismen foræret.

Jeg har valgt en Raspberry Pi (RPi 3 model B V1.2) til at styre herligheden. Den er monteret på undersiden af robotten og strømfødes gennem en lille 5V/10A R/C regulator.

Illustration: Steen Garbers Enevoldsen

Oprindelig havde jeg tænkt mig til de første tests, at forbinde en R/C receiver og så styre controlleren via PWM. Men der er en bug i oDrive som gør at det ikke umiddelbart virker, og i stedet for at spilde tid på at fikse det valgte jeg at lade raspberry pi controlleren forestå kontrollen som den under alle omstændigheder jo skal gøre i den endelige version.

Fjernstyringen klarer jeg med en ps3 controller som via bluetooth linkes til Raspberry Pi'en. Jeg har flikket en første primitiv gang kode sammen i python for at teste alle hardware elementerne.

En testkørsel nede i kælderlabbet er udelukket, da den frie gulvplads er særdeles begrænset og derfor sneg jeg mig op i stuen for at lave testen. Uheldigvis overværede hustruen et lille "bælte-spin" hvorved der straks blev nedlagt forbud mod yderligere tests på stuegulvet. Heldigvis har det lokale supermarked en P-kælder, hvor den nederste etage stort set aldrig benyttes. Perfekt til formålet!

Testen startede fint ud, og det ser ud til at jeg har rigelig buffer i den mekaniske konstruktion. Jeg ophævede trinvis begrænsningen på strøm og omdrejningshastighed indtil jeg ikke længere kunne opretholde kontrollen over robotten. Det skete ved ca. 15-20 km/t (som svarer til ca. 10-15% nominel kraft). Mon ikke den bliver mere styrbar når jeg får opgraderet bælternes trædeflade med et eller andet friktionsmateriale? Lige nu er det plastic mod epoxymalet beton = minimalt vejgreb!

Testene endte dog brat da jeg konstaterede røgudvikling. Jeg har ikke i skrivende stund færdiganalyseret fejlen, men umiddelbart ser det blot ud til at være en underdimensionering af motorledningerne som resulterede i smeltet isolering.

Jeg har haft kameraet med under testene, så de nysgerrige kan få syn for sagen i denne video:

Emner : Robotter
Steen Garbers Enevoldsen er civilingeniør, nørd og rodehoved.
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
  1. hvorfor bælter og ikke 4 eller 6 hjul ?
  2. jeg forstår hvorfor to joysticks kan styre blandt andet retningen.

- har du planer om at lave den brugermæssigt simplere rat-styring (retning) + frem/bak hastighed (som speeder + gearskift) ?
3. har du planer om en in-house 2D positionsbestemmelse ?
4. OG måske den helt nørdede on-board inerinavigation ?

NATURLIGVIS er det trin du har beskrevet, altså en styrbar platform, den helt elementære forudsætning for alt andet.
Men der er jo derefter interessante udfordringer i varianter af:
- 2D navigation (bestikberegning, inertinavigation, 2D positionsbestemmelse)
- ruteplanlægning (som forudsætter et "kort" / "gulvplan") og nævnte 2D avigation
og som du selv antyder forskellige anti-kollisionsvarianter.

Det kunne jo være du har en drøm ?

  • 1
  • 0

hvorfor bælter og ikke 4 eller 6 hjul ?

Dette projekt er for sjov og forhåbentlig lærer jeg noget i processen også. Den bedste forklaring på at jeg valgte bælter er, at jeg havde lyst til at prøve kræfter med at designe bælter og så ser det fedt ud :)

Jeg er ret sikker på at det rationelle valg ville være hjul...

jeg forstår hvorfor to joysticks kan styre blandt andet retningen.
- har du planer om at lave den brugermæssigt simplere rat-styring (retning) + frem/bak hastighed (som speeder + gearskift) ?

Jeg linker venstre joystick til venstre bælte og vice versa med højre. Hvis jeg giver ens input kører robotten ligeud. Hvis jeg giver mere input på det ene drejer robotten til modsatte side. Som du kan se i videoen er det ikke særlig let at styre på den måde :)

Det er slet ikke meningen at robotten skal styres manuelt. Den skulle gerne ende som et 100% autonomt køretøj, så jeg har ikke umiddeltbart planer om at rafinnere fjernstyringen, og dermed er svaret på næste spørgsmål...

  1. har du planer om en in-house 2D positionsbestemmelse ?

Yessir! Jeg har skaffet et LIDAR modul og vil prøve at lege med SLAM (Simultaneous localisation and mapping) så robotten i princippet blot stilles i et rum og så vil den på egen hånd køre rundt og samtidig generere en floorplan som efterfølgende kan navigeres efter.

  1. OG måske den helt nørdede on-board inerinavigation ?

Jeg har slet ikke tænkt sensorsiden til ende endnu.

Som jeg ser det er der to grupper af sensorer som er nødvendige:
- De nære/fysiske sensorer (kofanger, undgå at køre ud over en trappe, osv.): som grundlæggende samme som er i en standard robotstøvsuger

  • navigations-sensorer (LIDAR, inertial, ...) som gør at robotten kan danne sig et billede af omgivelserne på lidt større afstand.

Jeg vil umiddelbart tro at inertialnavigaiton ikke er nødvendig når man har lidar og forholdsvis nøjagtig positionering af bælterne? Men jeg er absolut åben for forslag!

Softwaremæssigt tror jeg at jeg vil prøve at kigge på http://www.ros.org .
Det ser ud til at være et godt grundlag at bygge videre på. Er der nogen som har gode forslag til andre frameworks man kan kigge på?

  • 2
  • 0

Tak for udtømmende svar.

ad 2: Forstået.
intuitivt ville jeg bare tro, at hvis du alternativt manuelt kan styre (følge et rute) med et rat, som oversættes til bæltedrift, så ville det efterfølgende være lettere.
Altså et delmål.
Det svarer jo til det man gør i et skib med autopilot, hvor en rute kan følges med een simpel kommando drej 30 grader (e.g. fra kurs 110 til kurs 140), idet for et skib drejeradius (strengt taget den kurve som følges) kun afhænger af rorvinkel og hastighed.
For et hjuldrevet køretøj er der jo bare en drejeradius for hver ratvinkel (5, 10, 15, 20, ...., 90 grader).
ad 4: Forstået.
Men ville det ikke være sjovt, hvis moderne, billigt, accellerometer (jfr. mobiltelefon) viste sig nøjagtig nok ? (kombineret med et ur).
Måske er det hyldevarer et sted (på nettet) (Rasppberry Pi).

Søg på "accellerometer raspberry pi" - der er phyton kode også.... utroligt.

  • 0
  • 0

ad 2: Forstået.
intuitivt ville jeg bare tro, at hvis du alternativt manuelt kan styre (følge et rute) med et rat, som oversættes til bæltedrift, så ville det efterfølgende være lettere.
Altså et delmål.

Jo det er måske ikke en helt tosset ide. Jeg skal under alle omstændigheder have lavet en model, som kan tage "drej 30 grader til venstre", og omsætte det til motorkommandoer.
Det vil jeg lige overveje lidt mere.

Men ville det ikke være sjovt, hvis moderne, billigt, accellerometer (jfr. mobiltelefon) viste sig nøjagtig nok ? (kombineret med et ur).
Måske er det hyldevarer et sted (på nettet) (Rasppberry Pi).

Jo det kunne være sjovt. Jeg flyver en del med quads, og en flightcontroller er baseret på accelerometre (og evt gyroer). Den slags komponenter er særdeles billige idag.

Søg på "accellerometer raspberry pi" - der er phyton kode også.... utroligt.

Jeg elsker åbensovs! Der er ufatteligt meget kode derude som dygtige mennesker deler med os andre dødelige.

  • 1
  • 0