WEBVTT 00:00:01.490 --> 00:00:05.950 It's Rust in Production, a podcast about companies who use Rust to shape the 00:00:05.950 --> 00:00:06.850 future of infrastructure. 00:00:07.190 --> 00:00:11.530 My name is Matthias Endler from corrode, and today we talk to Sebastian Scholz 00:00:11.530 --> 00:00:16.170 from Gama Space about controlling solar sails and satellites with Rust. 00:00:19.010 --> 00:00:23.050 Sebastian, thanks very much for taking the time for the interview today. 00:00:23.230 --> 00:00:25.670 Can you say a few words about yourself and about Gama? 00:00:26.170 --> 00:00:30.510 Yes, thank you very much for having me, Matthias. I'm very excited to be here. 00:00:30.710 --> 00:00:36.550 My name is Sebastian Scholz, and I'm an electronics and embedded system engineer at Gama Space. 00:00:36.890 --> 00:00:42.790 We are based in Paris, and I've been with Gama Space since January 2023. 00:00:44.030 --> 00:00:50.330 Our mission, our Gama Space's mission, is to develop and provide a propulsion 00:00:50.330 --> 00:00:53.030 technology called solar sails in space. 00:00:53.870 --> 00:01:00.990 And to do that, we are using rust in various places. And that's what I'm here to talk about. 00:01:01.470 --> 00:01:08.130 Now, not everyone might be familiar what a solar sail is. Can you describe the principle behind it? 00:01:08.510 --> 00:01:12.070 Yes. So the concept is actually rather simple. 00:01:12.570 --> 00:01:16.790 You know, when you have a sail on a boat, you have the wind blowing into it. 00:01:17.050 --> 00:01:22.630 In space, you don't have that, but you have the sun. And the photons of the 00:01:22.630 --> 00:01:26.110 sun provide some amount of pressure on a sail. 00:01:26.250 --> 00:01:31.610 So if you have reflective space, the reflections of the photon give you an impulse 00:01:31.610 --> 00:01:34.130 and so provide momentum to your sail. 00:01:34.270 --> 00:01:41.270 So basically, it's a way of moving in space, but without fuel and just relying on the sun. 00:01:41.610 --> 00:01:41.950 Wow. 00:01:43.890 --> 00:01:45.830 Basically, free propulsion. 00:01:46.490 --> 00:01:50.270 Basically, free propulsion. That's exactly it. The main advantage of it, 00:01:50.410 --> 00:01:54.030 of combustion propulsion, is that you don't need to bring your fuel with you. 00:01:54.430 --> 00:01:58.670 So, as you might know, it's still kind of hard to get mass into space. 00:01:58.670 --> 00:02:06.230 So, by saving all of this potential fuel mass, it's going to be easier and cheaper to go into space. 00:02:06.450 --> 00:02:09.390 And the trade-off is speed, I'm assuming, right? 00:02:09.390 --> 00:02:15.010 Yes, of course, there are some downsides compared to a normal combustion engine. 00:02:15.370 --> 00:02:18.730 The impulse, the specific impulse that you get is rather low. 00:02:18.850 --> 00:02:23.850 So that means the acceleration is extremely low, actually, in the area of a 00:02:23.850 --> 00:02:27.750 few newtons versus kilonewtons that you get from normal propulsion. 00:02:27.950 --> 00:02:31.390 So that means you have to plan your trajectories accordingly. 00:02:31.950 --> 00:02:36.910 But, I mean, the benefit is that this propulsion is infinite compared to the 00:02:36.910 --> 00:02:40.190 fuel, because at some point fuel runs out. But the sun, it's going to take a 00:02:40.190 --> 00:02:41.510 very long time for it to run out. 00:02:42.110 --> 00:02:43.790 Unless you're too far away from the sun. 00:02:44.570 --> 00:02:48.210 Yeah, but even if you're too far away from the sun, you still get some amount 00:02:48.210 --> 00:02:51.130 of propulsion. I mean, it's not like you're on an empty tank. 00:02:51.710 --> 00:02:57.050 You still have some amount of movability even if the sun is very low. 00:02:57.350 --> 00:03:03.170 But if you're on the outside of the solar system, you're going to have to move 00:03:03.170 --> 00:03:05.350 a bit slower. Yes, that's absolutely true. 00:03:05.990 --> 00:03:10.650 It's not a physics podcast, but at the same time, I'm always curious about space. 00:03:10.810 --> 00:03:13.930 It's a thing that's fascinated me since I was a child. 00:03:14.130 --> 00:03:21.570 And a lot of people, they requested an episode with you and with the project 00:03:21.570 --> 00:03:25.890 that you do, which we're here to talk about, because you also happen to use Rust. 00:03:26.490 --> 00:03:29.710 Yes, quite extensively, as a matter of fact. 00:03:30.090 --> 00:03:35.990 So for the solar sails, we have launched in January 2023. 00:03:36.010 --> 00:03:39.930 So right around the time when I joined the company, we've launched a satellite, 00:03:40.230 --> 00:03:44.510 a demonstration mission for this technology, the solar sails. 00:03:44.770 --> 00:03:48.570 And the onboard data handling system, our part of the satellite, 00:03:48.790 --> 00:03:51.290 is more or less completely written in rust. 00:03:51.290 --> 00:03:58.290 So we have a few sealers underneath the hood, but the main code and all of the 00:03:58.290 --> 00:04:01.430 supporting test equipment was written using Rust. 00:04:02.510 --> 00:04:08.330 Now, isn't it extremely risky to use Rust for such a mission? 00:04:08.330 --> 00:04:10.550 You don't really have that many tries anyway. 00:04:10.570 --> 00:04:13.310 It's not like redeploying a backend or so. 00:04:13.770 --> 00:04:19.270 Yes, there's one of the great dangers if you develop something for space. 00:04:19.270 --> 00:04:22.290 You get one shot with your 00:04:22.290 --> 00:04:24.990 satellites and if you mess it up it's not like you 00:04:24.990 --> 00:04:29.030 could just go up and try to reboot it you know you you 00:04:29.030 --> 00:04:31.790 really have only one shot but the mindset that 00:04:31.790 --> 00:04:37.510 we have at Gama is the mindset of the new space companies so we try to move 00:04:37.510 --> 00:04:45.310 fast and fail fail fast so we try a bunch of new things and if we do fail it's 00:04:45.310 --> 00:04:50.010 unfortunate of course but it's not a big deal That's kind of how we do learn. 00:04:50.850 --> 00:04:55.610 And so what we wanted to do with this mission, it's a demonstration mission. 00:04:55.730 --> 00:04:59.970 So we wanted to demonstrate our technology, but we also wanted to try out new things. 00:05:00.290 --> 00:05:06.330 And so using Rust as the main driver for our onboard data handling system was 00:05:06.330 --> 00:05:11.590 one of these decisions that we wanted to try out to see if it's going to be 00:05:11.590 --> 00:05:13.010 usable for the future as well. 00:05:13.480 --> 00:05:19.120 And before we talk about the onboard data handling system, what do you define 00:05:19.120 --> 00:05:24.320 as new space and what are maybe other companies in that realm? 00:05:25.080 --> 00:05:31.600 Yeah, so the main one that is probably known to everyone is SpaceX in that regard. 00:05:31.600 --> 00:05:37.700 And you can definitely see in the way they work that they like to fail fast as well. 00:05:38.220 --> 00:05:42.960 I mean, just look at the Starship launches. The development of this kind of 00:05:42.960 --> 00:05:48.780 rocket is extremely difficult, but they're doing it very fast and they're failing very fast as well. 00:05:48.880 --> 00:05:52.020 I mean, many of these launches end with spectacular explosions. 00:05:52.400 --> 00:05:58.460 And so the mentality is, yeah, OK, we're going to have to spend a lot of resources, 00:05:58.460 --> 00:06:01.340 but we're going to learn a lot of it as well. 00:06:02.330 --> 00:06:05.130 You're doing the failure so yeah that's 00:06:05.130 --> 00:06:08.050 that's just one way of moving forward versus in the past 00:06:08.050 --> 00:06:10.910 the kind of old space which 00:06:10.910 --> 00:06:17.870 is the big entities like nasa they want to do it once and want to do it correctly 00:06:17.870 --> 00:06:22.790 and i mean this mindset is also very important if you're doing like deep space 00:06:22.790 --> 00:06:26.810 missions as well where it takes a really long time to get to places for example 00:06:26.810 --> 00:06:28.990 i mean as well if you want to go to Mars. 00:06:29.670 --> 00:06:35.630 You kind of get one shot and if you don't do it correctly, you're going to have 00:06:35.630 --> 00:06:38.290 to wait a couple 10 or more years to get back. 00:06:38.470 --> 00:06:44.770 Okay, it's a test mission and yet it is foundational software that you're writing 00:06:44.770 --> 00:06:51.390 because you might as well just use some of the more established or some of the 00:06:51.390 --> 00:06:53.390 more common languages like C, 00:06:53.550 --> 00:07:00.310 C++ or maybe even ADA for the test mission for Gama Alpha but you chose rust why. 00:07:00.310 --> 00:07:03.970 So this mainly boils down to our 00:07:03.970 --> 00:07:06.950 software engineer at the time so this was 00:07:06.950 --> 00:07:12.510 before i started working at the company i i didn't mention but the Gama Space 00:07:12.510 --> 00:07:19.770 itself is only about five years old now so it was founded in the 2020s and we 00:07:19.770 --> 00:07:26.090 well We kind of move relatively fast and the team only grows relatively so. 00:07:26.210 --> 00:07:28.970 So right now we are, I think, 21 people in the company. 00:07:29.110 --> 00:07:32.530 And at that point, when we launched Alpha, it was more like 12. 00:07:33.630 --> 00:07:38.710 And most of our team is actually in mechanics because as you can imagine, 00:07:38.910 --> 00:07:44.010 I mean, the folding and creation of the sale is its own topic. 00:07:44.470 --> 00:07:49.090 It's one of the main things that we do. And so we only had one team 00:07:49.510 --> 00:07:52.350 electronics and embedded systems engineer the one that was 00:07:52.350 --> 00:07:56.310 responsible for the creation of of 00:07:56.310 --> 00:07:59.450 the on-board data handling system at the time which is 00:07:59.450 --> 00:08:05.350 a colleague of mine called Chris and his background was mainly in c plus plus 00:08:05.350 --> 00:08:13.410 and so he decided but he he knew that c plus plus was not well suited for well 00:08:13.410 --> 00:08:17.970 i mean it was difficult to use to get a reliable piece of software for the space environments. 00:08:18.190 --> 00:08:23.570 And so when he looked into options and other kind of languages to use, 00:08:24.370 --> 00:08:29.630 he decided that Rust would be a perfect fit for our case. He had a little bit 00:08:29.630 --> 00:08:31.410 of prior experiences in it as well. 00:08:31.710 --> 00:08:34.350 And so that's why we didn't choose Ada, for example. 00:08:35.510 --> 00:08:39.570 And how did he evaluate Rust? I know that you were not there, 00:08:39.730 --> 00:08:43.930 but maybe you talked to them about it. Why did they choose it? 00:08:43.930 --> 00:08:51.350 Yes. So basically, he did a trade-off of Rust versus other languages. 00:08:51.930 --> 00:08:57.590 And I mean, it came out clearly on top. The memory safety, just eradicating 00:08:57.590 --> 00:09:03.710 a whole bunch of errors that you can have with C and C++ is really critical 00:09:03.710 --> 00:09:05.410 for space applications. 00:09:05.410 --> 00:09:11.190 It's these kind of avoidable errors that can be caught before you deploy your 00:09:11.190 --> 00:09:14.710 code, that can just be denied by the compiler. 00:09:15.210 --> 00:09:20.950 And in general, the help that the compiler gives you compared to other languages 00:09:20.950 --> 00:09:26.790 in writing safe and good code, this I think was the main driver. 00:09:26.790 --> 00:09:31.810 And, of course, the ability to still go into the embedded systems level, 00:09:32.010 --> 00:09:35.490 still be real-time and be reliable. 00:09:37.510 --> 00:09:41.110 How can I imagine day-to-day at Gama? 00:09:41.170 --> 00:09:48.970 Do you use any special software that us normal, let's say, earthly Rust developers don't use? 00:09:49.090 --> 00:09:54.270 Or would you say, no, it's mostly the same components, it's mostly the same 00:09:54.270 --> 00:10:00.150 code structure, it's the same CI/CD platform like any other project? 00:10:00.690 --> 00:10:05.290 Yeah, actually, it's very, very similar. So in a bunch of companies, 00:10:05.290 --> 00:10:09.490 you would find setups with GitLab, for example, and so do we have it. 00:10:09.850 --> 00:10:16.310 We use a lot of crates that are just out there for many people to use, 00:10:16.710 --> 00:10:22.670 like ZeroCopy, for example, and other things, probe-rs for our debugging environment. 00:10:24.170 --> 00:10:29.170 It's a little bit more specific because we work with hardware. 00:10:29.590 --> 00:10:35.150 So in many software companies, you have your code, you have unit tests, 00:10:35.290 --> 00:10:39.270 you have integration tests that you run on your CI, and that's that. 00:10:39.450 --> 00:10:41.590 We have to interface with actual real hardware. 00:10:42.070 --> 00:10:49.630 And so maybe one of the key differences is that we have a flat-sat for the Gama Alpha 00:10:49.630 --> 00:10:51.930 product, so for theGama Alpha satellite. A 00:10:52.910 --> 00:10:57.970 flat-sat, I should say, is basically the electronics of the satellite unwrapped, 00:10:58.150 --> 00:11:02.430 laid out on a flat on a table, hence the name flat set. 00:11:02.430 --> 00:11:07.650 And it's a one-to-one, pretty much a one-to-one copy of the actual hardware 00:11:07.650 --> 00:11:12.670 of the satellite and we integrated it in our CI so that our tests, 00:11:12.970 --> 00:11:18.190 we have mainly integration tests and they run on the actual hardware and then 00:11:18.190 --> 00:11:25.210 we have probes attached to look at the actual output of the system and make 00:11:25.210 --> 00:11:26.210 sure that everything is all right. 00:11:26.770 --> 00:11:31.590 It's kind of cool that you use probe-rs especially because, 00:11:33.330 --> 00:11:39.170 All of the embedded, or I call it embedded, but like all of the low-level projects 00:11:39.170 --> 00:11:42.350 that I know of use it to some extent. 00:11:42.850 --> 00:11:46.450 Was it a natural choice for you? Did you evaluate anything else? 00:11:46.630 --> 00:11:51.030 Is there even anything else in that space? Or is probe-rs the de facto standard now? 00:11:51.850 --> 00:11:58.490 Yeah, it took us a while to get all of these systems up and running. 00:11:58.590 --> 00:12:02.650 And in the process of doing so, we did evaluate multiple things. 00:12:02.650 --> 00:12:06.850 But there was not a lot of choice for this sort of thing. 00:12:07.030 --> 00:12:13.670 We could have also just used regular C debuggers, as in just start a different 00:12:13.670 --> 00:12:16.130 process with the debugger and then interface with that. 00:12:16.310 --> 00:12:20.390 That was one of the other options that we looked at. 00:12:20.930 --> 00:12:23.870 I mean, that would basically have been the normal C approach, 00:12:24.070 --> 00:12:28.490 you know, like just use a GDB, for example, as a debugger. 00:12:29.950 --> 00:12:35.130 But the benefit of probe-rs was that, of course, it was written in Rust, 00:12:35.310 --> 00:12:42.770 and it allowed for a lot more fine-grained control of what we wanted to do with our integration tests. 00:12:42.770 --> 00:12:47.510 For example, we have a system to compile, 00:12:47.830 --> 00:12:54.070 test Rust binaries, and then upload them via probe-rs onto the actual hardware, 00:12:54.250 --> 00:12:58.190 and then look at the output and look for certain signals to make sure that the 00:12:58.190 --> 00:13:00.050 test that this binary represents passes. 00:13:00.530 --> 00:13:05.550 So that was very easy to do in Rust and using probe-rs. 00:13:06.030 --> 00:13:11.630 And how does that system look like? How does it work? What's the end-to-end development flow? So, 00:13:12.900 --> 00:13:16.700 So I'm guessing you develop code in your IDE. I'm not sure which IDE you use. 00:13:16.980 --> 00:13:25.740 Yeah, so we use VS Code. And so if we want to develop a new feature or work on some code, 00:13:26.040 --> 00:13:30.500 the typical workflow would be, so you write your code, you push it onto a new 00:13:30.500 --> 00:13:32.920 branch, and as soon as you push, 00:13:33.380 --> 00:13:36.940 our CI starts, and it reserves a slot on the flat side. 00:13:37.180 --> 00:13:40.340 The interesting thing is that we also use the flat side for manual debugging. 00:13:40.340 --> 00:13:44.340 So we have kind of a little bit of a system where you can reserve a slot on 00:13:44.340 --> 00:13:47.060 the flat set. During that time, the CI can't run and has to wait. 00:13:47.380 --> 00:13:50.780 But if the CI is running, you have to wait for a bit until it's finished. 00:13:51.240 --> 00:13:56.360 And so we kind of have a little server, which unsurprisingly is also written in Rust. 00:13:57.900 --> 00:14:00.980 Yes, that kind of manages the access to the flat set. 00:14:01.660 --> 00:14:02.780 And you wrote that yourself? 00:14:03.120 --> 00:14:05.960 Yeah, we wrote it ourselves. I think, oh, it's been a while, 00:14:05.960 --> 00:14:10.900 but I think it uses Hyper as a web server. 00:14:11.080 --> 00:14:13.200 I think it's called Hyper. Yeah. 00:14:14.240 --> 00:14:20.200 And basically, it manages access to it. At that time, so it has a web interface, 00:14:20.200 --> 00:14:24.840 and at that time, we wanted to kind of get fancy, and I have a little bit of 00:14:24.840 --> 00:14:27.340 a background in Flutter development as well. 00:14:27.520 --> 00:14:34.460 So the web interface is based on Flutter, but the actual logic and the serving of the files is in Rust. 00:14:34.840 --> 00:14:37.820 Oh, wow. that's a 00:14:37.820 --> 00:14:41.660 really cool project in and of itself because because i 00:14:41.660 --> 00:14:46.740 really wondered how would you how would you test your hardware components you 00:14:46.740 --> 00:14:51.540 kind of want to abstract that away you don't want to unplug and plug it back 00:14:51.540 --> 00:14:55.820 in again you kind of want to have a system for that and i'm assuming that there's 00:14:55.820 --> 00:15:00.500 not much on the market especially for flat sets like this it's probably a, 00:15:01.180 --> 00:15:04.180 Still an embedded setup, just like any other embedded setups. 00:15:04.360 --> 00:15:10.240 But the moment you go into the details here, you will find that you probably 00:15:10.240 --> 00:15:11.400 need a custom solution, right? 00:15:12.040 --> 00:15:16.440 Exactly. So this is one of the unfortunate truth. If you do develop your own 00:15:16.440 --> 00:15:20.240 system, there's no one solution fits all kind of a thing. 00:15:20.620 --> 00:15:25.480 So we did try to find generic solutions for embedded testing. 00:15:25.760 --> 00:15:29.060 And I don't know how it looks right now, but a couple of years ago, 00:15:29.280 --> 00:15:33.780 two and a half years ago, So there wasn't really a lot that helped you write 00:15:33.780 --> 00:15:37.320 actual tests for the embedded target and run them. 00:15:37.780 --> 00:15:42.280 So yes, this solution of the integration tests and the test suite itself is 00:15:42.280 --> 00:15:45.120 also a custom solution that we developed in Rust as well. 00:15:45.600 --> 00:15:50.280 So the whole integration test suite is also written in Rust and developed in-house. 00:15:51.260 --> 00:15:55.360 But the integration tests are still in a tests folder, just like you would expect 00:15:55.360 --> 00:15:57.060 from any normal Rust project, right? 00:15:57.300 --> 00:16:00.320 Yes, pretty much. so basically it's a 00:16:00.320 --> 00:16:05.920 binary that has all of the tests in it and then we just upload this binary to 00:16:05.920 --> 00:16:11.000 the hardware and then let it run and we look at the output via communication 00:16:11.000 --> 00:16:17.520 protocol I think for that we use just UART very common low-level communication protocol. 00:16:18.860 --> 00:16:23.740 Now earlier you mentioned correctness in a different context but I think it 00:16:23.740 --> 00:16:32.500 fits in here as well because couldn't you test a lot of the logic with unit tests? 00:16:33.320 --> 00:16:39.960 Or is it so that you kind of want to always test the inputs and outputs as well 00:16:39.960 --> 00:16:42.440 because it's kind of a monolithic service? 00:16:44.280 --> 00:16:52.200 Yeah, we have some unit tests and for smaller functionalities we do use those to test. 00:16:53.960 --> 00:16:57.560 The theme that we have in our code is we have one, 00:16:58.680 --> 00:17:01.520 big project but it's it's built 00:17:01.520 --> 00:17:04.520 up in smaller crates so the big kind of onboard data 00:17:04.520 --> 00:17:07.300 handling system software uses a lot of smaller crates 00:17:07.300 --> 00:17:10.100 that we also develop and the smaller crates they 00:17:10.100 --> 00:17:12.960 have unit tests for their functionality but for 00:17:12.960 --> 00:17:17.120 the big onboard data handling system it's harder 00:17:17.120 --> 00:17:22.640 to test these things because they're very much hardware specific so for example 00:17:22.640 --> 00:17:28.880 if i want to test that our persistence works so we are able to store data in 00:17:28.880 --> 00:17:32.620 some sort of flash memory i can't just write a unit test for it because i need 00:17:32.620 --> 00:17:36.240 the actual hardware i sure i could try to emulate it somehow, 00:17:37.240 --> 00:17:40.860 but that's a bunch of extra work and i'm not guaranteed that it is going to 00:17:40.860 --> 00:17:46.820 actually work on the hardware itself so in an embedded environment you you kind of can't, 00:17:47.490 --> 00:17:51.750 avoid doing integration tests because you need to test on the hardware so you're 00:17:51.750 --> 00:17:54.470 just going to test the whole system as a whole yeah. 00:17:54.470 --> 00:17:58.250 Well when you say that you store files on 00:17:58.250 --> 00:18:04.870 flash in a normal scenario it wouldn't be a problem if the flash storage fails 00:18:04.870 --> 00:18:10.090 you can't just you know fix it because it's maybe right next to you but it's 00:18:10.090 --> 00:18:16.430 harder to do in space do you have any failover for that sort of hardware failure? 00:18:16.650 --> 00:18:18.210 And if so, how do you test that? 00:18:19.270 --> 00:18:25.390 Yeah. So in fact, all of our flash memory, first of all, it's a very specific 00:18:25.390 --> 00:18:29.570 chip usually that has some built-in error detection and correction. 00:18:29.910 --> 00:18:33.290 So on a hardware level, we are protected against it. 00:18:33.390 --> 00:18:39.110 But on top of that, for specific parts of code that is stored on this flash, 00:18:39.250 --> 00:18:41.410 because that's the important thing. 00:18:41.830 --> 00:18:45.690 Code needs to be stored somewhere. And so if that code gets corrupted, 00:18:46.070 --> 00:18:47.710 you're going to be in big trouble. 00:18:47.930 --> 00:18:54.470 So one of the steps that we do in our bootloaders is that we check this code for errors. 00:18:57.030 --> 00:19:00.850 For example, for bit flips. In space, you have radiation. 00:19:01.050 --> 00:19:06.790 And so just random bits in your data and your code in that instance can just 00:19:06.790 --> 00:19:09.650 randomly fit, which can mess up the entire code flow. 00:19:09.870 --> 00:19:17.670 So we have steps. We have code written to verify that the stored code that we 00:19:17.670 --> 00:19:22.710 have in our flash memory is correct and that can potentially even recover from errors. 00:19:23.010 --> 00:19:28.810 So there's something called a hemming code, which means you basically reserve 00:19:28.810 --> 00:19:33.310 some extra space for redundant bits and you can use those bits later to detect 00:19:33.310 --> 00:19:36.110 and to recover from flipped bits. 00:19:36.110 --> 00:19:42.470 And this kind of code we have integration tests that uses prop.is to manually 00:19:42.470 --> 00:19:47.390 write into the flash into memory even and to flip some bits, 00:19:48.190 --> 00:19:52.850 And then we'll let it boot, see that it handles these kind of corruptions that 00:19:52.850 --> 00:19:55.710 we introduce correctly and fixes itself, yes. 00:19:56.630 --> 00:19:58.410 And that's also a custom solution? 00:19:58.970 --> 00:20:03.910 Yes. I mean, this is one of the tests that we run during our integration tests. 00:20:04.310 --> 00:20:12.050 So, yes, the integration test suite has a component that allows it to write into this flash memory. 00:20:12.150 --> 00:20:14.450 And that is developed by us, and that's a custom solution. 00:20:14.450 --> 00:20:17.150 Indeed let's talk 00:20:17.150 --> 00:20:20.030 a little bit about your background where you 00:20:20.030 --> 00:20:25.830 came from what your other strong languages were and how you got onboarded on 00:20:25.830 --> 00:20:30.470 the project and your first experiences with the code base a lot of people might 00:20:30.470 --> 00:20:38.230 be curious about you know exactly this process of working for quote-unquote a space company so. 00:20:38.230 --> 00:20:44.430 During my studies when i joined I joined a lot of projects that do things in space. 00:20:44.570 --> 00:20:48.970 So for example, one of the cool things that we did back then was something called 00:20:48.970 --> 00:20:57.170 Bexus and Rexus, which is a European project for students that allow you to do some sort of project, 00:20:57.370 --> 00:21:01.610 some sort of scientific mission on a small suborbital rocket or weather balloon 00:21:01.610 --> 00:21:03.570 that they launched from Sweden. 00:21:03.930 --> 00:21:08.030 And so that's kind of where I got exposed to my first real mission 00:21:08.440 --> 00:21:11.860 Bayes mission experience using those projects 00:21:11.860 --> 00:21:14.920 and we used a bunch of different languages though 00:21:14.920 --> 00:21:18.380 mainly C and Python and I 00:21:18.380 --> 00:21:25.020 must admit before I joined Gama and in my university days I have never heard 00:21:25.020 --> 00:21:32.400 of or used Rust so I'm kind of a late joiner in that regard but after finishing 00:21:32.400 --> 00:21:38.340 my studies I joined Gama then in January 2023 and that's 00:21:38.440 --> 00:21:42.420 The point when I started to learn about Rust and when I kind of fell in love 00:21:42.420 --> 00:21:47.540 with it because of the security guarantees that it gives you. 00:21:47.740 --> 00:21:52.020 You mentioned earlier that all of the stuff that we have talked before must 00:21:52.020 --> 00:21:54.520 have been in place before. And that's actually not the case. 00:21:54.980 --> 00:21:59.860 This is one of the reasons I got onboarded because at the time it was literally 00:21:59.860 --> 00:22:03.820 just Chris responsible for the software. 00:22:03.820 --> 00:22:10.620 And so we really needed more support in the electronics and in the software 00:22:10.620 --> 00:22:12.660 department, embedded software department. 00:22:12.880 --> 00:22:18.280 And so that's where I came in. Although I couldn't directly start working on 00:22:18.280 --> 00:22:19.520 the onboard data handling system. 00:22:19.780 --> 00:22:23.920 Well, I did some small contributions here and there. But when I started, 00:22:24.240 --> 00:22:27.800 I got assigned to a kind of a side project. 00:22:28.160 --> 00:22:33.260 So you have to imagine the satellite has just launched a few days ago. 00:22:33.820 --> 00:22:38.100 I come into the company, I get used to everyone, everything, 00:22:38.360 --> 00:22:45.140 meet everyone, and then, ah, okay, we have kind of a validation of our satellite. 00:22:45.520 --> 00:22:50.200 We want to do a zero-g flight. So that is a flight where the plane. 00:22:51.370 --> 00:22:54.530 Does a parable so it goes up and 00:22:54.530 --> 00:22:57.690 then it flies in a way so that you you cancel 00:22:57.690 --> 00:23:01.170 out gravity so you for a few seconds 00:23:01.170 --> 00:23:04.350 like 30 seconds you are weightless and we 00:23:04.350 --> 00:23:07.670 wanted to use that and develop a system to have a 00:23:07.670 --> 00:23:11.310 small scale solar sail deployed and to 00:23:11.310 --> 00:23:14.130 see how it how it behaves in COG because we 00:23:14.130 --> 00:23:18.010 they had simulations at the time but there 00:23:18.010 --> 00:23:20.770 was no practical experience and so we wanted to we wanted 00:23:20.770 --> 00:23:23.550 to see if our simulations actually match what we see 00:23:23.550 --> 00:23:27.490 in real life and so i got assigned to build this 00:23:27.490 --> 00:23:32.490 specific project and the code for it and of course because we were using rust 00:23:32.490 --> 00:23:38.610 this was also done in rust so they it's kind of it was kind of a relative simple 00:23:38.610 --> 00:23:45.890 thing we just had three motors and we were controlling a a disk inside of a box and on the disk so we 00:23:46.050 --> 00:23:52.510 were able to spin the disk and then release something that released our small-scale sail. 00:23:53.910 --> 00:24:00.850 And the main part of this was just to do this control, kind of account for vibrations 00:24:00.850 --> 00:24:05.350 of the plane because those kind of disturb the data and then record the data, of course. 00:24:05.590 --> 00:24:12.070 There was a lot of data coming in because we wanted to record as much as possible from this experience. 00:24:12.190 --> 00:24:16.810 We had cameras that captured the entire thing, but we also had various sensors, 00:24:17.310 --> 00:24:20.230 accelerators, and stuff like that. 00:24:20.710 --> 00:24:23.350 So that was kind of my first... 00:24:24.890 --> 00:24:28.490 My my foot into into the company and that's 00:24:28.490 --> 00:24:31.490 kind of also still what we do today if we 00:24:31.490 --> 00:24:36.350 if somebody else joins the company they're gonna have to get used to the way 00:24:36.350 --> 00:24:40.030 we work around here they're gonna have to get used to rust potentially and so 00:24:40.030 --> 00:24:45.050 they they usually get a small project on the site where they can they can work 00:24:45.050 --> 00:24:50.930 on it's still important to us of course and then they they kind of join the main force, 00:24:51.570 --> 00:24:56.030 like that and we have a bunch of back and forth where we because you're learning 00:24:56.030 --> 00:25:06.070 the way of how to write code not only for Rust but also for space there's a bunch of things that we, 00:25:07.370 --> 00:25:15.230 how to's that we have in the company that we've gathered over the years on how 00:25:15.230 --> 00:25:21.510 to write Rust safely as possible because unfortunately, it's still possible to screw up in Rust. 00:25:24.830 --> 00:25:26.650 Is it? Yes. 00:25:27.230 --> 00:25:30.070 So, yeah, one of the main things in the beginning, I thought, 00:25:30.390 --> 00:25:34.110 ah, it's so cool. Like, I can't get wrong with this. 00:25:34.210 --> 00:25:37.090 If my code compiles, it's perfect. 00:25:37.250 --> 00:25:41.850 And it's true in most of the cases, but some logic bugs can still sneak in. 00:25:42.590 --> 00:25:46.350 Mostly if you don't write your code in a way that prevents them because that's 00:25:46.350 --> 00:25:51.250 one of the cool things about Rust and what we use extensively here as well, if you write your code, 00:25:52.170 --> 00:25:55.570 Using the strong type guarantees, 00:25:55.890 --> 00:25:59.890 you can make it so that any invariants that need to hold true, 00:26:00.050 --> 00:26:05.250 so any preconditions that your code has and that need to be true for it to work 00:26:05.250 --> 00:26:07.870 correctly, you can express that in the type system. 00:26:08.190 --> 00:26:10.450 Maybe not all of them, but most of them. 00:26:11.010 --> 00:26:14.250 And so, for example, we use that extensively for configuration. 00:26:14.250 --> 00:26:20.270 We have things, we have code that can only run once the hardware is initialized correctly. 00:26:20.270 --> 00:26:28.250 And so we pass around serial-sized tokens, types that can only get created in 00:26:28.250 --> 00:26:32.290 one place in the system, and that's after initialization of that specific hardware. 00:26:32.570 --> 00:26:38.170 And so we use, for example, this sort of a token in other places to prove, 00:26:38.290 --> 00:26:42.070 yes, this code will only ever run after initializing that specific hardware. 00:26:43.010 --> 00:26:45.450 Couldn't you also use a type state pattern for that? 00:26:47.010 --> 00:26:50.630 Well if you do that type state pattern you kind of, 00:26:51.850 --> 00:26:56.690 You kind of make code dependent. You encapsulate the code. Not encapsulate. 00:26:56.850 --> 00:26:59.590 You make it dependent on each other a lot more, I feel like. 00:27:00.250 --> 00:27:05.090 So instead of writing a huge state machine, basically, like that, 00:27:05.270 --> 00:27:11.770 you can write your code more freely, just at any given structure that you want, 00:27:12.150 --> 00:27:14.410 just passing around these types of keys. 00:27:14.970 --> 00:27:19.330 Yeah, I never heard about that types with keys pattern, the token pattern that 00:27:19.330 --> 00:27:25.050 you described. Is that a thing that you invented, or does it come from any other project? 00:27:25.730 --> 00:27:30.710 Well, it's definitely used in the embedded world a lot. 00:27:30.850 --> 00:27:38.070 Maybe not in the same kind of way, but we've got the idea from crates like Embassy 00:27:38.070 --> 00:27:43.990 and actually various hardware abstraction layer crates that if you, 00:27:44.310 --> 00:27:49.330 in the beginning, they give you one struct that contains all of the peripherals 00:27:49.330 --> 00:27:54.950 but it's just zero-sized types for these peripherals and the idea behind that 00:27:54.950 --> 00:28:00.870 is that you can then when you want to use one of these peripherals you have to consume that type. 00:28:01.690 --> 00:28:05.430 And that prevents you from using the same peripheral twice, 00:28:05.530 --> 00:28:08.670 for example pins if you think about a microcontroller 00:28:08.670 --> 00:28:11.870 it has pins that you can toggle on or off and if 00:28:11.870 --> 00:28:14.650 you decided at one point yes okay i'm gonna use this 00:28:14.650 --> 00:28:17.510 pin to i don't know to talk to a motor for example 00:28:17.510 --> 00:28:20.230 and then later you think okay right i 00:28:20.230 --> 00:28:23.770 have a i have another use for a pin maybe i 00:28:23.770 --> 00:28:27.230 don't know i want to toggle an led or something let me 00:28:27.230 --> 00:28:32.650 see ah maybe pin one is still available i'm gonna try to use it ah no i've already 00:28:32.650 --> 00:28:37.090 used this before and rust tells you this because you moved the type you moved 00:28:37.090 --> 00:28:42.110 the variable into the function that used it and so you can't use it later and 00:28:42.110 --> 00:28:44.110 so that's that's kind of the the same idea. 00:28:44.370 --> 00:28:51.250 You have a token for each peripheral, for each pin that you can only use once. And you 00:28:51.640 --> 00:28:57.340 This is one of the things I really love about Rust. It's the ability to detect 00:28:57.340 --> 00:28:59.400 these kind of configuration errors at compile time. 00:28:59.640 --> 00:29:04.800 I mean, the compiler literally prevents you from writing codes that is wrongly 00:29:04.800 --> 00:29:09.580 configured that would be valid code just from a processor perspective. 00:29:09.980 --> 00:29:13.480 I mean, it's okay if you use the same pin for two different things. 00:29:14.900 --> 00:29:19.480 You can write to the registers and it's not going to care. But the end result 00:29:19.480 --> 00:29:23.400 is that the pin is not going to do what you want because you're using it for 00:29:23.400 --> 00:29:25.160 two things at the same time. 00:29:25.820 --> 00:29:32.280 And by expressing this notion of only one part of your program can use this 00:29:32.280 --> 00:29:38.220 specific thing via a token, the compiler can ensure that this, in fact, is the case. 00:29:39.820 --> 00:29:45.580 Now I understand part about loosely coupled components as well because I'm not 00:29:45.580 --> 00:29:53.080 sure, but I guess Embassy used the type state pattern and a lot of generics for the pins before. 00:29:53.280 --> 00:29:56.720 I'm not sure if they dialed it down a bit or dialed it back because, 00:29:58.110 --> 00:30:02.250 sometimes want to repurpose pins and if 00:30:02.250 --> 00:30:05.150 you set up your system once it's not 00:30:05.150 --> 00:30:08.190 as flexible as if you were to be able to 00:30:08.190 --> 00:30:11.370 you know change that dynamically sort 00:30:11.370 --> 00:30:19.490 of and at the same time you just use the normal ownership rules in rust to enforce 00:30:19.490 --> 00:30:23.050 the same behavior so you can still encode it in the type system without really 00:30:23.050 --> 00:30:28.510 having a lot of overhead and a lot of complexity on the on the type system level. 00:30:28.510 --> 00:30:31.730 Exactly yes we as i 00:30:31.730 --> 00:30:34.990 said we use this in a bunch of places also for example for 00:30:34.990 --> 00:30:37.750 wrapping c libraries it's kind of 00:30:37.750 --> 00:30:40.770 an interesting thing we during our 00:30:40.770 --> 00:30:44.390 Gama Alpha project we used a communication 00:30:44.390 --> 00:30:47.650 protocol called CSP and unfortunately 00:30:47.650 --> 00:30:50.530 at the time there was no pure rust implementation of it 00:30:50.530 --> 00:30:53.850 so we had no choice but to wrap 00:30:53.850 --> 00:30:57.070 well either implement the whole thing ourselves but that would 00:30:57.070 --> 00:31:00.470 have taken quite a bit of time which we didn't have or 00:31:00.470 --> 00:31:03.430 to wrap the the c library and the c library has 00:31:03.430 --> 00:31:06.490 a bunch of invariants when you use it you have one 00:31:06.490 --> 00:31:09.870 of them is you have to call a function called csp_init before 00:31:09.870 --> 00:31:12.650