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’m not only a simulation nerd, I’m also a visualization nerd. My interest in formatting, layout and displays has proven to be extremely helpful in my daily work, where finding the right visual is often key to analyzing and communicating large measurement and simulation datasets. Sometimes, I also find the time to participate in fun events like the recent storytelling with data visualization challenge – which also is a good excuse to write this post on plots and visualization techniques.
So here are some simple tips to get better result plots and graphs. Most of my advice is focused on visuals for simulation results, especially in the context of large datasets and use-cases where you have to plot results frequently (like multibody simulations). This often boils down to getting the workflow right – the most beautiful visuals won’t help when creating them takes more time than what’s available.
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.
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).
I got a small display compatible with my Due for christmas. And since I really wanted to see some arduino-in-the-loop simulations, I decided to use it for exactly this: real-time multibody simulations on the Ardunio and the results displayed on the tft.
It’s been more than a year since I published my post on numerical integration on an Arduino. Since then, the post has been quite popular, recieving a steady stream of visitors (mostly via Google). When I originally wrote it, I only had an Arduino Uno at hand – since then I’ve added a couple of Nanos and lately an Arduino Due to my inventory and decided it would be interesting to do a couple of speed tests to see how they perform. The latest addition to my growing circus of microcontroller boards is a Teensy 3.5 board.
As I pointed out in the original post, numerical integration relies heavily on floating-point math – which is something the Arduino’s 8-bit processor is not particularly good at. The Due features a 32-bit processor, a clock frequency of 84 instead of 16 MHz and the possibility to use double (64 bit) instead of float (32 bit) as a data type – so I was curious to see how it would compare to the Arduino Uno. The Nano is supposed to have more or less the same characteristics as an Uno, but is a lot smaller and cheaper – see below for details.
Now added to the comparison, the Teensy 3.5 includes a 32-bit processor with 120 MHz clock speed and a FPU for speedier floating-point math.
I’ve spent some time on setting up audio and video streaming on my raspberry pi (mostly used as a baby monitor right now). While there are great ressources out there, it took me a lot of effort to find them and put everything together. So here’s a handy list of instructions if you want to:
- Record and stream audio
- Record and stream both audio and video into one file
- Are just looking for an introduction into the topic.
This post is not really about multibody dynamics. Instead of simulating stuff, I’ve actually built something: A glowing, more-or-less-interactive lamp.
We are awaiting our first child and with all the things we bought (mostly used), there was a small, adorable lamp. Unfortunately, it had some weird-looking electrics inside (both looking very old and labeled for 120V – so it wouldn’t work with our 230V here in Germany), so we decided to remove all cables and replace them with LEDs. Actually, WE just decided not to use the existing cables and then I talked my wife into letting me build something with an Arduino.
So I hooked up the lamp with a digital LED-stripe – I found one that came with digitally-adressable LEDs and used the Adafruit Neopixel library to adress those. Now there are 24 RGB-LEDs inside the lamp which I can control direct with the Arduino.
What’s better suited for object-oriented programming (OOP) than building a simulation of a physical system? Each physical object (e.g. mass, spring etc.) can be implemented as an object and then we should be able to easily build and modify large models.
However, there are a lot of challenges to get there, including:
- How to work with classes and objects at all (if you’re like me new to OOP)?
- How to build a working object structure that adopts to the requirements of a typical ODE solver (which usually requires access to all state variables in the so-called state-space representation)
- How to design classes for different object types in a way that allows them interact with each other to calculate and transmit forces and accelerations.
Getting there turned out to be quite interesting and I finally got a simple object-oriented multibody model to simulate in Matlab and GNU Octave. This post is a wrapup of all the stuff I learned to get there.