Onderwerp: SignalK invoer OpenCPN

@Paradyske: exact.

Hieraan kan je nog toe voegen dat een nauwkeurige registratie van nul en generlei waarde is als de referentietijd niet gelijk is. Dus zelfs als je de meest nauwkeurige klok inbouwt en elk instrument de data met andere vertraging op de bus zet (zonder tijd of met eigen timer) is de nauwkeurigheid nog ver te zoeken.

Ik ben het in 1 ding wel met Roos eens:
De meest voor de hand liggende kritische toepassing is tegenwoordig te vinden in de IMU. Meeste mensen omzeilen de timingsproblemen daarbij door te kiezen voor een geintegreerde oplossing.

3Noreen schreef :
Die kunnen helemaal niets met de timestamp.

reuver schreef :
Precies daar heb ik ervaring mee, GPS compass voor positie, heading en heave met PPS output voor de timing en een IMU.
Werkt dat zomaar goed om een toepassing te stabiliseren, nee, de software die het geheel verwerkt moet ook de locaties van de diverse delen vast kunnen leggen, anders werkt het voor geen meter, in deze toepassing is het helaas niet mogelijk om alle bronnen in één geheel te krijgen en dan begint de ellende, dan werkt het net niet zo als bedacht.

Werken met IMU-data is een probleem op zich.

Als je uitgaat van een standaard MPU-9250 of vergelijkbaar heb je 9 sensoren op dezelfde bus, dus ook zelfde klok. Dan hoef je in principe alleen de software te tunen op een goede dataverwerking.

Dat is een ander probleem als wanneer je (bijvoorbeeld) een 6-DOF IMU als de MPU6500 op je GPIO van je RPI zet en dit samen met de fluxgate op je N2k netwerk probeert te combineren tot complete 9-DOF IMU ("kon ik 2 euri uitsparen want die zat er al op toen ik het schip kocht"). Dan heb je 2 klokken en 2 posities: veel succes.

Binnen de regelkring met een 9-DOF IMU heb je dan alleen nog te maken met een stuurautomaat en een roerstandaanwijzer en een bijna constante koers. Deze laatste hoeven minder exact gesynchroniseerd te zijn met de IMU.

Vanuit de strategie van keep-it-simple zou ik dan kiezen voor een IMU met autopilot los van OpenCPN. Bijvoorbeeld een pilot op een eigen RPI/Arduino of een losse aansturing (van RM/GM/SR/BG/whatever) met misschien een terugkoppeling van de heading voor de weergave op de plotter.

Hoeveel timingsproblemen heb je dan nog?

Helemaal mee eens

Nou werk ik sinds kort voor het bedrijf xsens.com, en wij hebben hele leuke modules, waarmee je realtime alle bewegingen kan registreren.
Bijvoorbeeld deze:
www.xsens.com/inertial-sensor-modules

Of een compleet pak met sensoren waarmee je realtime animaties kan maken!

Bij al die toepassingen is timestamping van cruciaal belang, dus elk sample heeft dat. Tot en met synchronisatiemogelijkheden om alle sensoren tegelijk te laten meten.
Ik zou zeggen, probeer eens .
Ook met CAN-bus leverbaar.

Deze bijvoorbeeld?



Ik kan mij voorstellen dat de set metingen van tijdstip T op tijdstip T+1 in een (1) CAN PGN verzonden worden. Dan ben je een fractie te laat maar de applicatie die deze data gebruikt heeft wel de beschikking over een in de tijd consistente set data.

Maar hoe wordt “timestamp=T” dan meegezonden? Zit die in dezelfde PGN? Dacht dat CAN geen natuve timestamps kent, dus dan zou er in die PGN een dataveld voor beschikbaar moeten zijn.

Mooi spul trouwens!

Nachtvlinder schreef : Zo denk ik er ook over. 3Noreen je zou de IMU met pypilot eens moeten uitproberen!

Ken Xsens ook en nog wel iemand die daar werkt, weet je wat een sensor bij hun kost!

It Paradyske schreef :
off topic=ON

Nou, dan moet je geen hekel aan drones hebben! Wat een geweldige introductiefilm op die website trouwens, zelden zoiets indrukwekkends gezien.

off topic=OFF

Nachtvlinder schreef :
Ze hebben eigen datadefinities.

Zeilprutser schreef :
Ja, hallo, ik moet ook betaald worden!

It Paradyske schreef :
3Noreen is misschien wel handig met fourier transforms en aanverwante wiskunde die hem niets kost maar leeft van een beperkt inkomen, dus reken je niet rijk.