mäta pwm med en atmega16?

[mmarks]

Jag håller på med ett projekt där en processor skickar ut en pwm till drivningen av en robot och en annan processor (atmega16) tar hand om balanseringen av roboten. därför vore det väldigt praktiskt att kunna mäta pwm-signalen så att en framkoppling kan implementeras för balanseringen.
Är det någon här som kommer på något sätt att göra detta?

[sodjan]

Vad är det du ska mäta?

[mmarks]

jag vill veta vilken pwm som skickas ut till drivningen så att jag snabbt kan motverka det uppkomna momentet istället för att behöva vänta på att roboten börjar tippa.

[Andax]

Titta lite på input capture i data bladet. Man kan latcha en räknare mha av en ingång.

[sodjan]

> jag vill veta vilken pwm...

Vad är "vilken pwm"?
Frekvens ? Pulsbreddsförhållande?
Och med vilken upplösning?

Jag antar att ni redan har konstaterat att en processor inte
klarar av båda funktionerna? Annars så blir allt väldigt mycket
enklare om man kör det i en processor.

[mmarks]

@ sodjan.
Pulsbredden är det jag vill ha, frekvensen är 400 Hz och pulsbredden varierar mellan 1 till 2 ms och det jag vill använda är förändringen i pulsbredd. vad gäller upplösningen har jag inte räknat exakt på vad som skulle behövas men "the more the merrier"
Som du säger så är det redan konstaterat att en processor inte klarar av jobbet.

@ Andax.
Jag känner till input capture, problemet är bara att timer1 redan ställer ut en pwm till balanseringen och den går inte att ersätta med någon annan timer eftersom de inte klarar frekvensen plus att de är upptagna för andra uppgifter.
Det skulle vara smidigt att använda input capture men då behöver jag en atmega som har dubbla 16-bitars timers och så vitt jag vet finns det ingen sådan till lågt pris?

[eqlazer]

Du kan inte låta de två processorerna prata med varandra istället för att mäta vad den skickar ut?
Tex med SPI där du skickar över de parametrar som bestämmer pulsbredden.

[sodjan]

Beroende på hur snabbt det hela behöver reagera så finns
ju alltid lösningen med filtreringoch ADC. Men sannolikt blir det
för långsamt. Vad är det den andra processorn behöver "veta"?
Att det finns en PWM signal över huvudtaget? Eller att det har
blivit en ändring i pulsbredd sedan förra mätningen?

Kan processor 1 kanske ha en extra signal som säger "nu har jag
ändrat pulsbredden"? Eller är storleken på ändringen avgörande?
(Eller en annan extra komm-linje som eqlazer just föreslog).

> vad gäller upplösningen har jag inte räknat exakt på vad som skulle behövas

Det är ju ganska avgörande för att avgöra om man har en lösning som "duger".
Samt hur snabbt det behöver reagera. Ska det "svara" inom en 400 Hz cykel?

[mmarks]

Processor 2 (som tar hand om balanseringen) behöver veta hur stor förändring som skett sedan senaste mätningen eftersom detta kommer generera ett nettomoment på roboten som balansdelen måste upphäva genom att generera ett åtminstone liknande moment åt andra hållet.
Anledningen till att jag inte har brytt mig om att räkna mer exakt på vilken upplösning som behövs är att det fortfarande är många parametrar som inte är spikade än vad gäller masscentrum, tröghet, moment från drivningen etc. Därför undersöker jag än så länge bara möjligheten att göra en framkoppling eftersom jag inte fullt litar på att den PID-regulator vi tagit fram klarar av den störning som blir när roboten accelererar/retarderar.

SPI skulle helt klart kunna vara ett alternativ, jag har dock ingen personlig erfarenhet av att programmera SPI så jag får rådfråga de i projektgruppen som kan det om det är möjligt med den setup vi har.

[sodjan]

Ja, det måste ju inte vara SPI, det beror lite på vad som är "ledigt".
Det kan vara enklare rent programmeringsmässigt att t.ex köra USART.
Bara slänga på en byte som repreesenterar duty cycle på USARTen...

[Swech]

Är det inte bättre att balanseringsprocessorn talar om för pwm processorn vad
balanceringen vill ha för PWM
Det bör ju vara relativt långsamt förkopp och kan fixas via UART t.ex.

Swech

[mmarks]

Det är två helt skilda system, vi har två motorer som sköter framdrivningen via två parallella hjul (processor 1) och en horisontell propeller som håller roboten i korrekt vinkel genom att vi mäter propellerarmens vinkel till marken (processor 2) och reglerar vinkeln på propellerbladen. Fördelen med detta är att vi har kunnat utveckla systemen helt individuellt samt att vi ville göra något annorlunda än den "vanliga" inverterad pendel-designen à la segway. Så processor 2 som sköter balansen ska inte styra framdrivningen på något sätt, den ska bara rätta sig efter rådande förhållanden. Balanseringen i stillastående fungerar fint med enbart en PID-regulator men för att slippa begränsa accelerations/retardationsförloppen vore det trevligt att kunna implementera en framkoppling för att förbättra responsen.

[Swech]

Men det förutsätter ju då att PWM signalen alltid är ett exakt svar på hjulens rotation.
Om roboten t.ex. kör på något så att hjulen spinner så blir det väl märkligt.

Åter till din fråga så är det ju så att timers kan göra flera saker om man planerar för det.
T.ex. en capture timer kan du ha att den bara räknar på och utifrån det även genererar andra
timer signaler förutom capture

Swech

[mmarks]

Jo som du säger så kan det ju bli konstigt om vi kör på något, dock så är det en tävling som kommer gå på slät mark (antingen i en korridor eller om vädret tillåter utomhus) så vi hoppas att det inte kommer vara ett problem.

Jag hade faktiskt inte tänkt på att jag kan låta timern göra flera saker samtidigt, rent spontant känns det som att det skulle gå att fungera utan större problem i vårt fall så jag ska titta på det och direkt kommunikation mellan processorerna.