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 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).
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.
Update: There is now also a newer post I’ve just written on a comparable multibody simulation structure in Processing / Java.
So far, I’ve mostly been working on rotational mechanics – multibody models where each mass only has one rotational degree of freedom and two state variables (angle and angular velocity). Every now and then, I use some commercially available tools to simulate more complex 2d and 3d models – often being surprised by how slow simulation is. At the same time, I’ve been wondering a lot:
- how I’d actually model these problems by hand – especially when additional boundary conditions and/or contacts are involved.
- why some video games seem to be able to include complex dynamics with detailed contact and collisions involved, simulating in real time (while commercial multibody simulation often takes hours to calculate a few seconds of dynamic behavior).
An important answer to these questions is the topic of impulse-based dynamics. I stumbled upon it in some amazing literature from Prof. Jan Bender (see http://www.interactive-graphics.de/) and so far I’ve been experimenting a bit with the method myself. This post today features a small and practical introduction to modelling boundary conditions in impulse-based mechanics.
It’s been almost a year since I wrote my post on how to model friction in a dynamic multibody system. Since then, I’ve reconsidered my ideas from the post a few times and finally found out that there’s a theory called “hybrid systems” that intersects with the problems described there.
Let’s assume you want to model a multibody system that includes friction. This seems like a quite reasonable idea to me and in this post, I’ll share what I’ve learned when doing exactly this in GNU Octave (or Matlab – doesn’t matter much since we’ll use quite basic functionality).