Onderwerp: Arduino project aan boord

TS hier:
@roozeboos zeilprutser; ik begrijp wat jullie zeggen. Ik begrijp het theoretische verschil tussen controller en processor, ik heb tenslotte een HTS eletrotechniek opleiding achter de rug afgestudeerd in informatica, zoals dat toen nog heette.
In de volksmond word eea door elkaar gebruikt om toch hetzelfde te duiden. Pas als je het gaat bestellen moet je goed opletten
Ik waardeer jullie bijdragen tenzeerste, omdat imo jullie er meer kaas van hebben gegeten dan ikzelf. Daarom is dit een mooi projectje (voor mij). Dus bijdrage aan het project door te blijven posten; bekvechten hebben we andere draadjes voor. Nu elkaar de hand weer schudden en vrolijk verder met wat ons plezier geeft.

En ja WiFi tzt staat ook op de future feature list... dus wie weet; maar eerst de must haves invullen.

Mannen, luister naar Jazz die het perfect weergeeft: ga door met goede inhoudelijke bijdragen, hou beide op met bekvechten! Ik heb alle (nu al 8 ) betreffende berichten verwijderd...

Als jij het maar snapt Yazz, daar gaat het om.
als ik jou was zou ik wel eerst kijken naar de Wrover. Scheelt allicht dubbel werk.
Zeker als je ook wifi wil gaan doen.

Ik heb verschillende printplaatjes ontworpen waar hij op zit, als je dat zoekt maar even PB

@H2O; goed om te weten van die ESP32. WiFi staat op de featurelist.
Als pro werk ik elke dag met MoSCow , dat zit op het ruggemerg na 35 jaar De MEGA heeft aardig wat I/O poorten digitaal in ieder geval die niet door de display worden gebruikt.naar 4 seriële poorten en I2C en SCL

@roozeboos; thks! ik hou het zeker even in het achterhoofd. Nu eerst de skills even ontroesten

Yazz schreef : Het is zelfs in hobby projecten goed om je requirements goed te prioriteren. "Featuritis" kruipt er vooral met dingen die je zelf ontwikkelt makkelijk in

Ik denk dat je met de Mega2560 prima uit de voeten kan voorlopig. Mocht je later meer willen dan is er gelukkig nog een hele wereld te ontdekken. Succes met je project!

Leuk project. Mijn aannames waren duidelijk niet juist. Het een en ander gaat me ook boven mijn pet. Maar zover er op ZF verslag van komt ga ik het zeker volgen. Keep up the good work !

Na wat zwoegen heb ik een eerste MVP (Minimal Valuable Product ) draaien die de 9DoF uitleest voor de heading en waarbij wordt gecorrigeerd voor tilt en pitch. Daarnaast worden in de oude niet MEA0183 compatibele berichten netje omgezet.
Mijn eerste object georiënteerde aanpak leidde tot een gebrek aan geheugen voor de variabelen (90% bezet) terwijl het TFT scherm nog ontbreekt. Dat moest dus anders en een oude wijsheid dat OO en embedded niet goed samengaan, bleek waar al te (z)waar.

Terug naar de tekentafel draait het nu wellliswaar met 2 classes maar gewoon in een loop met een ISR voor de MPU9250. IN het screenshot zijn de op basis van de MPU9250 gegenereerde HDG berichten als ook de omgesmurfde DBK, XOD berichten voor de BATT. Daarnaast zijn van alle $II talker ID berichten de checksum berekend....
Het concept werkt dus.

Blijft de heading goed met sensor onder helling ?

Mooi dat je nu al je eerste resultaat hebt. Aan de andere kant: misschien toch maar sparen voor een ESP32 en dan leren te leven met wat minder I/O pinnen

Programmeren van embedded spul vergt zeker een andere manier van denken en misschien voor sommige dingen een wat meer klassieke (niet-OO) aanpak. Die technieken zal je vanzelf gaan ontwikkelen en beheersen als je verder komt.

@roozeboos; ik zie duidelijk verschil tussen niet en wel gefilterde heading waarden. Alles valt en staat bij goede calibratie waarden van de MPU sensor. Die heb ik nu maar een beetje met de Franse slag gedaan. Hoe goed e de filtering is moet ik nog onderzoeken, maar de eerste resultaten lijken te werken.
Zie de discussie met code hier. Die code heb ik gebruikt. Het was nog lastig om de juiste include files te vinden....

Ik probeer altijd maar de functies klein en compact te houden. Beetje OO stijl.
Het voordeel is dat het eenvoudig te testen is. En overzichtelijk.
Uiteindelijk is het een kwestie van doorzetten, en doorzetten en doorzetten..

Deze sensor goed krijgen is nogal een klus lijkt me.
Als je het werkend hebt kunnen we er misschien wel een productje van maken.

Yazz schreef :
Vooropgesteld dat ik je niet wil bekritiseren. Maar puur uit nieuwsgierigheid. Zie je een nut in het koppelen van rate of turn en magnetische heading ?

Werk je met de Arduino IDE of in een andere omgeving? En welke MPU9250 library gebruik je nu?

Er zijn er flink wat beschikbaar en het heeft voordelen om een library te gebruiken die beschikbaar is vanuit de IDE (zoals de Bolder Flight Systems library die in jouw link gebruikt wordt). Dan hoef je in ieder geval niet meer naar includes te zoeken

@3Noreen; ROT zie ik persoonlijk als weinig toegevoegde waarde. Heading daarentegen , of het ontbrekend daarvan speelt mij nu parten in de TimeZero app. Mijn boordnetwerk meet het niet, maar geeft 0 door. De app denkt dan dat de heading 0 is en plot daarop de heading koers. Dat is vervelend dus heb ik besloten dat te kunnen manipuleren.. Daarnaast ben ik nieuwsgierig naar de nauwkeurigheid van een elektronisch kompas vs een traditioneel kompas.

@H20: Er zijn idd veel include-files voor de MPU9250, allemaal met verschillende implementaties en wel of niet volledig, nodeloos complex of minder complex.. Het probleem daarbij is dat al die libraries MPU9250 heten, dus is het lastig om overzicht te houden welke waar bij hoort.... P.S. Ik gebruik inu id de library van Bolderflight

Ik ben ook eens bezig geweest, een jaar of drie terug ofzo. Ook met een library. Maar kreeg het niet goed aan de praat.
Het probleem van de nauwkeurigheid en wat de library moet oplossen is dat als je de sensor kantelt bij dezelfde heading de gegenereerde heading gelijk moet blijven.
Op je stabiele buro gaat het altijd goed, maar de boot beweegt natuurlijk continue.

@roozeboos; klopt zo'n IMU is zeer gevoelig voor titl en pitch. Maar uiteindelijk met complexe goneometrie kan je compenseren. De jongens(en meisjes?) die veel met drones doen hebben daar belangrijk werk in verricht en daar pluk ik nu de vruchten van... Ik heb een hoop geleerd de afgelopen avonden

@Yazz,

Dat heb je snel gedaan. Het verbaast me wel dat je al tegen geheugenbeperkingen aanloopt. Een 9DOF filter kost wel wat rekenkracht maar niet zo heel veel geheugen. Heb je veel statische strings? Dan kan je overwegen deze in het programmageheugen te zetten, zoek op progmem. Doubles kosten ook veel ruimte.

@Aswin; het tekort doet zich voor in het dynamische geheugen niet in het programma geheugen. Daar is genoeg van op de Arduino(256K). Er worden nu veel strings gebruikt, dus valt nog wel te optimaliseren. Maar nu eerst het geheel compleet werkend maken als ik de essentiële onderdelen binnen heb. Qua software ben ik aardig op weg

Je kan het zo overzetten op een ESP8266 (nodemcu of esp12e)
compatibel, meer geheugen, sneller, zuiniger en goedkoper

En met een Nextion touchscreen nog een eenvoudige mooie UI eraan maken

Yazz schreef : Dat is ook wat ik bedoel. Met progmem kan je een compiler instrueren dat de string in het grogrammegeheugen opgelagen moet worden. Zo maak je ruimte vrij in het dynamisch geheugen.

@Aswin; als newby op de Arduino moet ik nog uitzoeken wat PROGMEM doet. Stond niet in mijn MoSCoW lijstje Maar staat op Could have....(maar kan zomaar een must have worden )

Yazz schreef :
Kun je die strings in preprocessor directives definiëren ? Of zijn het toch echte variabelen ?

@Noreen; er worden zeker een reeks in de preprocessor gedefinieerd zoals #define _HDG "$IIHDG" . Maar voor het parsen, de stack( die ik gebruik als een buffer) worden best wel wat echte variabelen gebruikt. En een String object gebruikt best wat bytes itt een array van characters.
Maar voor nu denk ik dat het moet lukken. Optimization is de volgende stap als de MVP werkt.

Hi Yazz. Gebruik bij voorkeur niet het String object in Arduino, dat is een draak om mee te werken. Beter gewoon een character array gebruiken.

Hierbij een korte uitleg over het opslaan van strings (character array's) in het programmageheugen.

1 Bij de declaratie van een variabele instueer je met behulp van de directive progmem de compiler dat de variabele in het programmageheugen opgeslagen moet worden.De variable moeten constanten zijn want je kunt het programmageheugen niet schrijven vanuit het programma zelf.

2 Je definieert een string als buffer omdat je de progmem variabelen ook niet direct kunt gebruiken en je ze voor gebruik eerst naar de buffer moet kopieren.

3 Als je een string wilt gebruiken kopieer je deze naar de textBuffer met strcpy_P. Daar kan je evt nog eea manipuleren. Vervolgens gebruik je de buffer.