Svenska ElektronikForumet

Snabbt är alltid relativt, du får väl räkna på hur många klockcykler dina beräkningar tar, och sedan bedöma om det är tillräckligt snabbt.

Okej.

Vad är egentligen snabbt enligt er? 1 sekunds beräkning?

Det beror ju helt på, ibland kan 10s vara snabbt nog, ibland är 1 mikrosekund väldigt långsamt.

Tänk att du ska styra en robotarm i en visst val position. Då vill man inte ha några överskjutningar. Därför är det viktigt att ha ett snabbt styrkort. Men vad för styrkort vet jag inte.

Du bör nog göra din hemläxa först, innan du bestämmer dig.
Analysera responstider mm.

Okej. Jag får göra det och sedan dra beslut vilket kort jag ska använda. Tack.

Du nämnde GSL, vet inte om det bara var ett exempel eller om du måste använda det. Det gäller då att de funktioner du vill använda är portade till Arduino-miljön eller att det går att porta. Det behöver inte vara speciellt märkligt men det är något att kolla upp i alla fall.
Sen tycker jag det är onödigt att låsa sej till just Arduino Due, det finns andra processorer som har hårdvarustöd för flyttal som kan vara bra alternativ.

Men som sagt, man måste göra hemläxan först och sätta upp en lämplig och fungerande krav-spec.

Al_Bundy skrev:Tänk att du ska styra en robotarm i en visst val position. Då vill man inte ha några överskjutningar. Därför är det viktigt att ha ett snabbt styrkort. Men vad för styrkort vet jag inte.

Vad menar du med "överskjutningar"? Och vad är det för typ av robotarm?

Handlar det om att styra en robotarm är en Due alldelse förträfflig. Om man kan dra paralleller med 3d-printers där den fungerar bra.

Sen vad som är snabbt? Processorn ska vara så snabb att resultatet är beräknad i tid till att det ska användas. Det är helt olika situationer om beräkningen ska vara klar innan varje styrningstilllle säg 20 kHz eller om dét handlar om uppdatering av displayen med 100 Hz. Det värsta är algoritmer med variabel tidsåtgång som en del solvers till ickelinjära problem som stegar sej fram tilll svar. Om sedan inte processorn hinner med så kan man alltid försöka få tag i en snabbare processor. Eller man börjar analysera problemet, vad är det som tar tid? Kan man göra annorlunda? Måste man beräkna så mycket, går det att linjarisera? Osv.

hawkan skrev:Handlar det om att styra en robotarm är en Due alldelse förträfflig. Om man kan dra paralleller med 3d-printers där den fungerar bra.

Sen vad som är snabbt? Processorn ska vara så snabb att resultatet är beräknad i tid till att det ska användas. Det är helt olika situationer om beräkningen ska vara klar innan varje styrningstilllle säg 20 kHz eller om dét handlar om uppdatering av displayen med 100 Hz. Det värsta är algoritmer med variabel tidsåtgång som en del solvers till ickelinjära problem som stegar sej fram tilll svar. Om sedan inte processorn hinner med så kan man alltid försöka få tag i en snabbare processor. Eller man börjar analysera problemet, vad är det som tar tid? Kan man göra annorlunda? Måste man beräkna så mycket, går det att linjarisera? Osv.

Jag kommer endast hålla på med linjär reglerteknik där modellen ändrar sig över tid. I praktiken blir den olinjär, fast inte matematiskt.

Glattnos skrev:

Al_Bundy skrev:Tänk att du ska styra en robotarm i en visst val position. Då vill man inte ha några överskjutningar. Därför är det viktigt att ha ett snabbt styrkort. Men vad för styrkort vet jag inte.

Vad menar du med "överskjutningar"? Och vad är det för typ av robotarm?

Jag ska bygga en inverterad pendel.

hawkan skrev:Du nämnde GSL, vet inte om det bara var ett exempel eller om du måste använda det. Det gäller då att de funktioner du vill använda är portade till Arduino-miljön eller att det går att porta. Det behöver inte vara speciellt märkligt men det är något att kolla upp i alla fall.
Sen tycker jag det är onödigt att låsa sej till just Arduino Due, det finns andra processorer som har hårdvarustöd för flyttal som kan vara bra alternativ.

Det enda jag kan tänkas lära mig är att plocka fram en Atmel uC och programmera den från grunden. Men jag vet inte exakt hur mycket jobb det är och om det är mer värt att köpa färdigt kort. Kunskapen är nog inte fel. Målet är att skapa ett reglersystem, dvs algoritmerna.

Codesys har jag en stor erfarenhet av.

Codesys Matrix Library €250.00 plus VAT https://store.codesys.com/matrix-librar ... re=default

Har du kollat Scientific Python på Pi?

Utveckla matematik i ett kompilerat språk är 100'000 omkompileringar, tandagnissel och gråt, enklare att först testa fram fungerande lösningar i Matlab, Octave, Scipy etc. och sedan översätta dem till C/C++.

Inverterad pendel? Jag tycker du kan testa med en Due i så fall. Min känsla, dock bara känsla, är att det krävs en del men trots allt begränsat med beräkningar för att hålla balans på en inverterad pendel. Jämför med flight-controllers för multikoptrar eller modellhelikoptrar, de har precis vuxit ur 8-bitars kontrollers och använder 32-bitars. Där utgås från diverse givare för att korrigera läget, ungefär som du vill göra.

Sen kanske du inte ska använda alltför generella fall i dina beräkningar utan kondensera ner det till exakt det du behöver. Kanske du kan göra egna, slimmade versioner av matrisberäkningarna.

En inverterad pendel är väl inga problem en 8-bitar? En AVR på 16-20 MHz måste ju vara snabb så det räcker.

Jag är inne på hawkans linje.
En F4 baserad flightcontroller.

- Bra pris
- Hög klockfrekvens
- FPU
- Alla sensorer du behöver på köpet.

Exempel:
LÄNK