I’ve got some great references and quotes here that help me explain how exactly we are able to numerically calculate the dynamics of a multibody system.
I’ve finally built my Due and TFT into a nice housing and coded a reasonably well-working oscilloscope and datalogger for it. Here’s what I’ve learned along the way!
The oscilloscope showing analog input and digital output from an Arduino Uno powering a servo motor with the “knob” example sketch from the Arduino servo library.
I’ve used a lot of different configurations of Arduino-related gear as datalogging utilities. So here’s a comprehensive guide on what’s possible, how to set up stuff and on what you can expect regarding accuracy, battery life and logging speed.
(However, please keep in mind that I’m neither particularly skilled with electronics nor programming and other’s know a lot more on this than I do. I’m particularly grateful that Ed Mallon provided a link to this paper he coauthored with Patricia Beddows in the comments – the work and knowledge they put into it is just amazing)
My Arduino Uno with the datalogger shield both temperature and brightness sensors connected. I used a normal smartphone charger to power it for more than 3 days and placed it in this fireproof baking tray since I felt somewhat unsure about having it running unattended.
I recently learned about the Kalman filter and finally got to play around with it a little bit. Since I had a hard time figuring out how to get it to work, here’s a practical (but yet general) introduction with examples:
A Kalman filter works by matching a simulation model and measured data. For each data point, an estimation of the simulation model’s internal state is computed based on the estimate of the previous state. This works with noisy data and limited measurement signals (e.g. a model with 10 state variables but only 2 measurement signals, although there are obvious limitations here (the more and the better the sensor data, the better the results should be – there’s also some limit on observability).
So we have this interesting tool which does all these different things:
- filtering noisy data, while taking knowledge (or assumptions) on the underlying dynamics into account
- merge data from several different sensors into one signal (typical application: combine GPS and acceleration sensor data into one accurate position signal)
- offer a prediction of a system’s future state
- estimate internal parameters of a system (say a spring stiffness based on measured oscillations)
Another interesting use is that we might try two different simulation models on the same measurement and check which one does a better job at synchronizing to the measurement (I’ll do this in a very simple example below).