Når maskinlæring flytter ind i mikrokontrollere

Afstanden til virkeligheden

Du har måske prøvet det. 

En klassisk sensorpipeline bliver pludselig for langsom. Data skal ikke bare videresendes — de skal forstås, filtreres og prioriteres tættere på kilden. 

Men hver gang du flytter behandlingen til clouden, opstår der nye problemer: latenstid, ustabil forbindelse, datastrømme der vokser eksplosivt – eller krav om hurtigere reaktionstid, end netværket kan levere. 

Det er ikke clouden, der er flaskehalsen. Det er afstanden til virkeligheden. 

Derfor begynder flere udviklere at lægge intelligensen helt ud i kanten af systemet – på mikrokontrollere og embeddede enheder, hvor maskinlæring tidligere var utænkelig. 

Hvorfor flytte intelligensen helt ud til enheden?

I mange elektronik- og IoT-projekter er datapunkter kun halvdelen af sandheden. Resten ligger i timing, kontekst og lokal variation – ting, en cloud-model sjældent når at reagere på. 

Når ML-modeller kører lokalt på microcontrollers, får du: 

• lavere latenstid – beslutninger i millisekunder, ikke hundreder
• mindre datatransmission – kun relevante events sendes videre
• bedre robusthed – systemet reagerer stadig, selv når netværket ikke gør
• diskret og energieffektiv læring – perfekt til batteridrevne enheder
• privacy by design – rådata forlader aldrig enheden

Når virkeligheden blander sig

I laboratoriet er signaler rene, temperaturer stabile og spændingen konstant. Men i virkelige systemer møder du: 

• sensorer med støj og drift
  
• busser med varierende latenstid
  
• enheder, der sover og vågner energistyret
• CPU’er der nedskalerer clocken for at spare strøm
• radioer, der mister handshake midt i en inferenscyklus
• modeller, der ikke generaliserer på alle edge-scenarier

Og det er her, edge-ML for alvor bliver disciplin: At kombinere datavidenskab, komprimering, embedded systemdesign og signalbehandling til noget, der virker — hver gang. 

Typiske årsager til ustabil edge-intelligens

Stabil edge-AI kræver ikke kun en “lille, kompakt model”. Det kræver forståelse for, hvordan systemet reagerer under last, i varme, kulde, vibrationer og med uperfekte signaler. 

De mest almindelige fejlkilder er: 

• modeller trænet på for rene datasæt
• manglende quantization-awareness → modellen opfører sig anderledes på MCU
• race conditions mellem inferens og sensorlæsning
• DMA-konflikter i højt belastede busser
• sampling, der ikke matcher det, modellen forventer
• modeller der bruger for meget RAM og udløser uforudsigelige GC-cyklusser

Edge-AI, der holder til virkeligheden

Så hvordan designer du edge-AI, der holder, når modellen skal køre på en mikrokontroller med begrænset hukommelse, energi og støjfyldte input? 

1) Raw signaler vs. cloudforædlede data

Cloud-modeller er ofte trænet på pre-processerede datasæt. 

Edge-modeller skal kunne tåle: 

• støj
• lav opløsning
• uforudsigelig sampling
• sensorfejl og vibrationer

Det gælder med andre ord om at designe med udgangspunkt i, hvad enheden faktisk “ser” — ikke i ideelle datasæt. 

2) Determinisme vs. nøjagtighed

En model, der er 2 % mere præcis men tager dobbelt så lang tid, kan ødelægge hele realtidssystemet. 

Edge-AI handler om: 

• fast latency
• forudsigelig eksekvering
• lav RAM-kontention
• minimal blocking af kritiske tasks 

En “perfekt” model, der ikke overholder deadlines, er en dårlig edge-model. 

3) Variation vs kontrol

Du skal bevidst introducere: 

• jitter
• temperaturændringer
• bus-belastning
• signalstøj
• afbrudte forbindelser
• energisparemode under inferens

De fleste edge-fejl opstår, når input ændrer sig i tempo eller mønster. Test derfor modellen med varierende bevægelse, belastning og kontekst.