servo controller

ssc32 is een leuke controller om mee te beginnen.

Ik heb echter zelf een 20 servo controller gebouwd, en neem van mij aan, de ssc32 scheelt je héél véél tijd.

Een pic kan het vast wel, heb het zelf met een avr gedaan.

Er is zo ergens een 8-Servo controler te krijgen.
(daar is een jaar of wat geleden een topic over geweest)
En je hebt het wel nodig.
Want als je een servo even zijn pulstreintje niet geeft, is hij meteen zijn kracht kwijt en zakt hij in, voor zover er een kracht op staat.

Op 7 september 2008 13:43:11 schreef LED-Maniak:
ssc32 is een leuke controller om mee te beginnen.

Ik heb echter zelf een 20 servo controller gebouwd, en neem van mij aan, de ssc32 scheelt je héél véél tijd.

Een pic kan het vast wel, heb het zelf met een avr gedaan.

en die ssc32, hoe word deze dan geprogrameerd?
en kwa tijd maakt he eigenlijk niet echt uit, want het is zuiver hobby.
zo'n 20 servo controller zou wel ideaal zijn, maar ik kan jammergenoeg geen avr programmeren.

@fantomaz, thnx voor de tip.
ik heb deze controllers ook al gezien, maar dan zou ik 3 van deze controllers moeten kopen, en ik denk dat die ssc32 voor +/-40€ dan wel goedkoper word. plus dat ik waarschijnlijk een hoop plaats bespaar met de ssc32

greetz

Hey Wushu ik ben ook bezig om mijn eigen servokaart te maken. Geef me ff je msn adres.

Zoals te zien is gebruikt de ssc-32 ook een AVR chip. Dit kan ook met een PIC. Alleen gaat het echt veel tijd kosten. Maar dan heb je uiteindelijk ook wat.

Op 7 september 2008 15:07:20 schreef wushu1989:
[...]
en die ssc32, hoe word deze dan geprogrameerd?
en kwa tijd maakt he eigenlijk niet echt uit, want het is zuiver hobby.
zo'n 20 servo controller zou wel ideaal zijn, maar ik kan jammergenoeg geen avr programmeren.

@fantomaz, thnx voor de tip.
ik heb deze controllers ook al gezien, maar dan zou ik 3 van deze controllers moeten kopen, en ik denk dat die ssc32 voor +/-40€ dan wel goedkoper word. plus dat ik waarschijnlijk een hoop plaats bespaar met de ssc32

greetz

Die hoef je niet te programmeren. Gewoon direct de commando's sturen wat welke servo moet doen

Ziet er mooi uit Zeta!

Op zich is het natuurlijk niet zo moeilijk om voor een groot aantal kanalen de pulsen softwarematig te genereren.

De maximale pulslengte is 2ms, en de minimale 1ms, dus je hebt ook maar 1ms speling. Als je de pulsen 100 keer per seconde herhaalt (dat is aan de hoge kant), heb je dus een interval van 10ms. Je kunt elke milliseconde nauwkeurig een puls genereren, zonder dat je concurrentie problemen krijgt, per timer. Je kunt terug naar 50 pulsen per seconde, en dan zijn 20 servo's al helemaal geen probleem meer. Je kunt ook meerdere timers gebruiken, maar dan loop je het risico dat je in de interrupt routine van de ene zit, terwijl de andere ook een interrupt genereert.

Je doet dan dus het volgende: je zet uitgang 1 aan, en stelt de compare value van de timer in zodat deze exact 1ms later afloopt. Tevens stel je de timer zo in dat deze bij een compare match automatisch reset. In de interrupt routine zet je timer 2 aan, en stel je de compare value in op de gewenste waarde voor uitgang 1. Zodra deze afloopt, ze je de uitgang uit, en stel je de compare value in op het restant voor 1ms. Zodra deze afloopt, begin je opnieuw, maar nu met de compare value voor kanaal 2, en je zet uitgang 3 hoog.

Op deze manier heb je exact elke milliseconde een interrupt, en daar tussenin nog een, voor de juiste timing van een kanaal. Per kanaal heb je dus maar 1ms nodig, dus als 20ms tussen de pulsen acceptabel is, kun je 20 kanalen aansturen.

De communicatie met een andere controller zou ik via SPI doen, omdat je daarbij weinig overhead hebt. Deze kun je in een idle-loop afhandelen.

Op 7 september 2008 15:55:26 schreef LED-Maniak:
[...]
Die hoef je niet te programmeren. Gewoon direct de commando's sturen wat welke servo moet doen

deze kaart kan je niet gebruiken als stand alone system?
deze moet altijd aan de pc aangekoppeld zijn?

het is mijn bedoeling dat ik een kaart heb met minstens 4bit digitale ingang, en door deze code te veranderen (daar zorgt een andere µC voor) een andere beweging uit te voeren.

@ SprkyGSX dat gaat even te snel voor mij....
die interval waar je over spreekt kom ik niet zo goed uit, en die concurrentieproblemen begrijp ik ook al niet zo veel van. mss moet ik me eerst wat verder verdiepen in PICs.
ik heb vorig jaar op school iets over pics gezien, maar dat was allemaal vrij vaag en niet zo concreet.
niemand is er eigenlijk in geslaagd om zo iets werkende te krijgen, maar ik vermoed dat het komt door de tijd die we er voor kregen.
daarom dat ik nu een curcus van deze site over pics aan het leren ben.
mss lukt het dan al wat beter

greetz

Klopt

Maar jij wil dus compleet standalone? Ik heb pas voor mijn eigen hexapod een pcb ontworpen die gebruik maakt van dataflash geheugen als sequence opslag, is draadloos en heb er één teveel besteld. Als je er echt niet uit komt, mag je deze pcb(met smd dus kan het voor je solderen) van mij overkopen...

[Bericht gewijzigd door LED-Maniak op zondag 7 september 2008 21:26:46 (63%)]

thnx, maar dit is hobby voor mij en het is de bedoeling om er uit te leren en zelf ervaringen op te doen.
daarom dat ik liever zelf alles maak en leer het te programmeren.
ook zie ik dat jouw ontwerp draadloos is, en dus ook geen stand alone.
voor mij is een robot pas een robot als je hem zelf niet hoeft te besturen, hoe miniem de mogelijkheden dan ook mogen zijn.

toch bedankt voor het aanbod

Draadloos is om hem commando's te geven voor het programmeren van de sequences of andere oefeningen.

Voor de rest heeft hij namelijk 8 sensoren om 100% standalone te werken

Maar succes! Zo te horen gaat het een goed leerproject worden

Het concurrentie probleem krijg je als je alle uitgangen tegelijk hoog zou maken, en dan een voor een laag, afhankelijk van de gewenste pulslengte. Je stelt de timer dan in voor de kortste tijd, en zet in de interrupt routine de uitgang laag, rekent uit hoe lang het nog duurt voordat de volgende laag moet worden, oh, shit, die had intussen al laag moeten zijn. Te laat, dus.

Je krijgt op die manier dus problemen als er 2 tijden dichter bij elkaar liggen, dan de tijd die je nodig hebt om 1 gebeurtenis helemaal af te handelen.

Mijn idee is dan, dat je niet meer dan 1 signaal tegelijk probeert te genereren, waardoor je alle aandacht aan 1 signaal kunt besteden. De eerste 2ms gebruik je voor het eerste signaal, de volgende 2ms voor de volgende, net zolang tot je ze allemaal gedaan hebt, en dan begin je weer opnieuw.

Dit idee kun je optimaliseren door te observeren dat de eerste 1ms van een signaal altijd gelijk is; de variatie zin in de volgende milliseconde. Je kunt de uitgang dus al aanzetten, terwijl je nog met het vorige signaal bezig bent.

Een kleine illustratie. ___ is een laag signaal, --- is een hoog signaal, en xxx is het variabele stuk (hoog of laag, afhankelijk van de gewenste tijd).
Elke 5 tekens staat voor 1ms.

Het signaal voor een servo is dus:
_____-----xxxxx_____
Dus: 1ms hoog, en dan nog 0-1ms hoog (dus 1-2ms in totaal hoog). Dit een aantal keren per seconde herhalen.

Voor 3 servo's:
1 -----xxxxx____________________
2 __________-----xxxxx__________
3 ____________________-----xxxxx

Hier genereer je dus eerst signaal 1, 2ms later signaal 2, enz.

De optimalisatie:
1 -----xxxxx__________
2 _____-----xxxxx_____
3 __________-----xxxxx

De vaste 1ms hoog voor elke kanaal, begint op het moment dat je begint met het variabele deel van het vorige kanaal.

ik heb een weekje op reis geweest en in mijn vrije tijd wat zitten nadenken over de controller en ik ben op het volgende probleem gestoot;

om een servo aan te sturen moet je een puls genereren van min 1ms en deze zeker na 10ms herhalen.
anders verliest deze zijn kracht.

stel dat ik dit nu via een pic zou doen dan kan ik toch maximaal 10 servo's aansturen?

als je 10 kanalen hebt en de ene na de andere een puls geeft (je geeft dus op 10 verschillende kanalen een puls van 1ms) dan moet je toch na het 10de kanaal al een puls gaan geven op het eerste kanaal om de kracht te kunnen bewaren?

hoe los je het dan op voor meerdere kanalen?

en hierbij houd ik nog geen rekening met de tijd om mijn input te controleren.

ik heb even geschetst wat ik bedoel.

servo 1: ---___________________________
servo 2: ___---________________________
servo 3: ______---_____________________
servo 4: _________---__________________
servo 5: ____________---_______________
servo 6: _______________---____________
servo 7: __________________---_________
servo 8: _____________________---______
servo 9: ________________________---___
servo10: ___________________________---

en dan heb ik nog geen rekening gehouden dat ik voor de andere positie pulsen moet genereren van 2ms.

greetz

Dat was nu precies wat ik schetste; de puls is altijd 1ms + [0..1]ms. Die eerste ms kun je dus gemakkelijk timen, omdat het schakelmoment daarvan nooit in de knoop kan komen met het andere kanaal.

Ik dacht dat je het signaal ook wel elke 20ms mocht herhalen, maar dat kan ik natuurlijk fout hebben.

Bij mijn methode heb je 1ms per kanaal nodig, dus als je een interval van 10ms nodig hebt, kun je inderdaad "maar" 10 servo's met 1 controller doen. De communicatie doe je dan in de idle-loop, dus dat loopt ook niet spaak met de timing. Je kunt 2 controllers gebruiken voor de servo's, en een derde die de beslissingen neemt, en updates stuurt naar de 2 slave controllers.

EDIT: wikipedia en een aantal andere pagina's zegt ook 20ms.

de enige mogelijkheid ligt dus in het werken met 3PICs...

1 voor de beslissingen en 2 voor het effectief aansturen van de servo's.

ik heb nu ook gevonden dat het blijkbaar om de 20ms mag, maar als ik het met 3pics zou uitvoeren dan zouden er geen problemen mogen zijn denk ik.