I was at ICRA last week and I had the pleasure to talk at the workshop entitled "What Sucks in Robotics and How to Fix It: Lessons Learned from Building Complex Systems" organized by Gian Diego Tipaldi and Cyrill Stachniss. This was a truly exceptional event where people showed up to talk honestly and challenge each other about robotics as a science and an engineering discipline.
My presentation was called "Representing Robot Pose: The good, the bad, and the ugly", where I tried to give some basic recommendations on how to talk about, write about, and code with representations of robot attitude and pose. I have seen many hours of productive time lost within my lab when students were trying to interface an open source package or process a dataset where the notion of robot pose was not clear enough to implement it correctly without trial and error (and pain and misery and suffering).
Here are the slides from the talk. To make everything easily accessible, I've written a brief overview below. Please let me know if anything is unclear of if you find typos!
A large part of the practice of robotics is fundamentally about developing machines that can perceive and interact with the real physical world. And for that, we need to talk about, write about, write computer programs that represent robot poses. For the most part, we are extremely bad at this. There are hundreds of ways of turning a handful of scalars into a transformation matrix and, unless we are extremely clear about how to do this and how the result can be applied, we are condemning each other to wasted time and effort experimenting with the different possibilities until we find the one that fits. Rather than get in to religious discussions about which representation is correct, I propose a minimum amount of documentation to avoid ambiguity.
My goal in writing this is to convince you to go back to your documentation, papers, datasets, and open-source software to update the text so that the interpretation of the frame transformations is completely unambiguous to the user. Said another way, I would like you to help me reduce the amount of suffering in the world. There are many, many interesting problems that we still need to solve in robotics, and it pains me to see students and engineers losing days struggling with basics that can be avoided with some simple clear documentation.
I will use the notation that we have proposed for our software library "Kindr". We traced this notation back to the book "Elastic Multibody Dynamics -- A Direct Ritz Approach" by H. Bremer. I'll try to find time to make another post about notation that covers the major styles used in robotics.
1. Always provide a frame diagram