This is the kind of story that makes you remember why you got into engineering in the first place. From whiteboard to orbit: that's the dream trajectory. Curious about the gap between "it works in the lab" and "it works in space." What was the hardest constraint that changed your design assumptions?
Thanks for the feedback! Regarding your question, well, that's a tough one...
Short answer:
- designing for microgravity while in gravity
- one-shot, high-stakes nature of the experiment (there is no live bug-fixing and retries with an updated version)
Long answer:
the project was mostly software-based (apart from the phone itself, provided by Axiom Space), so I did not have to address hardware-related issues directly, which many would consider a more common meaning of "lab" vs "real-life" setup. Still, there were many concepts and constraints to keep in mind. First and foremost, the absence of gravity. It is essentially impossible to simulate all aspects of it in a regular lab. Drop towers, parabolic flights, and sounding rockets are the most common (if not the only) ways to test projects in microgravity, but the time spent in microgravity during these ranged from a couple of seconds to several minutes, plus one does not necessarily have full control over the experiment. The second biggest concern was due to the one-shot nature of the mission, meaning that I had to thoroughly test every function, account for every potential problem, identify and classify every possible risk, and develop fallback mechanisms. Simply put, I had to develop a very robust and fail-safe application while keeping it very intuitive and simple to use.
While there were no 180-degree turns during the development, it was very challenging to account for every aspect of microgravity and the "no-second-chance" nature of the project.
thanks! Yes, it is very challenging, almost impossible to maintain tracking on a very high level of precision during larger time scales without the incorporation of further readings of the actual environment (e.g. magnetic field strength for orientation updates, ultrasonic distance metres, cameras, etc., and all that fed into a Kálmán-filter). Navigation of the aforementioned space drones is not meant to rely solely on IMU data, but needless to say, the lower the accumulated error stays, the better off we are. Close-quarter navigation can be greatly supported by IMUs, e.g., with checkpoints not too far apart, where these could serve as update points of "known" position or the like (and be inputs to a Kálmán-filter). One can also model the path of small space vehicles as the sequence of different path shapes (curves, lines, loops etc.) that can be learned by a machine learning model as well, and help with path planning and maneuvering.
In this regard, the work of S. Bonnabel and A. Barrau in the field of invariant Kálmán-filters (IEKF) is very inspiring and useful in this case, and I can only recommend it.
Regarding the magnetic field strength: yes, absolutely, it also surprised me. The data shown in the plot consists of raw readings from the magnetometer.
This is the kind of story that makes you remember why you got into engineering in the first place. From whiteboard to orbit: that's the dream trajectory. Curious about the gap between "it works in the lab" and "it works in space." What was the hardest constraint that changed your design assumptions?
Thanks for the feedback! Regarding your question, well, that's a tough one...
Short answer:
- designing for microgravity while in gravity
- one-shot, high-stakes nature of the experiment (there is no live bug-fixing and retries with an updated version)
Long answer:
the project was mostly software-based (apart from the phone itself, provided by Axiom Space), so I did not have to address hardware-related issues directly, which many would consider a more common meaning of "lab" vs "real-life" setup. Still, there were many concepts and constraints to keep in mind. First and foremost, the absence of gravity. It is essentially impossible to simulate all aspects of it in a regular lab. Drop towers, parabolic flights, and sounding rockets are the most common (if not the only) ways to test projects in microgravity, but the time spent in microgravity during these ranged from a couple of seconds to several minutes, plus one does not necessarily have full control over the experiment. The second biggest concern was due to the one-shot nature of the mission, meaning that I had to thoroughly test every function, account for every potential problem, identify and classify every possible risk, and develop fallback mechanisms. Simply put, I had to develop a very robust and fail-safe application while keeping it very intuitive and simple to use.
While there were no 180-degree turns during the development, it was very challenging to account for every aspect of microgravity and the "no-second-chance" nature of the project.
Hope that answers your question!
thanks! Yes, it is very challenging, almost impossible to maintain tracking on a very high level of precision during larger time scales without the incorporation of further readings of the actual environment (e.g. magnetic field strength for orientation updates, ultrasonic distance metres, cameras, etc., and all that fed into a Kálmán-filter). Navigation of the aforementioned space drones is not meant to rely solely on IMU data, but needless to say, the lower the accumulated error stays, the better off we are. Close-quarter navigation can be greatly supported by IMUs, e.g., with checkpoints not too far apart, where these could serve as update points of "known" position or the like (and be inputs to a Kálmán-filter). One can also model the path of small space vehicles as the sequence of different path shapes (curves, lines, loops etc.) that can be learned by a machine learning model as well, and help with path planning and maneuvering.
In this regard, the work of S. Bonnabel and A. Barrau in the field of invariant Kálmán-filters (IEKF) is very inspiring and useful in this case, and I can only recommend it.
Regarding the magnetic field strength: yes, absolutely, it also surprised me. The data shown in the plot consists of raw readings from the magnetometer.