De Hexa-Bouncer is een geavanceerde ball-bouncing machine en de directe opvolger van de Octo-Bouncer. Het apparaat is een roterende hexapod die wordt aangedreven door zes Nema 23 stappenmotoren en aangestuurd door een Teensy 4.0 microcontroller.
De werking is als volgt:
- Tracking: Twee camera's registreren de 3D-positie van de bal met een snelheid van 120 frames per seconde.
- Besturing: Een Unity-applicatie verwerkt deze data en gebruikt PID-controllers om de exacte positie en kanteling van de peddel te bepalen.
- Pulsgeneratie: Om complexe bewegingen (zoals cirkels) mogelijk te maken, is gekozen voor lineaire interpolatie tussen datapunten. Dit voorkomt dat de microcontroller overbelast raakt door zware IK-berekeningen.
Hoewel de fysieke machine enige mechanische beperkingen vertoont, zoals speling in de tandwielkasten en lichte instabiliteit bij grote uitslagen, slaagt het ontwerp erin om complexe virtuele trajecten succesvol om te zetten naar fysieke bewegingen.
De Hexa-Bouncer
Componenten
De Hexa-Bouncer heeft de volgende onderdelen nodig om te functioneren:
- 1x Teensy 4.0 microcontroller (met deze code)
- 6x StepperOnline CL57T stepper motor drivers
- 6x Nema 23 stappenmotoren met 10:1 planetaire tandwielkast ([link])
- 1x 36V 14A voeding
- 2x e-con Systems See3CAM_24CUG camera's
- 1x Windows-computer met GPU
- Alle onderdelen gedefinieerd in deze drie Fusion360-projecten
- Zes armen, één basis en één driehoekige end-effector
- Deze aangepaste Windows-applicatie (gemaakt met Unity)
Mechanisch ontwerp
De Hexa-Bouncer is in feite een roterende Hexapod, met de kleine nuance dat we universele koppelingen gebruiken in plaats van kogelgewrichten op alle zes de armen.
- A, B: universele koppelingen
- C: polsgewricht
Aanvankelijk dacht ik dat het mechanische ontwerp zou werken door simpelweg twee universele koppelingen (A en B) te gebruiken. Echter, na het uitvoeren van enkele IK-simulatietests in Unity merkte ik dat het gewricht op positie B moet kunnen roteren rond de as van de eindschakel. Daarom moest ik polsgewricht C toevoegen.
Het gebruik van zowel universele koppelingen als polsgewrichten maakt het geheel wat onhandig. Idealiter zouden we een universele koppeling bij A en een kogelgewricht bij B gebruiken, waardoor het nu redundante polsgewricht C overbodig zou worden. Ik kon echter geen degelijke en betaalbare kogelgewrichten vinden die in mijn ontwerp pasten, dus besloot ik vast te houden aan wat ik ken en wat werkt (het ontwerpen van eigen gewrichten met kogellagers).
Hoe werkt het precies?
De twee camera's sturen beeldata naar de pc via de USB-bus met een snelheid van 120 frames per seconde. We extraheren de 3D-positie van de bal uit de twee camerabeelden (de camera's zijn in een hoek van 120 graden ten opzichte van elkaar geplaatst). Hierdoor ontvangen we in onze Unity-applicatie elke 8,33 ms een nieuwe 3D-positie van de bal.
We gebruiken deze data om te voorspellen wanneer de bal weer naar beneden komt en de peddel raakt (om te bepalen wanneer de volgende opwaartse beweging moet beginnen) en hoeveel de peddel gekanteld moet worden tijdens het omhoog bewegen (via een PID-controller voor de X- en Y-as).
De bovenstaande afbeelding is een screenshot van de Unity-applicatie ([Github-link]) waarop de virtuele machine (digital twin) en beide camerabeelden te zien zijn.
Motorpulsgeneratie
Een doel bij de Hexa-Bouncer was om hem niet alleen omhoog en omlaag te laten bewegen en te laten kantelen, maar hem ook complexere bewegingen te laten maken, zoals de beweging waarbij de machine in een cirkel beweegt terwijl hij op en neer gaat.
Het lastige deel van het mogelijk maken van dergelijke bewegingen was het ontwerpen van de pulsgeneratie, zodat complexe motorprofielen kunnen worden omgezet in een passende pulsstroom. Voor het uitvoeren van de bovengenoemde beweging op de fysieke machine moet de rode motor bijvoorbeeld een motorprofiel volgen zoals hieronder getoond.
Het genereren van stappenmotorpulsen voor een zuivere sinusgolf is eenvoudig, maar hoe genereren we pulsen voor een complexe curve? Enkele opties die in overweging kwamen:
- Optie A: De microcontroller voert dezelfde IK-berekeningen uit als de Unity-app tijdens de pulsgeneratie.
- Optie B: De curve wordt gefit aan een functie en de benodigde parameters om deze functie te beschrijven worden naar de microcontroller gestuurd. De microcontroller voert vervolgens de gefitte functie uit tijdens het genereren van de pulsen.
- Optie C: Er wordt een set punten op de curve verzonden, waarna de microcontroller lineair interpoleert tussen de punten op de curve.
Ik heb gekozen voor optie C. Optie A is problematisch omdat de Teensy 4.0 simpelweg niet snel genoeg is om de IK voor alle zes de armen uit te voeren bij elk pulsgeneratie-interval. Optie B had kunnen werken, maar ook hier maakte ik me zorgen over de prestaties. Optie C is perfect voor dit geval, omdat we de punten dicht genoeg bij elkaar kunnen kiezen, waardoor het resultaat vloeiend genoeg is om geen problemen te veroorzaken. Het enige nadeel is dat we veel data naar de microcontroller moeten sturen (alle interpolatiepunten), maar de datasnelheid via de seriële bus is in dit project geen bottleneck.
Hier is het resulterende motorprofiel na de implementatie van methode C met grove tussenruimtes tussen de datapunten. Omdat er veel ruimte tussen de interpolatiepunten zit, is te zien dat de hele curve is opgebouwd uit meerdere rechte lijnsegmenten.
Hier ziet het motorprofiel eruit nadat de afstand tussen de datapunten vijf keer zo kort is gemaakt. Nu ziet het er bijna hetzelfde uit als het oorspronkelijke motorprofiel dat we probeerden te reproduceren. Dit is meer dan voldoende voor ons project, mede omdat onze mechanische structuur niet perfect rigide is en er sprake is van speling (backlash) in de tandwielkasten van de stappenmotoren. Onze machine kan dus prima omgaan met een kleine afwijking van de ideale motorbewegingen.
Hieronder staat de beweging van de fysieke machine na de implementatie van methode C. De beweging is niet zo vloeiend als bij de virtuele machine, maar ik vermoed dat dit meer te maken heeft met het feit dat dit specifieke mechanische ontwerp onstabieler wordt naarmate de end-effector verder van het centrum af komt, dan met de manier waarop de pulsen worden gegenereerd.
De Hexa-Bouncer
Componenten
De Hexa-Bouncer heeft de volgende onderdelen nodig om te functioneren:
- 1x Teensy 4.0 microcontroller (met deze code)
- 6x StepperOnline CL57T stepper motor drivers
- 6x Nema 23 stappenmotoren met 10:1 planetaire tandwielkast ([link])
- 1x 36V 14A voeding
- 2x e-con Systems See3CAM_24CUG camera's
- 1x Windows-computer met GPU
- Alle onderdelen gedefinieerd in deze drie Fusion360-projecten
- Zes armen, één basis en één driehoekige end-effector
- Deze aangepaste Windows-applicatie (gemaakt met Unity)
Mechanisch ontwerp
De Hexa-Bouncer is in feite een roterende Hexapod, met de kleine nuance dat we universele koppelingen gebruiken in plaats van kogelgewrichten op alle zes de armen.
- A, B: universele koppelingen
- C: polsgewricht
Aanvankelijk dacht ik dat het mechanische ontwerp zou werken door simpelweg twee universele koppelingen (A en B) te gebruiken. Echter, na het uitvoeren van enkele IK-simulatietests in Unity merkte ik dat het gewricht op positie B moet kunnen roteren rond de as van de eindschakel. Daarom moest ik polsgewricht C toevoegen.
Het gebruik van zowel universele koppelingen als polsgewrichten maakt het geheel wat onhandig. Idealiter zouden we een universele koppeling bij A en een kogelgewricht bij B gebruiken, waardoor het nu redundante polsgewricht C overbodig zou worden. Ik kon echter geen degelijke en betaalbare kogelgewrichten vinden die in mijn ontwerp pasten, dus besloot ik vast te houden aan wat ik ken en wat werkt (het ontwerpen van eigen gewrichten met kogellagers).
Hoe werkt het precies?
De twee camera's sturen beeldata naar de pc via de USB-bus met een snelheid van 120 frames per seconde. We extraheren de 3D-positie van de bal uit de twee camerabeelden (de camera's zijn in een hoek van 120 graden ten opzichte van elkaar geplaatst). Hierdoor ontvangen we in onze Unity-applicatie elke 8,33 ms een nieuwe 3D-positie van de bal.
We gebruiken deze data om te voorspellen wanneer de bal weer naar beneden komt en de peddel raakt (om te bepalen wanneer de volgende opwaartse beweging moet beginnen) en hoeveel de peddel gekanteld moet worden tijdens het omhoog bewegen (via een PID-controller voor de X- en Y-as).
De bovenstaande afbeelding is een screenshot van de Unity-applicatie ([Github-link]) waarop de virtuele machine (digital twin) en beide camerabeelden te zien zijn.
Motorpulsgeneratie
Een doel bij de Hexa-Bouncer was om hem niet alleen omhoog en omlaag te laten bewegen en te laten kantelen, maar hem ook complexere bewegingen te laten maken, zoals de beweging waarbij de machine in een cirkel beweegt terwijl hij op en neer gaat.
Het lastige deel van het mogelijk maken van dergelijke bewegingen was het ontwerpen van de pulsgeneratie, zodat complexe motorprofielen kunnen worden omgezet in een passende pulsstroom. Voor het uitvoeren van de bovengenoemde beweging op de fysieke machine moet de rode motor bijvoorbeeld een motorprofiel volgen zoals hieronder getoond.
Het genereren van stappenmotorpulsen voor een zuivere sinusgolf is eenvoudig, maar hoe genereren we pulsen voor een complexe curve? Enkele opties die in overweging kwamen:
- Optie A: De microcontroller voert dezelfde IK-berekeningen uit als de Unity-app tijdens de pulsgeneratie.
- Optie B: De curve wordt gefit aan een functie en de benodigde parameters om deze functie te beschrijven worden naar de microcontroller gestuurd. De microcontroller voert vervolgens de gefitte functie uit tijdens het genereren van de pulsen.
- Optie C: Er wordt een set punten op de curve verzonden, waarna de microcontroller lineair interpoleert tussen de punten op de curve.
Ik heb gekozen voor optie C. Optie A is problematisch omdat de Teensy 4.0 simpelweg niet snel genoeg is om de IK voor alle zes de armen uit te voeren bij elk pulsgeneratie-interval. Optie B had kunnen werken, maar ook hier maakte ik me zorgen over de prestaties. Optie C is perfect voor dit geval, omdat we de punten dicht genoeg bij elkaar kunnen kiezen, waardoor het resultaat vloeiend genoeg is om geen problemen te veroorzaken. Het enige nadeel is dat we veel data naar de microcontroller moeten sturen (alle interpolatiepunten), maar de datasnelheid via de seriële bus is in dit project geen bottleneck.
Hier is het resulterende motorprofiel na de implementatie van methode C met grove tussenruimtes tussen de datapunten. Omdat er veel ruimte tussen de interpolatiepunten zit, is te zien dat de hele curve is opgebouwd uit meerdere rechte lijnsegmenten.
Hier ziet het motorprofiel eruit nadat de afstand tussen de datapunten vijf keer zo kort is gemaakt. Nu ziet het er bijna hetzelfde uit als het oorspronkelijke motorprofiel dat we probeerden te reproduceren. Dit is meer dan voldoende voor ons project, mede omdat onze mechanische structuur niet perfect rigide is en er sprake is van speling (backlash) in de tandwielkasten van de stappenmotoren. Onze machine kan dus prima omgaan met een kleine afwijking van de ideale motorbewegingen.
Hieronder staat de beweging van de fysieke machine na de implementatie van methode C. De beweging is niet zo vloeiend als bij de virtuele machine, maar ik vermoed dat dit meer te maken heeft met het feit dat dit specifieke mechanische ontwerp onstabieler wordt naarmate de end-effector verder van het centrum af komt, dan met de manier waarop de pulsen worden gegenereerd.
Groetjes,