Robotics

Home/Robotics

December 2016

Stumbler – part III (more cowbell)

By |December 26th, 2016|3D Printing, Electronics, Robotics|

PID-kontrolleren fungerte. Lavpassfilteret for aksellerometerdata fungerte. Det samme gjorde kalmanfilteret. Det hjalp likevel så inderlig lite når aksellerometeret støyet så mye, og i tillegg var så følsomt for vibrasjoner at enhver motorrespons resulterte i spinnville data. Stumbler ville ikke stå på egne hjul.

Derfor byttet jeg ut IMUen i noe mer beefy. Jeg gikk for BNO055 fra BOSCH. Dette er mer et SoC enn en sensor, da den gjør sensor fusion for deg. Den snakker i likhet med LSM9DS1 I2C, men har et mye enklere oppsett. Du kan bruke den i forskjellige modus. Enten som en tradisjonell IMU, eller som en 9DOF sensor med fusion-algoritme som snurrer i bakgrunnen. Ut får du ferdigtygde data, i form av quaternions, Eulervinkler, rotasjonsvektor, lineær aksellerasjon, gravitasjon og heading. Det finnes nok enda bedre sensorer der ute, men denne kostet rett under 40 USD og var svært enkel å bruke. Se BNO055.cpp for bare bones implementasjonseksempel, inklusive kalibrering.

Jeg har kranglet med LSM9DS1 i ukesvis, men bare et par timer etter å ha byttet IMU, så hadde jeg tegn til virk. Den balanserte nå såpass bra at den tålte å krasje i vegger, samt å få en dytt. Den tok seg nå inn igjen.

PID-parametrene kan nok fremdeles forbedres, iom at den er litt “tense” (Vi har hatt noen spektakulære krasj på steingulvet her). Under, så ser du en av de første prøveturene med BNO055 – med ukalibrert sensor (kan jo ikke kaste bort tiden med å lese spesifikasjon…)

Den var fremdeles litt vill av seg, så jeg myste litt i databladet. Det viste seg at BNO055’en har en autokalibreringsalgoritme. Man kan lese ut kalibreringsdata fra kalibrerningsstatusregisteret. Ved å vifte litt rundt i lufta med botten, inntil man leser ut “1” for bit 6 & 7, så oppførte ting seg enda bedre etterpå.

Under, så balanserer den helt fint på sofaen. Relativt stram pute, og absolutt ikke et flatt underlag.

Må kanskje presisere at den ikke akkurat er fjellstø ennå. Den tryner ofte med pannebrasken ned i flisgulvet, og forsøker av og til å stikke av – i ganske voldsom fart. Signalet fra PID-kontrolleren er vel å betrakte som non-insane i tiltintervallet [-3, 3] grader elns – foreløpig.

Jeg har ihvertfall nok virk til å kunne bygge en 2.0 versjon av botten med større batteripakke, samt litt mer optimal plassering av sensoren. Plata, som alt er montert på nå, er litt wobbly, og stepperne kunne gjerne hatt enda litt mer kraft. Vurderer også å kanskje lage et lite PCB med stepperkontrollere og IMU integrert.

Repo med modellfiler og (prototyp)kode finnes her: https://github.com/hansj66/Stumbler

October 2016

Stumbler – part II (a few iterations later)

By |October 11th, 2016|3D Printing, Electronics, Rants, Robotics|

Å forsøke seg på noe man ikke kan, er makerens mantra, samt en ypperlig kilde til læring (gitt at man da ikke ender opp med en Darwin Award i prosessen). En god læringskurve krever et minimum av surfe-skills, samt et Dirk Dale soundtrack.

Å gjøre noe som involverer flere ting man ikke kan – minner mer om å surfe på bølger, pisket opp av Dirac. Jo større fart du har inn i ting som ser ut som delta-funksjoner, jo vondere gjør det når du treffer.

Newton…

Jeg startet med det jeg kunne, dvs å source deler, samt 3D-printe det strukturelle “limet”, som holdt alle dele sammen. Deretter var det bare å rappe noen strategiske kodefragmenter fra the interwebs, og så hadde man funky balansebot. Right… ?

Well…

Å skru sammen en bot, samt koble sammen noen stepper-drivere, en mikrokontroller og en IMU viste seg å være ganske grei skuring. Etter å ha bannet litt over databladet til IMU’en, så hadde jeg kommunikasjon med denne via I2C. Hjul snurret og jeg klarte å måle akselerasjon og gyrorater.

Nå var det kun litt tafsing på parametrene til PID-regulatoren, så kom botten til å stå som en påle. Right… ?

Not so.

Akselerometeret gir deg målinger i G på tre akser. Du kan da regne ut vinkelen til botten. Akseleromteteret har en del støy og det er helsikes følsomt for vibrasjoner, men du kan stole på lavfrekvenskomponenten i målingene.

Gyroen gir deg en rate ut, ikke en vinkel. Hvis du kjenner dt, så kan du regne om gyroraten til en delta vinkel. Den drifter over tid, men du kan stole på høyfrekvenskomponenten i målingene.

Du kan kombinere disse målingene på flere måter. Man kan gå for et komplementærfilter, et Kalmanfilter, eller ta den helt ut og også dra inn magnetometer-komponenten i noe litt mer hårete, som f.eks Madgwicks AHRS-algoritme.

Sensor fusion er et løst problem, selv om Kalmanfilter, eller Madgwick-algoritmen gir meg vondt i hodet når jeg forsøker å se under panseret. Jeg liker å adressere litt mer praktiske problemstillinger. Som f.eks. å krangle med fysiske lover.

Newtons 3. lov viste seg heldigvis å fremdeles være i effekt, da den slo inn med full kraft fra første step. Bokstavelig talt.

Motorene har ganske mye masse, og når du sender dem et step-signal, så gjør de akkurat det de er designet for å gjøre. De flytter rotoren nøyaktig 1/200 rotasjon, mens statoren står helt stille. Right… ?

Not so.

Jeg gikk for minste motstands vei i det mekaniske designet, så alt er veldig godt boltet sammen. En liten vibrasjon i bånn vil forplante seg helt opp i toppen av botten, og gjerne forsterkes litt på veien også. Hvilket i sin tur gjør at MEMS-sensorene i IMUen går haywire. Dette danner så en fin liten feedback-loop, som gjør ethvert forsøk på PID-tuning komplett meningsløst.

Jeg hadde tidligere, implisitt antatt at botten kunne håndtere momentan aksellerasjon, da jeg hadde foret kontroll-outputen fra PID-algoritmen rett inn i en funksjon av typen n/control == PWM-frekvens. Dette ville ha fungert utmerket i en verden der Newtons første lov ikke hadde vært i effekt.

Jeg hadde nå en bot, som var fundamentalt uenig med Newton på to punkter. Og jeg endte som vanlig opp med å være megler.

For å komme vibrasjonene til livs, så endte jeg i kveld opp med en step-algoritme som er noe smidigere. Jeg bruker fremdeles n/control fra PID-regulatoren, men nå for å signalisere ønsket PWM-frekvens. Deretter er det en opp til en interrupt-drevet step-funksjon å akselerere så smooth som overhodet mulig opp til denne, før neste signal kommer fra PID-kontrolleren.  PID-oppdateringer skjer nå på 200Hz og step-funksjonen kjører på 7 kHz. Hvis dette ikke drar ned sensorstøyen, så får jeg finne opp en inertia damper, evt surre fast murstein på botten. Stay tuned.

September 2016

Stumbler – part I (Code name “Karma”)

By |September 25th, 2016|3D Printing, Electronics, Robotics|

Rasket med meg en BBC Micro:Bit hjem fra jobb. Dette er en liten datamaskin, som blir delt ut til alle 11-12-åringer i England. Det sitter en nRF51822 (ARM Cortex M0) fra Nordic Semiconductor på den. Den har magnetometer og akselerometer. Man har knapper og leds. Det er en høyst hackbar sak, og ungene kan programmere den i JavaScript, Python, eller i Microsoft sin Block Editor. Hvis du kobler Micro:Bit til en datamaskin via USB, så vil den dukke opp som en ekstern disk. Man slipper ganske enkelt den kompilerte hex-fila ned på denne disken og så er den programmert. Du kan også programmere den via blåtann fra telefonen, hvilket er en genistrek m.t.p. å senke terskler m.h.t. programmering, for ungene.

Siden jeg er hønngammal – og liker litt eldre språk, så valgte jeg å istedet sette opp Micro:Bit som target i mBed sin online-kompilator. Jeg kan da leke meg med den i et språk jeg er komfortabel med – d.v.s. C++. Jeg har ikke brukt denne verktøykjeden siden jeg fikk min første (og frem til nå – eneste) mBed i 2010, så jeg kniste litt når jeg så at mBed/Twitter-prosjektet mitt fremdeles lå i skya når jeg logget på.

Anyways, dette er en høyst hackbar sak,  den er lett å programmere, og den er liten. nRF51822 har nok oomph til å gjøre ganske mye, så jeg fant ut at en balanserobot kunne være en ok utfordring.

Micro:Bit har en edge-connector, som man kan putte inn i et eksperimentkort, som har breakoutpinner og breadboard. Jeg fant ut at jeg bare var to stenger, et par motorer og litt plast unna noe som lignet en robot, så jeg designet noen smådeler i Fusion 360 for å holde ting sammen. Printingen var unnagjort på et par kvelder.

Siden kortet ikke har gyro, så hektet jeg på en LSM9DS1 fra Sparkfun (også rappet fra jobben). Denne har akselerometer, gyro og magnetometer. Du kan kommunisere med dette via SPI eller I2C. Som motorer, så valgte jeg et par 1,7A Nema17, som jeg hadde liggende. Disse blir drevet av hver sin DRV8825 stepperkontroller. Alt dette kan kontrolleres fra Micro:Bit via 6 ledninger (2 stk for I2C og 4 stk for STEP/DIR-tilkoblingene på stepperkontrollene)

Siden motorene trives best på ganske høy spenning, så har jeg en småfeit batteripakke i toppen av roboten. En LD1117V33 regulerer batterispenninga ned til 3,3V.

Jeg bannet initielt litt over I2C-kommunikasjonen, men har nå fin (og rask) datastrøm fra sensorene. Det hjelper alltid å skrive sin egen kode – istedet for å bruke forvirrende biblioteker, som insisterer på å abstrahere hver eneste beskrevne bit i databladet. Stepperne er relativt greie å styre via de analoge pinnene på Micro:Bit. Ved å skrive en verdi til en analog pinne, så har man gratis PWM-output fra denne. Den analoge verdien er i intervallet 0 – 1023. “0” == 0% duty cycle og 1023 == 100% duty cycle. Man kan så bestemme frekvensen ved å sette perioden på den analoge pinnen.

Stepperkontrollerne tolker en høy/lav-puls på STEP-pinnen som step-signal, så her PWM-kontroll ideelt m.t.p. eksempelvis PID-kontroll av motorhastighet fra observert feil i balansevinkel.

Jeg har nå en mekanisk og elektrisk fungerende plattform for balanserobot. Jeg lurer litt på om jeg skal booste spenninga på stepperne opp til 24V ved å bruke 14650 LiIon-celler istedet for NiMH. Dette for å øke momentet og makshastigheten på motorene. Ellers, så ser ting ut til å virke rimelig bra.

Nå kommer den vanskelige biten, d.v.s. å integrere sensorinput fra flere kilder i kontroll-loopen. Modige sjeler kan google “sensor fusion / kalman filter” for å danne seg et inntrykk av hva som nå står for døra.

Når alt funker og er stabilt, så publiserer jeg kode, skjema, komponentliste og STEP-filer på GitHub. Koden er såpass generisk at den bør fungere på det meste av mikrokontrollere man kan utvikle for i C++. Det eneste Micro:Bit-spesifikke er to kall for å lese/skrive data over I2C og to kall for å sette PWM duty cycle og frekvens på pinnene til stepper-kontrolleren.

img_3271

img_3269

April 2016

Mobile Beer Platform – mk I

By |April 5th, 2016|3D Printing, City Beest, Götterdämmerung, Robotics|

Sånn går det når man glemmer å slå av 3D-printeren sin i løpet av påskeuka. Før man vet ordet av det, så har robotene i kjelleren formert seg. Hils på skjelettet til MBP – mk I. Foreløpig totalt utestet. What could possibly go wrong…?

Mobile Beer Platform

Mobile Beer Platform

Charge indicator

Charge indicator

Motor cowling

Motor cowling

Power button

Power button

May 2010

Vi utfordrer datalagringsdirektivet !

By |May 10th, 2010|Parallel Universe, Programming, Robotics|

Istedet for å stage-dive ned i hylekoret, så lar vi heller datalagringsdirektivet inspirere oss til litt “roll your own”- crypto. Jeg antar at dette også kan gjelde flere – kanskje til og med de som datalagringsdirektivet er myntet på ?

Jeg lovte for 14 måneder siden en flaske Crème de menthe til førstemann på jobben som klarte å knekke en RSA cipher med en astronomisk 25-bits nøkkel. Det er fremdeles ingen som har hentet flaska – og jeg må innrømme at jeg er bittelittegrann skuffa over kollegene.

Lett inspirert av Simon Singhs “The Code Book”, samt Neal Stephensons “Cryptonomicon”, så kjører vi nå på med 2 crypto-challenges på TimeExpander (Må innrømme at jeg håper bittelittegranne på at Mr.Black kliner til med et vakkert CUDA-basert angrep her). Førstemann som tar oppgave 1, har sikret seg en av de viktigste ingrediensene til en Long Island Iced Tea. Tar noen oppgave 2, så er jeg målløs – selv om vi fremdeles er milevis unna sterk kryptering (den er kanskje noe i nærheten av 3300 bits nøkkel).

De fleste har vel allerede tafset på PGP en eller annen gang i livet, men det er jo alltid mye morsommere å implementere selv.

Algoritmen er mainstream RSA, og encoding er den samme for begge oppgavene. Blokkstørrelsen er på 6 ASCII-tegn. (Eks. ABABCC kodes om til tallet 065066065066067067, som så krypteres til en blokk)

Challenge 1

Eksponenten er her 13, og modulus er 67678791760781523437. Dette koker ned til en 64-bits nøkkel, og på en gjennomsnittlig laptop, så vil du finne faktorene i denne på litt over 6 sekunder i GHC-interpretern (Vil anbefale å laste ned factors.hs + avhengigheter ). Når du har funnet faktorene, så kan du beregne dekrypteringseksponenten med Euclids litt mer hårete algoritme. Har du funnet faktorene p & q, så beregner du (q-1)*(p-1) som du sender inn som første parameter i algoritma. Eksponenten sender du inn som andre parameter. Tredje-(ut)parameter gir deg den überhemmelige dekrypteringseksponenten du trengre for å få ut klarteksten.

Meldinga er:

29643486281214166221
31754568318096595222
18866919755208611117
55040353993448503713

Challenge 2

Samme eksponent, men litt mer spenstig modulus (

678648287556408617566069222098092902319638579724763875423231780887782326290241

8744935562591753666395263203428475274164718768544714991285086897539719863791118

6738188516300965912313252519347371139520672783464398243462618474462789121940809

9114315856609681214446240262839281497875178239697354955962530884728294167958882

1810144649133171263643828721099263415616160241960347422876670232802323954916153

203458325605447155696165221304951552737653043673235876789182276584555029158316

306025226515214149292624577476985142800101585906921256842656760345220750940800

773391507375838096484475814715991700775116950996058350550623510986740512768220

5901173058576812786694734254940160714262362347388194271548813831795003045136323

4931117226890457894237151923513658606018447058856460088641456991246871553798871

6321044744986262680135316851295044487842324672058126529415662142249679080097680

3872828355872743194309262734480141233313566807508114373357542300631203369795753

89505524061770859087441543471000292176019523256017430869)

Meldinga er:

Blokk1:

377115642735908117634179214447605612540218329872407165870138140622416033271

897546885685495927151782530732361682604928598246196985267990225557751408420

636520989535311669448003738074476220310868379166880607681043991761231
Blokk2:

385003780674235349593353258943692556522883981777147082636946189123366585988

38762006293275050883553693166734753353162741955253799670514390196940297464

753492879286385543131085777359141224795483055628098023956281545231
Blokk3:

62262973840636976542976222853245241536540257579793119620781087099370189332

145848943412187781153561779540870288111901778724323262918299776123951572354

8842888816551428732027287524442967514199041656065173235375891920166015625

Blokk4: 688579136852433871931703296

(Konkatener linjene i h.h.v. modulus of hver blokk til ett tall – worpress sliter med lange ord…):

Vote:

May 2006

Sommerprosjekt ?

By |May 5th, 2006|Electronics, Robotics|

Kjenner det begynner å klø litt etter å lage noe igjen… Har allerede fosøkt meg som pyrotekniker (endte på legevakta), bygget en liten Tesla Coil (540W), Lifter (#62 ), Beam robot og en del mer.

Har et halvferdig elektrostatisk prosjekt og et påbegynt mamekabinett, men jeg vil bygge noe som det er litt schwung over. Hørte jeg noen si “pulsjet” ? … ;)