In April, during CodeGeneration 2012, Markus Völter and Bernhard Merkle showed us MBeddr - a modularized implementation of C created in MPS. A useful effort, that proved to be useful in a real-world project as well.
At the time, he showed me briefly what I should do to build in support for coordinate systems and conversion between them. If you are creating software for mechatronics systems in C, you probably know how easy it is to implement vectors as structs, and then forgetting about the coordinate system they were created in. Net result: at best an occasional mistake in direction of a vector (+ and - sign mix up), at worst a completely wrong conversion that will only show at the most inconvenient time - at the customer site.
If we had a mechanism to prevent this type of error, even before we run unit tests that might be a great help. The physical units module implemented in MBeddr C could be the start of that.
So, what would it bring if we implemented something that allows us to type the following, assuming we have vectors in two coordinate systems named rootCS and derivedCS?
vector2d someVector#rootCS = (10, 20)#rootCS;
vector2d someOtherVector#derivedCS = (10,20)#derivedCS;
vector2d resultVector#rootCS = someVector + someOtherVector;
Depending on implementation, this could lead to two situations:
- We get an error message when on the assignment to resultVector because the two operands of the addition are expressed in different coordinate systems, or
- An automated conversion is inserted such that SomeVector is first converted to rootCS
Even better, taking into account performance, we could add a third alternative, forcing us to explicitly specify the conversion in places where we want it. This could be done in the same way as explained for physical units in the MBeddr User Guide. Where no explicit conversion is programmed, we'd get the aforementiond error message again.
vector2d resultvector#rootCS =
[someVector -> rootCS] + [someOtherVector -> rootCS ];
Today, finally, after a delay of over 4 months, I picked up the latest implementation of MBeddr and started implementing this.
Right now, I'm pondering over the following:
- How to specify a coordinate systems and conversions in a useful manner?
Coordinate systems in mechatronics systems are relative to the system, not the universe, and they may vary over time depending on calibrations and drifts. So, they cannot be part of the language, and the conversions are not fixed.
- If we can do this for 2D and 3D vectors, could we also do it for 6DOF vectors (i.e. vectors that contain x, y and z, but also take into account roll, yaw and rotation)
- Can we integrate vectors, coordinate systems and the already implemented physical units, so that we can enforce vectors to be expressed in meters (and rad for the 6DOF angles)?
Over the next two weeks, I hope to finish a first implementation, and who knows, it may end up in the MBeddr Git repository at some point.