Het OpenTX draadje (nieuws, handige weetjes, hardware, diy)
- Topicstarter Tadango
- Startdatum
Ik vind het nog wel meevallen. Curves in de output is de juiste manier. Geef 1 servo geen curve (als die mooi lineair loopt tenminste naar tevredenheid), de andere stel je bij zodat ie de 1e volgt.
Je moet wel zorgen dat ze allebei de zelfde uitslag halen.
Het fenomeen rond 10s dat de rechter beweegt en de linker niet, suggereert dat er fysiek in de aansturing iets verschillend zit: de linker servo zit tegen zijn einde aan (fysiek, qua stuurstang of omdat het roer niet verder wil of de servo hoorn ongunstig ver gedraaid is). De rechter niet, dus die zie je nog bewegen. Je kunt dat fixen door bij het linker roer de aansturing zo te fixen dat de boel wel wil bewegen, of
alternatief door de maximale uitslag van de linker terug te schroeven in outputs. Hij moet bewegen tot 100% stick uitslag en dan precies bij zijn uiteinde zijn. Als hij eerder stopt kun je de max uitslag
wat verlagen in de output.
Als je eenmaal beide servos zo hebt dat ze bij volledige stick uitslag precies van -max tot +max bewegen, en fysiek ook even ver, dan kun je daarna met de curve nog de verschillen "onderweg" bijsturen.
Je kunt ook de eindpunten bijsturen met zo'n curve, maar bljif daar weg: dat kan je beter in het outputs scherm met min en max uitslag regelen.
Staan je servo's (roerhoorntjes) zo dat ze in neutraalstand van de servo allebei precies de zelfde hoek maken t.o.v. het vliegtuig?
Je moet wel zorgen dat ze allebei de zelfde uitslag halen.
Het fenomeen rond 10s dat de rechter beweegt en de linker niet, suggereert dat er fysiek in de aansturing iets verschillend zit: de linker servo zit tegen zijn einde aan (fysiek, qua stuurstang of omdat het roer niet verder wil of de servo hoorn ongunstig ver gedraaid is). De rechter niet, dus die zie je nog bewegen. Je kunt dat fixen door bij het linker roer de aansturing zo te fixen dat de boel wel wil bewegen, of
alternatief door de maximale uitslag van de linker terug te schroeven in outputs. Hij moet bewegen tot 100% stick uitslag en dan precies bij zijn uiteinde zijn. Als hij eerder stopt kun je de max uitslag
wat verlagen in de output.
Als je eenmaal beide servos zo hebt dat ze bij volledige stick uitslag precies van -max tot +max bewegen, en fysiek ook even ver, dan kun je daarna met de curve nog de verschillen "onderweg" bijsturen.
Je kunt ook de eindpunten bijsturen met zo'n curve, maar bljif daar weg: dat kan je beter in het outputs scherm met min en max uitslag regelen.
Staan je servo's (roerhoorntjes) zo dat ze in neutraalstand van de servo allebei precies de zelfde hoek maken t.o.v. het vliegtuig?
Omdat we er plotseling vrij veel leerlingen bij hebben, maar we ook nog met Corona zitten, heb ik een paar adaptertjes gemaakt waarmee we wireless les kunnen geven.
Het maakt gebruik van de mogelijkheid van mijn Taranis X9D om de trainerport op SBUS Master te zetten en de leerling gebruikt in dit geval zijn Futaba zender om naar bovenstaande ontvanger te zenden.
Vervolgens gaat dit geheel dan in de modulebay van mijn Taranis, die naar het vliegtuig uitzendt. So far so good.
Nu wilde ik deze oplossing ook in de Horus X10S van een andere instructeur stoppen en tot mijn verbazing kent die niet de optie SBUS Master als training signaal input. Die kan alleen een CPPM trainersignaal via de jack plug ontvangen.
Hoe kan ik er achter komen welke OpenTX zenders wel of geen SBUS trainer signaal als input ondersteunen?
Heb al een poos zitten zoeken op RCGroups en op OpenTX forum, maar daar geen uitsluitsel kunnen vinden.
Het maakt gebruik van de mogelijkheid van mijn Taranis X9D om de trainerport op SBUS Master te zetten en de leerling gebruikt in dit geval zijn Futaba zender om naar bovenstaande ontvanger te zenden.
Vervolgens gaat dit geheel dan in de modulebay van mijn Taranis, die naar het vliegtuig uitzendt. So far so good.
Nu wilde ik deze oplossing ook in de Horus X10S van een andere instructeur stoppen en tot mijn verbazing kent die niet de optie SBUS Master als training signaal input. Die kan alleen een CPPM trainersignaal via de jack plug ontvangen.
Hoe kan ik er achter komen welke OpenTX zenders wel of geen SBUS trainer signaal als input ondersteunen?
Heb al een poos zitten zoeken op RCGroups en op OpenTX forum, maar daar geen uitsluitsel kunnen vinden.
Ja, dan moet er een externe Multiprotocol module in. Daar begon ik mee, omdat ik dacht dat dat in een taranis ook zou werken, maar kwam er later pas achter dat bij de FRSky zenders de interne en externe zendmodule niet gelijktijdig kunnen werken. Er is wel iemand over aan het denken, maar dat betekent wat hardwaremods in de zender doen. Voor mijn eigen zender vind ik dat geen probleem, maar niet voor een zender van iemand anders.
https://www.rcgroups.com/forums/showpost.php?p=45123017&postcount=19153
Toen heb ik de multiprotocolmodule er weer uitgehaald en ben met SBUS-in begonnen, waarbij ik nu dus ook een hobbel tegenkom.
https://www.rcgroups.com/forums/showpost.php?p=45123017&postcount=19153
Toen heb ik de multiprotocolmodule er weer uitgehaald en ben met SBUS-in begonnen, waarbij ik nu dus ook een hobbel tegenkom.
Wat je daar ziet rond 10 sec kan ik niet beter vergelijken alsof de rechterservo sneller reageert op het stickinput.
Ik heb nu de max 'down' uitslag teruggeschroefd. En ze starten nu alle 2 gelijktijdig ongeveer.
Hoewel in het gevoel heb dat de rechter toch niet iets sneller reageert.
Verder heb ik een 17punts curve toegevoegd.
Als ik beidde 'up' doe, lopen ze mooi gelijk. Maar als ik down geef, de laatste 20% ongeveer zit er weer verschil tussen de servo's.
Zelf met de 17punts curve krijg ik het niet volledig weggewerkt.
Misschien moet ik toch beginnen denken dat het probleem aan die servo ligt..
Ga eerst eens kijken of ik het verschil merk tijdens het vliegen, vind het ook bizar dat het enkel tijdens 'down' is en de laatste 20%.
Anders probeer is eens een andere servo
Omdat we nu toch verder willen met draadloos lessen met de Horus X10S, vandaag besloten om iets te verzinnen wat ik kon maken met de onderdelen die ik in huis heb en wat niet afhankelijk is van de zenderconfiguratie.
Op basis van een Arduino Promini heb ik nu een receiver switch gemaakt waar je twee CPPM ontvangertjes aan hangt en dan kan de leraar bepalen naar wie kanaal 1-4 gaat. Kanaal 5-8 is altijd aan de leeraarzender gekoppeld voor als je bijvoorbeeld het gas zelf wil blijven doen, dan kloon je het gaskanaal op je zender naar kanaal 5 en prik je de regelaar in kanaal 5 van het receiver switch printje.
kanaal 8 van de leeraar bepaalt wie de besturing van kanaal 1-4 heeft. Kanaal 7 is nog even gereserveerd, ik wil er nog een gyro functie bij doen.
Ik kan bij interesse wel een beschrijving maken, want het is supersimpel te maken.
Hieronder de sketch
Op basis van een Arduino Promini heb ik nu een receiver switch gemaakt waar je twee CPPM ontvangertjes aan hangt en dan kan de leraar bepalen naar wie kanaal 1-4 gaat. Kanaal 5-8 is altijd aan de leeraarzender gekoppeld voor als je bijvoorbeeld het gas zelf wil blijven doen, dan kloon je het gaskanaal op je zender naar kanaal 5 en prik je de regelaar in kanaal 5 van het receiver switch printje.
kanaal 8 van de leeraar bepaalt wie de besturing van kanaal 1-4 heeft. Kanaal 7 is nog even gereserveerd, ik wil er nog een gyro functie bij doen.
Ik kan bij interesse wel een beschrijving maken, want het is supersimpel te maken.
Hieronder de sketch
Laatst bewerkt:
AHoogendijk
PH-SAM
Ik heb de sketch toegevoegd en daar ook uitleg bij gezet over de aansluitingen. Kijk maar even of dat duidelijk genoeg is. De extra elco die ik tussen VCC en GND heb geplaatst is uit voorzorg, omdat ik in het verleden bij een eigenbouw gyro soms een brown-out of vastloper kreeg van de Arduino. Met condensatortje erbij was dat probleem toen verleden tijd.
@Tadango Bij het gebruiken van je S-port library is het me opgevallen dat als ik daar een willekeurige sensor mee maak en vervolgens vanaf mijn zender (Taranis X9D) het LUA script "FrSky SxR" gebruik om een S6R of S8R gyro ontvanger te configureren, dat dan het LUA script in 90% van de gevallen vastloopt. Een vliegmaat heeft hetzelfde met zijn Horus X10S en moet dan even de S-port kabel uit zijn ontvanger trekken als hij het script wil gebruiken. Ik probeer er achter te komen hoe dat nou komt, want als ik het goed begrijp heb jij jouw library juist laten samenwerken met LUA scripts voor een aantal geavanceerde sensoren die je hebt bedacht.
Tadango
Forum veteraan
Het probleem met Frsky SPort is dat het enorm slecht geïmplementeerd is hardware matig. De enige manier om betrouwbaar data naar een sensor te sturen vanaf een zender is om allemaal naar hetzelfde adres te schrijven. Ik gebruik dus het enige werkende adres wat de S6R ook gebruikt. Nu zou mijn library hier geen probleem mee moeten hebben normaal omdat hij alles negeert wat niet voor hem bedoeld is. Ook zouden alle sensoren dezelfde data tegelijk moeten kunnen ontvangen en zolang je geen data terug stuurt op het verkeerde moment moet een sensor met mijn library de boel niet beïnvloeden. Dit is theorie
Ik zal eens debuggen binnenkort of er ergens een fout in de code zit. Ik heb een S6R liggen om mee te testen.Maar, is de main loop van je sensor snel genoeg? Mijn library is erg afhankelijk van een enorm snelle main loop. Wanneer er een request voor data binnenkomt (in de serial buffer) en deze wordt pas laat in de code verwerkt omdat de main loop bezig was met iets stuurt de sensor de data wellicht te laat terug en dan tegelijk met data van een andere sensor. In de serial buffer weet je niet hoe laat de data ontvangen is en of je wellicht te laat bent. Ik heb gekeken naar timers ipv de aanroep vanuit de main loop maar dat is niet makkelijk en netjes te implementeren helaas.
Bedoel je met "slecht geimplementeerd", dat er geen hardware UART (met buffer) wordt gebruikt, maar dat je het met softwareserial moet oplossen of bedoel je wat anders?
Ik had ervaren van de vorige projectjes, waarbij ik de S-port library van RC-Groups lid "Pawelsky" gebruikte dat ik ervoor moet zorgen dat de main loop heel vaak naar de polling vanuit de ontvanger luistert en hierop snel moet reageren (microseconds matter). Ik heb ook nog weer even getest met zijn library en die verstoort niet het LUA script.
Ik ben begonnen met testen met behulp van je voorbeeld sketch "SimpleSensor.ino". Een snellere main loop kon ik mij niet voorstellen.
Ik heb getest met een Arduino Promini op 8MHz, resultaat, script loopt vast
Ik heb ook getest met een LGT8F328 op 32MHz, 16Mhz, 8MHz en 4MHz. Iik had de indruk dat het bij 4MHz maar in 70% van de gevallen mis ging, maar dan krijg ik wel af en toe een melding "sensor lost". Dat was trouwens met een iets zwaardere main loop, omdat ik wilde kijken of een tragere respons op de polling vanuit de ontvanger verschil zou maken. Ik kreeg dus een beetje de indruk dat als de S-port respons op het script van de eigenbouw sensor sneller is dan de S-port respons vanuit de S6R ontvanger dat het script dan crasht.
Wellicht dus inderdaad kijken of jouw library wel alles negeert wat niet voor hem bedoeld is en niet toch per ongeluk op andere polls reageert? Ik heb zelf even in je source zitten kijken of ik kon zien hoe het allemaal werkte, maar mis daarvoor nog wel wat C++ kennis. Jij goochelt ermee.
void SPortHub::SendData(sportData data, int prim) {
if(_swStream) {
_swStream->stopListening();
pinMode(_softwarePin, OUTPUT);
delay(1);
Ik heb wel deze delay(1); eens veranderd in een microseconde en hem weggecomment, maar dat maakte geen verschil.
Als ik nog dingen moet testen, doe ik dat graag.
Ik had ervaren van de vorige projectjes, waarbij ik de S-port library van RC-Groups lid "Pawelsky" gebruikte dat ik ervoor moet zorgen dat de main loop heel vaak naar de polling vanuit de ontvanger luistert en hierop snel moet reageren (microseconds matter). Ik heb ook nog weer even getest met zijn library en die verstoort niet het LUA script.
Ik ben begonnen met testen met behulp van je voorbeeld sketch "SimpleSensor.ino". Een snellere main loop kon ik mij niet voorstellen.
Ik heb getest met een Arduino Promini op 8MHz, resultaat, script loopt vast
Ik heb ook getest met een LGT8F328 op 32MHz, 16Mhz, 8MHz en 4MHz. Iik had de indruk dat het bij 4MHz maar in 70% van de gevallen mis ging, maar dan krijg ik wel af en toe een melding "sensor lost". Dat was trouwens met een iets zwaardere main loop, omdat ik wilde kijken of een tragere respons op de polling vanuit de ontvanger verschil zou maken. Ik kreeg dus een beetje de indruk dat als de S-port respons op het script van de eigenbouw sensor sneller is dan de S-port respons vanuit de S6R ontvanger dat het script dan crasht.
Wellicht dus inderdaad kijken of jouw library wel alles negeert wat niet voor hem bedoeld is en niet toch per ongeluk op andere polls reageert? Ik heb zelf even in je source zitten kijken of ik kon zien hoe het allemaal werkte, maar mis daarvoor nog wel wat C++ kennis. Jij goochelt ermee.
void SPortHub::SendData(sportData data, int prim) {
if(_swStream) {
_swStream->stopListening();
pinMode(_softwarePin, OUTPUT);
delay(1);
Ik heb wel deze delay(1); eens veranderd in een microseconde en hem weggecomment, maar dat maakte geen verschil.
Als ik nog dingen moet testen, doe ik dat graag.
Hello All, Hi Tadango,
I have Radiomaster TX16s. I download yours nice project Lview in my radio and not working. I have 2.3.11 software. When I run Lview.lua I have No recent log files...
Can you help me?
cheers
Robert
I have Radiomaster TX16s. I download yours nice project Lview in my radio and not working. I have 2.3.11 software. When I run Lview.lua I have No recent log files...
Can you help me?
cheers
Robert
Tadango
Forum veteraan
Did you enable logging for the selected model?
Yes,
I have this file in logs, It is name-date.csv. Your program not see (search) this file.
I have this file in logs, It is name-date.csv. Your program not see (search) this file.
Yes but note see this file.