Våren 2024 hadde Kristian Blom som masteroppgave å videreutvikle hardwaren fra prosjektoppgaven og utvikle software slik at robotarmen skulle kunne brukes likest mulig slik som den kunne originalt.

Denne wikisiden inneholder en oppsummering av masteroppgaven samt notater for praktisk bruk av armen. Koden finnes på github. 



Oppsummering (abstract)

Innvevde datasystemer er et ingeniørfaglig felt med stort bruksområde. Enten man vasker klær eller holder et ellers ustabilt jetfly horisontalt innebærer de fleste prosesser i dagens verden bruk av en datamaskin. De mange maskin- og programvareløsningene som utvikles til disse prosessene er ofte både billige og lett tilgjengelige for hobbymakere, noe som utvider feltets bruksområde ytterligere: artige prosjekter utenåpenbar verdi ut over det læringsutbyttet de tilfører prosjektenes innehavere. 

Dette prosjektet tilstrebet å reparere en 6DOF-robotarm som ble donert til et studentdrevet verksted på NTNU, Omega Verksted, hvis spesialitet kan sies å være artige hobbyprosjekter. Inspirert av de mange robotbartenderne som finnes i barer verden over ble det satt som mål at armen skulle kunne bevege seg med slik styrke og nøyaktighet at den ville behjelpelig til å blande drinker, og at kontrollsystemet skulle være enkelt nok til at det kunne tas i bruk av folk uten en faglig bakgrunn i robotikk.

Tre kontrollenheter ble utviklet rundt mikrokontrolleren STM32F303, med grensesnitt slik at hver enhet er i stand til å styre to likestrømsmotorer med tilhørende relative enkodere, samt innhente og prosessere data fra treghetsmålere av typen LSM6DSM over I2C. Enhetene kommuniserer med hverandre over CAN-buss, og med eksterne enheter via RS232/UART.

Programvareenheter som implementerer en PID-regulator for styring av leddposisjoner via motorspenning, ble utviklet for å kjøre på mikrokontrollerne. Under uviklingen ble verktøy slik som SOLID-prinsippene og systemkravspesifikasjon tatt i bruk med formål om å oppnå vedlikeholdbarhet og standardisering på tvers av systemmodulene. Kinematikk håndteres av MoveIt, et program under Robotic Operating System-paraplyen, og kjører på en ekstern datamaskin som kommuniserer med armen over UART.

Resultatene indikerer at systemet er marginalt kompatibelt med det forespeilede bruksområdet. Objekter med en lengde opp mot 80 mm langs den korte aksen og med en masse opp mot 0.8 kg kan manipuleres til en presisjon på 10 mm/10°. Systemet ble ikke funnet å ha oppnådd den ønskede graden av autonomi. Planlegging av enkle bevegelser er tilgjengelig (altså en positurendring A → B) men oppgaveplanlegging (altså A → B → C) er det ikke. Systemet viser derimot stort potensiale for å kunne utvides med slik funksjonalitet. Imidlertid var det store problemer tilknyttet bruken av treghetsdata, og både maskin- og programvare behøver videre arbeid dersom presisjon og styrke skal kunne forbedres.

Hardware

Hardwaren beskrevet på hovedsiden til armen ble byttet ut med egendesignet hardware bestående av seks PCB-design. Filosofien var "bytt ut alt som kan erstattes, og som ikke krever endring av armens chassis". Noe av den orignale hardwaren ble derfor værende igjen, og var viktige designfaktorer i utviklingen av PCB-ene: DSUB15-kontakt i  enden av lineærleddet, 16-leders flatkabel som ligger langs hele innsiden av lineærleddet, 20-leders flatkabel som forbinder øvre og nedre del av torso (se fig på siden), og de 6 DC-motorene med tilhørende kvadraturenkodere. Skruehull for festing av PCB'er kan også nevnes som en honorable mention, de var også viktige for designet. Ellers er alt byttet ut/fjernet (et eller annet om han grekeren og båten hans).


  • Prosessor: STM32F303RET6 (72MHz, 32bit Arm Cortex M4)
    • UART: kommunikasjon med ekstern kontroll-datamaskin (115200 Baud)
    • CAN controller: kommunikasjon mellom prosessorer
    • I2C: kommunikasjon mellom prosessor og IMU
    • USB (funker ikke): samme som UART
  • Krystall: 16MHz
  • Motordriver: DRV8215A (PWM-styring)
  • Enkoder: HEDS-9100 (500 cpc, NB: 5V)
  • IMU: LSM6DSM
  • CAN transciever: TJA1057BT
  • Spenningsregulator: LM317HV
    • 3.3V til de fleste komponenter
    • 5V til CAN-transcievere og enkodere
  • DC-motorer (modellnr 100% sikkert kun for twist/pinch)
    • Rail: Pittmann DC040B-2 (30.3V BDC)
    • Shoulder: Pittmann DC054B-5 (30.3V BDC)
    • Elbow: Pittmann DC040B-3 (24V BDC)
    • Wrist: Pittmann DC030B-3 (30.3V BDC)
    • Twist: Escap 23LT2R (12V BDC)

Som nevnt i abstractet funker ikke IMUene. Fant aldri ut av akkurat hvorfor, så kontrollsløyfa er per 29.09.24 ganske enkelt kun mellom enkodere og motordrivere. USB funker heller ikke, mest sannsynlig pga feil i kretsdesignet, så all kommunikasjon med kontroll-datamaskin foregår over UART.


Arkitekturen oppsummert

Armen kommuniserer med omverdenen gjennom en DSUB15-kontakt som inneholder signaler for UART/RS232 og USB, lokalisert i den ene enden av lineærleddet. Inni armen er det tre kontrollenheter som er nesten like: én STM32F303 styrer to motorer med PWM og tilbakekobling fra enkodere. Motordriverne har også funksjonalitet for å måle strømtrekk, men dette brukes bare for å sikre mot for høy strømtrekk fra motorene. 

  • Enheten montert i torsoen er ansvarlig for UART-kommunikasjon, og videreformidling av informasjon til de to andre enhetene via CAN-buss. I tillegg tar den inn et signal fra en optocoupler som fungerer som endestoppswitch for lineærleddet. Denne styrer lineærleddet og skulderleddet.
  • Enheten montert i skulderen er ansvarlig for å kommunisere med IMU0 (skulderbevegelse, se fig) via I2C og formidle dataen tilbake til enheten i torso via CAN-buss. Denne styrer albueleddet og håndleddet.
  • Enheten montert i hånda er ansvarlig for å kommunisere med IMU1 (underarmsbevegelse) og IMU2 (håndbevegelse) over I2C, og formidle dataen tilbake til enheten i skulderen via CAN-buss. I tillegg tar den inn et signal fra en optocoupler på twist-leddet som sier noe om leddets absolutte posisjon. Denne styrer twist og pinch.

Merk, igjen, at ingen av IMUene faktisk virker, så CAN-bussen brukes i praksis bare til å sende settpunkter fra torso til de to andre enhetene.

Softwarearkitektur

De forskjellige softwaremodulene kan deles inn etter abstraksjonsnivå slik som i figuren til høyre: Peripherals, drivers, control og kinematikk. Kolonnene representerer kategorien funksjonaliteten som modulen er knyttet til, og en modul på høyere abstraksjonsnivå benytter seg av funksjonalitet/informasjon fra modulene på lavere nivå – fortrinnsvis innen samme kategori.


AL1: Peripherals

Det første abstraksjonsnivået går på konfigurasjon av peripherals på STM'en. Filene er automatisk generert av STCubeMX, et grafisk grensesnitt for peripheral-config som ST tilbyr "gratis" i den forstand at man bare trenger å registrere seg på nettsiden deres for å laste det ned. ST definerer også en HAL for bruk av konfigurerte peripherals som gjøres tilgjengelig via disse filene (tror jeg, skriver dette litt på gefühlen. Se hva det står i masteren/includepaths i koden på git). Bruken av CubeMX bryter litt med open-source-idealet for oppgaven, men sparte sinnsykt mye tid i forhold til om jeg skulle skrevet all den lavnivåkoden selv. Modulen unit config er et unntak her, den inneholder diverse konfigurasjonskonstanter jeg har funnet på selv.

AL2: Drivers

Hardwaredrivere? Hardwaredrivere. Funksjoner og structs som definerer bruken av en hardwareenhet i forhold til prosjektet. For eksempel definerer modulen motor driver funksjonen go forward, som abstraherer bort timer/counter-registre definert i modulen tim i AL1.

AL3: Control

Reguleringssløyfer, funksjonalitet som knytter sammen prosjektet til en helhet. De fleste modulene i dette laget inngår direte i main-loopen som kjører på mikrokontrollerne. CAN-meldinger blir parset og håndtert, PID-er blir oppdatert, etc. Tilstandsmaskinen går, kort sagt, bare ut på om armen er i en operasjonell eller kalibrerende tilstand. Hvis operasjonell, så skjer alt main-loopen definerer. Hvis kalibrerende, så går armen gjennom en kalibreringsprosedyre som skal ende i at armen peker rett oppover.

AL4: Kinematics/UI

Dette (foreløpig) øverste abstraksjonslaget definerer et sett med ROS2-noder og et par andre programmer som er ansvarlige for å løse kinematikken til armen og tilby et brukergrensesnitt. Per 29.09.24 fungerer dette ved at brukeren manipulerer en 3D-modell av armen i MoveIt, en robotsimulator, som så regner ut en tidsserie av posisjonssettpunkter for alle leddene i armen slik at den ender opp der brukeren ville. Denne tidsserien overføres til armen via UART-grensesnittet med en frekvens på 100Hz (igjen, dobbeltsjekk med oppgaven), og PID-sløyfene for hvert enkelt ledd forsøker å holde tritt. Det er ingen tilbakekobling fra den fysiske armen til simuleringen i MoveIt – for alt den vet finnes bare simuleringen. 


Onboard software (AL1-3)

Figuren til høyre oppsummerer hva som skjer i på mikrokontrollerne, fortrinnsvis i mainloopen. Boblene er utdrag av funksjonalitet som finnes på AL2 og 3, og pilene indikerer hva slags informasjon som blir sendt hvor. Mainloopen funker i hovedsak slik at den sjekker om noen av interrupt-drevne flaggene assosiert med de øvrige funksjonene er blitt trigget siden sist den kjørte, og så utfører funksjonen hvis det det har det. Eksempelvis vil en ny CAN-melding utløse et interrupt som lagrer meldingen og setter flagget via CAN receive handler, så håndteres meldingen neste gang mainloopen sjekker dette flagget via CAN transmit handler. 

Offboard software (AL4)

  • No labels