wireless PiD controler

Heb je al eens aan Xbee gedacht?

https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf

UDP?

Dat klinkt als TCP/IP over WiFi, niet het meest geweldige als je realtime data nodig hebt.

Welk deel wil je draadloos maken? Ik zou de controller bij de elektronica van de motoren houden, anders kun je rekenen op een boel nieuwe ellende omdat je variabele vertragingen krijgt in je control loop. Je zou de setpoints draadloos kunnen doorsturen, en dat hoeft meestal niet real-time, omdat je vooraf weet wat de volgende beweging gaat worden. Je zou dus een soort G-code kunnen versturen en lokaal bufferen, lang voordat die nodig is, en dan heb je dus automatisch wat tolerantie voor vertraging op die verbinding.

@lambiek : ik bekijk het vanavond eens in detail maar zie op het eerste zicht niets over latency ?

@sine : idd, volgens de Elektuur van deze maand was het sneller dan wifi wegens geen fout controle feedback en minder overhead. Ik las het in de bib en heb het artikel dus niet bij.

@ SparkyGSX : even het probleem beschrijven

Het gaat om een kabel robot, die je best kan vergelijken met een kabelbaan met één gondel, waaraan onderaan die gondel een slinger hangt. Onderaan de slinger zit de nuttige last ( een glas bier;-) en een versnelling sensor (bmo055). Deze meet alle versnellingen in 9 assen , en dus ook eventueel schommelen.

Deze moet een servo die de kabelbaan aandrijft zo sturen dat het glas vanuit stilstand in plaats A , naar stilstand in plaats B kan brengen. De servo motor is een JMC iHSV57-30-18-36. zie https://www.circuitsonline.net/forum/view/141868#highlight=servo+jmc

Het aansturen van de servo gebeurt door pulsen , intern in die servo zit ook nog een PID in met parameters die aanpasbaar zijn. Over deze pid gaat het dus niet in deze post.

In een eerste fase zou ik graag de schakeling zo maken dat wanneer de last slingert, de regeling de slingering kan stoppen.

Ik dacht alle PID sturing bij de versnelling sensor te houden, omdat ik dan maar minimale data moet doorsturen naar de motor ? ( aantal stapjes met richting erbij. Dit is bij de schrijfmachine in de filmpjes van de startpost ook zo gedaan.

Jan

ps ik heb vodden met uploadarchief, waardoor ik geen schetsje kan posten, is er een alternatief voor upload archief?

Op 27 december 2019 10:51:30 schreef fablab:

@sine : idd, volgens de Elektuur van deze maand was het sneller dan wifi wegens geen fout controle feedback en minder overhead. Ik las het in de bib en heb het artikel dus niet bij.

Dan begrijp jij niet wat UDP is, en Sine wel.

UDP is een deel van het TCPIP protocol. Het TCPIP protocol zegt iets over wat de bitjes in een pakketje betekenen maar niets over hoe de pakketjes van A naar B moeten. Als jij zegt "wireless" en "UDP" dan impliceert dat dat je in 99% van de gevallen de bitjes met het "Wifi" protocol van A naar B wil gaan krijgen.

Veel protocollen waar TCPIP op draait heeft truken als retries als er een collision optreed: Zowel wired als wifi heeft dat.

Dit is ABSOLUUT niet fijn voor real-time processen als een PID loop.

-----

Maar het is nog helemaal niet duidelijk dat dit iets met jou probleem te maken heeft.

Een PID loop moet je met zo min mogelijk vertraging zo dicht mogelijk bij de meting en de actuator laten runnen. Dus als je het setpoint via WIFI (UDP of anders!) naar de PID controller wil sturen: no problem!

Op 27 december 2019 12:01:03 schreef rew:
UDP is een deel van het TCPIP protocol.

Dan mis je zelf ook nog iets UDP is een protocol dat op de IP laag (in OSI) staat. TCP zit op dezelfde laag. Het zijn beide transport lagen. Het is dus een van beide, UDP is geen deel van TCP.

Staat de servo-aandrijving boven de gondel, of in één van beide "kabelstations" ? De BME055 bevindt zich in de gondel ? Indien beide zich onafhankelijk van mekaar moeten kunnen bewegen zonder signaalkabel ertussen heb je inderdaad een draadloze signaal overdracht. Dan stelt zich direct het probleem van latentie. Indien de "slinger" voldoende lang is, heb je wel een redelijk traag systeem. Ik zou het eerder met BT of 433 MHz verbinding proberen, deze hebben duidelijk minder latentie.

@rew flipflop : Ik heb het artikel uit elektor niet bij, het kwam min of meer hierop neer https://www.youtube.com/watch?v=Vdc8TCESIg8
Het is iets dat naast TCP staat, met voordelen ( kleine pakketten, sturen wanneer ik wil) en nadelen (fire and forget + volgorde garantie).

@rp6conrad : de servo heeft 180 Watt nodig, te veel voor een batterij en moet dus in de kabelstations staan, de bmo055 bevind zich onderaan in een slinger die aan aan de enige gondel vast is gemaakt. Beperkt slingeren is nodig , omdat de last een glas bier is. Als dit glas rechtop staat en versnelt, gaat dit mis. Het zou wel prettig zijn om het systeem zo snel mogelijk te maken, om het dan ook zo spectaculair mogelijk te maken.

@allemaal : ik heb hier nog 2 ESP32's liggen en ga daar eens mee proberen een stabiele UDP verbinding mee te maken, en uit te zoeken hoeveel "3 bytes" berichten ik van de ene naar de andere kan sturen per seconde. De 3 bytes is nodig omdat ik iet langer de delta zou doorsturen maar de totale positie , als er dan een berichtje eronderuit gaat is dit niet het einde van de wereld.

Voor alle duidelijkheid , dit is iets dat bedoelt is als grap, om te bewijzen dat het mogelijk is, niet om in een echt cafe of zo te draaien.

Volgende week donderdag heb ik tijd, voordeel is dat ik de hardware liggen heb. Zigbee en BT zijn plan B. Ik zie dat 433 mHz maar 4 kb aan kan? Dat wordt wel heel weinig? de HC-12 RF-module 433mHz ziet er ook de moeite uit.

jan

upload archief is hersteld, het principe

De meeting gebeurt bij de versnelling sensor bij de last, de servo motor moet aangestuurd worden. De kat en gondel zijn hetzelfde.

jan

Heeft er iemand ervaring met "esp now"?

https://www.youtube.com/watch?v=6NsBN42B80Q

Blijkbaar de methode om zonder router tussen 2 esp32 draadloos te communiceren of voor esp32 =>esp32 => router netwerken?

jan