#29 - Operating Satellite Constellations at Planet Labs with Deanna Farago

Hello and welcome to another episode of the Art of Space Engineering, the podcast which explores the details behind how space systems come together and what lessons are learned along the way. I'm your host, Sarah Rogers, and this week's episode explores how Planet Labs manages operations for its constellation of over 200 satellites. Planet Labs was founded in 2010 with a goal to collect high-resolution imagery of the entire Earth every day.

Today, Planet's dataset includes on average 1,700 images of every place on Earth. This has provided researchers, businesses, and governments with significant insight into our Earth, not only in monitoring its climate and natural processes, but also on how we as humans are continuing to shape our planet. And currently, Planet is working on a next generation of satellites which offer improved image resolution and revisit rates.

This includes a new hyperspectral imaging satellite, TANIGER-1, which will launch this year. Mike is today Director of Mission Operations at Planet Diana Ferago. Her team is responsible for commissioning and operating the largest Earth-observing constellation of satellites in the world. With an expertise in operations at scale, Diana has written papers and presented at conferences such as the SmallSat, Grace Hopper, and the Space Operations Conference.

Prior to coming to Planet in 2014, Diana worked as a simulation engineer at the NASA Ames Research Center, performing human in-the-loop experiments in the vertical motion simulator. She also worked as the Mission Assurance Manager on the Astra project at NASA JPL, which helped to advance Mars surface instruments using a high-altitude balloon test environment.

During her time at Planet, she has seen how operations processes have grown to efficiently commission and operate a large constellation with very little operator interaction.

Now in this episode, we'll dive into how Planet Labs balances commissioning new satellites while continuing to operate existing ones, what tools and automated features enable their constellations to run seamlessly, what aspects of constellation management are not as well known as they should be, and finally what we can learn from reflecting on a decade of operations.

As satellite constellations like Planet Labs provide important everyday services for us here on Earth, I thought it would be useful to explore what actually goes into making their operations successful and what we should keep in mind as we find new needs for satellite constellations, whether that be within Leo or around the Moon. So I hope you find this episode as enjoyable as I did and that it provides some useful takeaways on the mission operations design side of things.

Now without further ado, please enjoy this conversation with Deanna for our go.

Maybe before sort of jumping into the background and everything, one thing I guess the concept of this interview sort of came up because I was thinking more about satellite constellations and swarm algorithms get better as well.

There's a lot more to explore in terms of controlling constellations and I think maybe not as massive as what Planet does, but I think there's definitely a lot of the autonomous operations that you guys do that people don't really think about when they think about constellations. And so I thought that would be a cool thing to share on this podcast and in sort of looking through everything I realized it's been like over 10 years since Planet has actually started.

So I think there's some cool things that we can touch on in this interview just with like how it's grown over the years and lessons learned from that. So I guess really like the first thing I'd want to say is just like congrats.

I remember when I was first working on CubeSats back in the 2015-ish timeframe, the dove constellation was a huge thing and everyone was really excited about just the ability to launch all of these CubeSats to do daily monitoring of the Earth and now it's like everyone's using Planet data and that's so cool. It is very cool.

I am always amazed at the number of scientific papers and research and just how much our data has been utilized across both like the academic fields as well as commercial industries and it really has so many use cases and exposes a lot of information that we really didn't have before I think. So I agree it's been really amazing to see how the product has evolved over time and continues to evolve. Definitely agree there.

Like I even like I went to AGU back in December and just like seeing all of the scientific papers there just like you were saying on like how many people have used Planet data for helping us understand more about Earth I think is so cool. And I feel like that part of the company or that part of what we do is really still so novel to me because my head is very much in just the space systems, mission operations side of things.

So what we care about is maximizing the amount of imagery that we can capture in downlink and optimizing that funnel making sure everything is as efficient as possible.

There's always going to be room for improvement and there's always a new bottlenecks or new challenges where we can further explore how do we reduce this mean time to recovery or this reaction time so that anything that happens on our fleet or on a per satellite basis like we can get that satellite back to an imaging state as quickly as possible. And if it can't go back to an imaging state let's use it as an on orbit test bed.

Let's continue to get as much utility as possible out of these satellites and exploring opportunities there. So yeah, the product side of things for me is still always very fascinating to listen to because we just don't get exposed to that as much on a daily basis. I think maybe that's kind of a good transition to a question I always like to start out with which is just getting to know a little bit more about you and your background.

So what sort of drew you to space and to planet labs and what does an average day look like for you? Sure. So I studied aeronautical and astronautical engineering at University of Washington and I think the reason why I went to this field was first off space is so cool. Everything about it I just think it's the problems, the challenges, the idea that we were able to put humans on the moon given the level of technology we had at that time.

It still blows my mind and I think I get very motivated when I sense that, I don't know if it's a good way to say this, but here's an example. So I'm very inspired by my mom's journey. She immigrated from Vietnam as a refugee. She came here when she was 19 years old and really didn't know any English and she became a mechanical engineer and worked her whole career in the field.

She was a working mom and so I have always been inspired by how she was able to overcome so many challenges and to never let things hold her back. And so I think I wanted to go into this field because it's hard and I wanted to prove to myself like nothing is too hard. This is, it's just really fun for me to solve hard problems.

When I graduated, I went to work at NASA JPL for a few years and then I came up to the Bay Area and worked at Ames Research Center and as well as in the Bay that I became reacquainted with someone I knew from JPL who was working at Planet at the time. So through him, I came for a tour and I was just so amazed at the pace, at the, you know, just the vibe of happening in that office. It was just so different from everything that I experienced up to that point in my career.

And a couple months after that, I saw a job description on their website that sounded really interesting and so I applied to be a spaceship captain, which was the title of the job at the time. And since then, the whole time I've been at Planet, I've worked in mission operations. I really love it. I think you have to understand so many parts of the system.

So it has that aspect of like a systems engineer type role, but you also have to think through a lot of implementation and execution of tooling and creating, you know, metrics and doing analysis. And it's just a very complex job that no matter what part of it you're interested in or if you have like a specific interest in a subsystem or a part of that operation, you're able to dive into it. So I think that's what's really, that's what drew me to my job specifically.

And to Planet in general, just the mission itself, I was very inspired by. It was more of a, if you build it, they will come, I would say in the beginning. I don't think, you know, it was very theoretical and everyone was very optimistic. When we have this product, people will find it useful because no one was doing it, you know, at least to that level. So yeah, it was just a really exciting time to join the company and to get that to production.

No, I think that's just a very beautiful and inspirational story. And was it that job, there was really called Spaceship Captain, that's wild. That's so cool. I know, I still have some business cards that say that just so I could prove to myself that really was my job title for a while. Yeah, that's awesome. Yeah, I think, I hope that they didn't get rid of that or if not, they should bring it back. I agree. They should bring it back.

Yeah, I think over the years, you know, we, the team grew and we wanted to make things more consistent across all of the operations teams. So unfortunately, that's no longer a thing, but who knows, never say never, it may come back. We still have some meetings that are called captain's meetings. So it's still in the culture. Okay, well, if you need a vote from outside of planet, I will happily mass email anyone. Thank you. Just bug them to death.

I can imagine too, from the operation side, just thinking through more of how things work, I feel like that's really how you do get to know the system at the end of the day is, like, okay, well, what do these things actually do and what commands do you send and then what are the nuances associated with those kinds of commands? Do you, because I know planet has been sort of expanding to incorporate other types of imagers like hyper spectral.

So do you get brought in sort of at the design phase with those as well to kind of help, help incorporate lessons learned too? Absolutely. Yeah, and I think, depending on the subsystem, to the degree, and very, but we absolutely incorporate our lessons learned into our new missions. And it's really exciting with the tech demo that flew late last year because this is a brand new bus, a spacecraft bus that's going to be flying different types of payloads this year.

And the bus development, you know, operators, we've been involved of, I would say, for the last three years, really building out the requirements from the con ops level, you know, the concept of operations, determining, you know, how do we meet the requirements of the product and the mission requirements, and this is how we expect it will a day in the life of the satellite would look like.

And then from there, deriving the subsystem requirements, and they've changed, you know, since the original design, but operators have definitely had like input in a voice along the way. And we helped to validate the system, the months leading up to pack out of our tech demo last

year, we were running end to end tests with mission control in the loop, making sure our scripts were going to work out the gate, that we would be able to update flight software in the first day, and that all of those operations were de risk as much as possible. And so, and we still manage the most flight like test bed on the ground to make sure that whatever we're going to do on orbit, we feel confident and have tested fully on the ground first.

So, yeah, I think I can't really say compared to operations at other companies, but I do feel like we are pulled in very early on for these project life cycles. Oh, that's really cool. And this is the Pelican one tech demo. Yes, that's correct. So you guys are in the commissioning phase of that right now.

Yes, that's correct. And I would say for a tech demo, the commissioning phase can, you know, go as long as you wanted to because we are really stress testing the system, we're trying to learn as much as possible as quickly as possible to fold those lessons into the next build for when the next Pelican launch. So commissioning has been going really well. We're updating flight software like on a daily basis, both for like bug fixes of things that we've learned along the way.

So those are treated pretty like urgently and high priority depending on the flavor of it. And meanwhile, also doing flight software updates for things that were already on the developmental roadmap. So that team has a lot of like priorities. They have to juggle that get decided with us and with other subsystems depending on, you know, who all the stakeholders are. But when we launched the tech demo, you know, we launched hardware that still didn't have

the software to support it. So we're kind of like building the ship as we, as we, you know, fly it. And it's really exciting to be able to do that so rapidly. But it can also be, you know, stressful because there's a lot of unknown unknowns and you want to continue to progress down this developmental roadmap and not get too distracted by, you know, the fires that might happen along the way. So it's a dialogue and we've made a lot of progress along the way so far.

So I guess this wasn't the direction that I was planning on asking questions. But now I'm curious. So if I'm allowed to ask. So this is the Pelican one tech demo is meant to upgrade the SkySat constellation and provide just higher resolution, faster rate visit rates. This is, is it visible or it's not hyper spectral? It's not hyper spectral. That's correct. Yeah. The hyper spectral mission is Tannager, which

will fly on the same bus as Pelican. And that's a new product for us. We currently don't have any hyper spectral imagery, you know, coming from our doves or SkySats, but you're correct. The Pelican fleet will be what eventually replaces the SkySats when they reach end of mission.

So like, I guess, since you guys have the existing constellation, what is, if you're allowed to say like, what's what's so new about the underlying software to where you guys are having this sort of do more of a tech demo and this like rapid software upgrade?

Yeah. So the SkySats, when they became part of planet, so planet acquired Karabella and along with it, the SkySats, Leeds and the people who operate them and, you know, along to and I believe the SkySats were actually delivered to Skybox and Karabella by Space Systems Laurel. So they were built out of house. And the Pelican bus is all designed and built in house. And we needed to, you know, find a way to eventually like replace

and improve the SkySat fleet once they deorbit. So this and creating a common bus was also a benefit because we were able to see other opportunities to fly, you know, external customer or partner payloads. So Tannager is a partnership with Carbon Mapper and JPL. So there was a lot of like overlapping, you know, benefits and requirements that we could see across both of these missions. And that's how the common bus kind of came to fruition. And

in terms of what we gain, you know, the initial Pelicans that we launch will, they should be like a product. It should map like one to one with SkySats. But then over time, like we have the ability to improve that resolution further to also have additional technology

on board to have very rapid low latency and tasking and downlinking. So there are some, yeah, there are some capabilities that the SmallSat bus has that SkySat currently do not, which will open up a lot of opportunities on the product side. Oh, that's so cool. I didn't, I didn't actually know that about the Pelican missions. So that's, that's awesome. I know it's like, it's always hard to like manage things when they, I guess

when things overlap. So that's, that's cool that that's working out very well. Yeah. And, you know, we're, we're going to have to explore that scenario with the Super does as well. They're not, you know, nearly as close to end of mission as the SkySats. But we need to have a continuity story there. And, you know, do we use the same bus platform? Is this still going to be a CubeSat? Are we going to use the common bus for those, for

those Sats? Like it's, there's a lot of trades that are happening right now, but really the difference between the Doves and, you know, what will follow is originally it was more capability driven. And then now we're very much more in like a product driven design phase.

Maybe to transition next, since we're talking about commissioning for the tech demo, I think, I think it would be cool to maybe first start off by giving an overview of what a typical like day in the life looks like for the commissioning phase, maybe looking at sort of the, the Dove constellation as an example. So like say when, when a, when a flock of Dove satellites are deployed and they enter this sort of early checkout or commissioning phase, what does

that look like? What activities are going on? And then how do you know when you're ready to transition to sort of nominal mode operations? Yeah, great question. So when we launch a new flock of Doves, we already have existing Doves on orbit that are in production, that are utilizing, you know, ground station time and contacts. And then all of a sudden we have a new set of Doves on orbit and they're all clumped together really tight. So they're going to be competing with one another for

the same ground station accesses as well as with, you know, production fleets. So the way that we manage that is we will target only a subset of the set. Initially we actually have a two to three set that we call our canaries. And we push those through commissioning as quickly as possible just to make sure there aren't any issues that we weren't able to see on the ground. At this point, like, there's nothing new that should be really showing

up with canaries. But they give us the up, we purposely choose the canaries that are at the beginning, middle and end of the deployment sequence so that while we're talking to each of those canaries in any ground station contact, we will also be asking, hey, how are all your

neighbors doing as well? And we will get like basic health telemetry for all of the, essentially all of the sats from the get go so that we know, okay, there's no, there's no single sad that is particularly, you know, low power or, you know, tumbling at high rates, or we can't communicate with any particular satellite. So it's just an initial like sanity check, okay, everything is good. Let's just proceed with the plan. The canaries go through commissioning.

And then after that, we start kicking off our batch of sets to do bus commissioning. And this is all automated. So we will have the list of hardware IDs that we want to progress through. And the commissioning automation will tell the satellite to detumble, then deploy its solar panels, we know it's in a good power state, and then it will start scheduling more high powered activities that require additional CPU power or turning the payload on. We'll

be doing, you know, GNC calibration activities. And once all of those calibration activities are done, then we achieve first light and we will turn on the camera. And because we've already gotten all of our calibration activities out of the way, the first images the satellite downlinks should already be customer quality images. And the automation essentially only will actively commission like five to 10 sets at a time, depending on the number that we

choose for that flock. And that's how we manage round access contention between the commissioning sets and the production sets. So there's never any large surge of resource fogging, essentially. So once the satellites are all imaging, then we will enable differential drag on all of them so that the differential drag is essentially how we start getting the satellites out into a more equidistant position around the planet. And it's done by orienting the satellite in

either a low drag or high drag configuration, while it's not imaging or downlinking. So basically when it's just in a background mode, not doing anything actively, we will set its orientation to low drag or high drag. And that schedule is calculated and maintained by our orbits team. And so over time, all of the satellites will start spacing themselves out. This will reduce ground station contention. It will also increase the amount of unique

imagery those satellites are producing. But I think your question was, at what point do we say they're like production ready? I would say it's once the imaging team has signed off, the satellite is whitelisted. And what they do is make sure that the satellite imagery looks calibrated, looks like it's within the range that is expected for customer specifications. And then they're whitelisted. And then all of the imagery that that satellite had been

taking since it started imaging will be retroactively whitelisted too. So all of those images will be put into our catalog and accessible to our customers. Okay, gosh, so many follow up questions. So maybe to start with the like, so if you're deploying, because Fox are usually, they're usually about 20, correct? They've really ranged. Yeah, we I would say these days, they're more in the 30 to 36 range. Okay. 24 to 36.

Okay. So you deploy all 36 at once. And then, you know, all 36 sort of start autonomously detumbling. But then you start commissioning about 10 at a time, while the other ones are just kind of chilling. And that's sort of like all automated, you're just focusing on like a small subset to make sure that they're good before moving to say like the next 10 in the sequence. Yeah, so it actually used to be that way, but we would do like 10, and then move to the

next 10. Now it's much more fluid. So as soon as one satellite is done, then it will automatically put one satellite into the into the active rotation. So it's much less like chunked out than it used to be. Yeah. Oh, interesting. Okay. And so that's just managed by all of your ground tools that you understand, like where the satellites are. So it has the the TLE of that spacecraft and how to communicate with it. And then it kind of just puts the next one into the queue.

Exactly. Yeah. So our operational scripts will know what state of commissioning the

satellite is in, and it will record that state on the ground. And so every time it talks to another satellite, it knows exactly like, Oh, okay, this satellite should have just de-tumbled. So I'm going to check on how the de-tumble went and what its rates are. And if it looks good, I'm going to move it to the next state, which is deploying its solar panels. And then the next contact will run. It knows that the panel deploy activity executed

and then will follow up and follow and check whether that was completed. And then once a satellite is past panel deploy, then we will actually put the new a new satellite into the queue to start its best commissioning timeline. So our the purpose is really to get all of the satellites to a panel deployed state as quickly as possible, so that we can minimize the risk of potentially getting into a tumbled orientation that puts us in a power negative

state because it has happened. The, you know, it's it's low likelihood, but it always requires like an operator to intervene and like, you know, take manual action and do things a little bit out of order. And so it's not ideal. So really, getting all of the satellites to a panel deployed states quickly as possible just decreases the chances that that will happen.

Gotcha. One other thing I wanted to ask about too was, and this this touched on one thing I remember reading in the one of the papers on the the planet operations and sort of ground architecture was a tool that you guys use for communicating with the satellites once they're deployed because like as they're passing over the ground station, like they're all very close together. And so you but you still have to target like, you have to know which TLE

belongs to which satellite and you have to target like that specific frequency. And sort of making sure that you have the right TLE and the right spacecraft parameters is it's kind of a it's a difficult part of like the early operations because you know, the TLE might be wrong, especially if you were like very lumped together. So when you're saying that you also talk to all of the neighboring satellites within that deployed flock, are

you guys using that tool to in order to do that? Yeah, so we should have pretty accurate knowledge of where our satellites are in relation to each other using ranging data. And that's what we we target is is is knowing, you know, which satellites are within the beam with that we could communicate with and then requesting health telemetry from those hardware IDs. And as long as they're within our, you know, communication beam with, then they should respond to their

hardware ID command. And that's how we can then also reaffirm like, okay, we we know where this satellite is, and and it's in a healthy state. Oh, gosh, yeah, that was, I guess I've had like one keeps that operation story, which when our when our keeps that deployed, along with 10 other keepsats from other universities, we had there was one keeps that that was on the same frequency as us. And we were having issues communicating in the beginning. So like, we were having a hard time hitting the

TLE on our spacecraft. And then we would get telemetry and we think it was ours. But it was the one from the other spacecraft. So it was so yeah, so I like I think because this is you're referring to the mega health app. Yeah, okay. Yeah, so it's a task that we ran called mega health.

Yeah, I love that name too. But yeah, when I when I read that, I was like, that's so useful. Yeah, it was very useful because it also meant that we didn't have to have just a one sat per contact allocation to get information. And especially when we were commissioning like 88 sets, we did not have the number of contacts to be able to get through everything like it would have taken weeks for us to just hear back from each satellite. So this is

essential for us to get through that commissioning phase. And your story reminded me of one of our stories where I forget which launch it was. But I think we were launching with Aspire as well. And after a couple of days, like, we still couldn't contact one of our sets. And we found out that Spire also couldn't contact one of their sets. And it turned out that their satellite their lemur had ended up in the middle of our in our of our flock.

Unfortunately, our satellite was not in their orbit. So our hypothesis was that it was stuck in the deployer. Because we we spiral searched everywhere for that satellite. And we couldn't feel confident that it was it was actually deployed. So but it was fun that we found the lemur in the middle of our doubts. Oh, wow. That's wild. I wanted to add a quick aside on the TLEs just going off of my last statement since

I didn't really relay our experience on Phoenix in the right way during the interview. And so there's a few things I want to correct there. For those who haven't heard of this before, a TLE stands for two line element set. This provides information on spacecrafts ported to velocity. Now before you deploy, your spacecraft is assigned an ID which will be linked with the TLE information. If you're part of a deployment of multiple satellites,

then this is tracked in the order of when you deploy. So you would say, okay, the first satellite in the deployment sequence will have this ID. Second one will have this ID and so on and so forth. Now in general, TLEs are pretty accurate on the first deployment, but you still need to confirm that you can talk to the satellite and that your TLE has

the right information. Now, however, if you have issues contacting your satellite after deployment and other people are also having difficulty in confirming this TLE can become very difficult to do early on because the satellites are still going to be very close

together. So on the operation side at the ground station, what you see when you're looking for these TLEs is that a certain TLE is going to pass over your ground station at a given time and then you use that to identify which ones you want to prioritize studying and trying to figure out if that belongs to your spacecraft. And so sometimes early on, you know, TLEs can

be right on top of each other as satellites are still close together. So you can try one and it may seem like it works, but there might still be a little bit of gray area there. And in addition to that, since you only get a couple of good ground station passes each day, if you're just using, you know, your own university ground station, then it can

take a while to cycle through all the ones that you're trying to try. Now, after a while, the spacecraft will start to drift apart in the orbit and the TLEs become much easier to isolate and figure out which one actually belongs to you. Now, to tie this back to the personal story that I was trying to tell Deanna, now when Phoenix first deployed, we were able to see a heartbeat after 30 minutes of deployment when all of our hardware was activated and

we had this automated health beacon just transmitting out. Everything looked healthy. We were very excited to see all of the telemetry. But after the first day, we ended up having a power anomaly that we still were never able to fully explain. But the upshot of that is that our computer stopped responding. And so our regular health beacon was no longer coming out and we weren't able to send commands to our computer that would request additional information.

Now, eventually we started trying commands that were very specific to our radio, which was working, and actually responded. And that was the process that we used to actually confirm

which TLE was ours. But prior to that, we were just, you know, we saw that a particular TLE was coming over our ground station, we would pick it, we'd try some commands, hear nothing, maybe try it again the second time that it was going over our ground station, and then say, okay, you know, maybe we should move on to another one that is still unconfirmed

to be with the satellite. So due to all of the issues that were found, you know, not only with our own satellite not communicating, but with other satellites in our deployment not communicating, it took us quite a while to actually confirm our TLE. And during that process, it was really important for us to communicate with all of the other CubeSat teams that deployed satellites to understand who had actually made contact with theirs,

and which TLEs had not yet been identified. And I think that email thread was actually initiated by one of the other CubeSat teams. They'd asked for points of contact for different universities to get in touch with them, and to start that kind of tracking thread. So I don't know if this is different now and more coordinated, but at least back when we deployed in 2020, this was not something that was initiated by, say, the launch integrator

or other folks from NASA who were coordinating deployment. Now, I don't want to tell the story to make people nervous about operations for CubeSats or feel like this whole process is not as coordinated or as robust as it should be. It certainly was very different from what we expected. It was not something we predicted and not something we planned for as a result.

But in looking back through some of my old information and emails on this topic, I think the TLE identification for our particular batch of CubeSats was much harder than it typically is for CubeSats being deployed. And I think this was really just due to the number of issues that people had experienced in making contact with their spacecraft. People did remark to us that it does not usually take several weeks to confirm the TLEs of all of the satellites

from a typical like NANORAC deployment. So I think this was a bit more of an anomalous situation. So I hope that doesn't sway anyone from getting excited about operations as well. There's just

a lot of really excellent work that goes into this kind of TLE identification just for maintaining space traffic management and really trying to help you make contact with your satellite after it's deployed. So I wanted to sort of set this stage right with addition to the story and just make sure that none of that work is underscored or that this came off in a wrong way. Ultimately, doing this whole process to confirm the position and health of each satellite in a

constellation requires a lot of careful planning and execution. It can be difficult to do manually. It's very time consuming to do manually. And the ability for planets, mega health application to just cycle through all of that information quickly to identify any issues with the satellites is just incredibly enabling when it comes to early operations for large constellations of satellites. So anyway, that's what I was really trying to relay and explore a little bit through this part

of the conversation. But in sort of post-editing, I didn't really feel like I executed it quite well and certainly not in the way that I had intended to do. So hopefully this, you know, addendum kind of shed some light on the experience that we had, operations in general, and what issues you might see and should plan for. And so with that tiny story out of the way, let's get back to the episode.

Okay. I, to make sure we have time for it, I want to ask more about like looking back on how planet has developed over the years, given that the company has been launching satellites for over 10 years and you've been at the company for, you know, basically for kind of the whole. Almost. Yeah. Yeah. A little over nine years ago. And when I joined, there already around, I think just about to break 100 people. So, yeah, we had, you know, teams already kind of established,

even if a team was just one or two people. But I think there was already like a good group of folks up in it. I guess within your time at Planet, what are a few things that you've, you know, admired about, you know, maybe the company and what you guys do just having seen it grow so much over time? Yeah, that's a great question. In terms of admired, I think a big part of why I've loved my job is because of the people I've gotten to work with and work for. I think, you know, like many companies,

the culture is really dictated more on like a micro level. There's a company wide culture, but I think the things that impact you more on a day to day basis is like your relationship with your manager and your manager's manager and the team members that you work with. And maybe it's just because of the nature of our work, but there's always, it's always been really valuable to me,

like the level of trust that our team has with one another. And what I admire about like Planet's journey over the years, I would say is we've really tried to be introspective and retrospective along the way and to not make like the same mistakes over and over again. That's not to say we haven't. Like we're still, you know, kind of repeating things that may be like, oh, we could have avoided that we knew better. But I think we do actively try to

learn from what we've done before, both technically, but also like culturally. So looking back over the nine years I've been at Planet, I can almost see like eras or like phases that we've been in, depending on who is in leadership or how mature our product was, you know, what companies were, did we like recently acquire and we're like working through the kinks of, you know, that transition, what satellites were we flying, because we've already had, you know, we retired rapid-eye

satellites several years back and that was through the acquisition of Blackbridge and then, you know, evolving Doves to Super Doves, like that was a big leap for us. So, yeah, it's been fun to look back and see like the different phases of at least the technological roadmap and then also how the company has gone from private to public and handling that rapid growth as well.

No, I definitely agree with like, nope, had I thought lost it. No, I think that's awesome and especially like sort of going back to, you know, working with different people over different time periods and just kind of seeing how it evolves. That's just really cool.

I don't know. I feel like when I look back on like long projects, it like, things just feel very long, but it also feels like the right things happened at the right time, you know, like stars aligned or something to where it just things fell into place nicely and they like,

and then when you think about it more, it's like it, it was building up to that for a while. It, I don't know, it just wasn't like always apparent or something, but. Yeah, definitely. I mean, it's, it's a little, it's up and down, right? Like, sometimes you feel like you're kind of in the bottom part of the sinusoidal graph and

it can only get better from here. And, you know, the company has had to make a couple course corrections over the years where we, you know, we've been doing a lot of research and we, you know, unfortunately had layoffs or had to do like big pivots to realign ourselves with the business strategy. And those are, those are tough periods for sure. But then immediately following is really like, I think periods of us rallying and getting much clearer direction

on where our priorities are and are able to really forge ahead after that. So I've definitely felt those like those lulls and highs along the way and appreciate that I've been around to be able to see them really and to celebrate the successes that we've had. Maybe as one final question before we have to sign off, are there, well, maybe this is too big of a question. So I apologize.

But I think one thing I did want to ask was like, you know, are there sort of general, not principles, but, you know, either other tasks, things people have to consider or issues that aren't just, aren't very well communicated with, you know, having to manage large constellations that, you know, like if you were to give advice to people who, you know, maybe wanted to start a company with large constellations of satellites, like that they

should know about but aren't really widely communicated, I guess. You know, I think for us, we've really benefited by knowing from the get go that we would need to operate a large number of satellites, a scaled fleet with a small number of

people. Like our operations team would not be scaling at the rate of our fleet and knowing that from the get go, like you don't waste any time automating things out or really thinking through your risk posture and what the satellite needs to be able to handle autonomously versus something that just needs to be commanded from the ground and having controls for operators to

really advance that con ops, right? So allowing operators to have the ability to configure things on a per se basis because they're all going to be special even though they're all the same. They will find ways to be special and operators will need to account for that. So making sure making sure your tooling enables them to manage all of those idiosyncrasies.

Yeah, and I think especially as these mega constellations common board that are like 10x of what we have, it's really being good space neighbors and sharing as much information as you can with one another about your conjunction management strategies and your processes, workflows and where your thresholds are. It's something we're continuing to try and be better about and helping to standardize good practices if possible. There's a lot of companies

and a lot of people that care a lot about this as they should because it's something we need to take really seriously. And that's part of why our small sat common bus has propulsion on board because it just further allows us to have more control authority and the ability to maneuver if we need to for conjunction avoidance. So yeah, that's something to definitely build into your overall mission design is how you're going to manage that. I think that's a perfect note to end

the chat on before as we're reaching the top of the hour here. So yeah, no, this was super fun. I really admire Planet and it was great to just hear more about how you guys operate from a day-to-day standpoint and even just reading all the papers. It was fascinating to understand all the things that you guys had to think about and the tools that actually make what you're doing possible essentially. So yeah, I really appreciate your time. Thank you. Oh my gosh, I really appreciate

you reaching out and really doing all the research ahead of time. I mean, that's a lot and if you're ever in the Bay Area, let us know. I would love that. I would geek out very hard. So anytime. Anytime. Thank you all for tuning into this week's episode of the Art of Space Engineering. If you want to learn more about Planet Labs, you can visit their website at planet.com. If you're interested in learning more about the mission operations at Planet and how this is automated, links to the

key papers that we were discussing are linked in the show notes as well. You can find other resources by searching for Planet Labs in the Smallsat conference database. That's my goal to make the content on this podcast as wide ranging and focused on processes that are useful to engineers, both young and experienced. And that being said, if you have any questions, comments, or ideas for future episodes, please feel free to connect with me via email or LinkedIn and you can find resources

for both of those in the podcast description. And if you've been enjoying this podcast and you want to support it, please share these episodes with your friends who might be interested in them. And don't forget to follow this on your favorite podcast source to get notifications on upcoming episodes. Here's looking forward to future adventures and the lessons learned from them. Cheers, Sarah.

Now, since this interview was limited in time, there were a few tools and general facts about the way that Planet manages operations that we didn't quite get to discuss here, but that I wanted to include for the reference that needs to be described in detail in a few of the papers that I linked in the show notes. So a key resource in scheduling is the Contact Allocator and Schedule Optimizer tools. The Contact Allocator runs alongside of schedule optimizers to distribute

contacts amongst all of the ground stations. The tool signs a priority to each satellite and then uses this to assess the right cadence of ground station passes. This also runs every few minutes to react to any short-term changes in a satellite state of health. So for example, image downlinks are given a very high priority, but if anomalies occur, then the tool ensures additional passes are scheduled to assist in troubleshooting and resolving the anomaly, and that anomaly management

is handled a bit more manually by the operator. Speaking of anomaly monitoring, papers also discuss their tool called Autobot, which monitors a four anomalous situation such as the bus voltage, unexpected tumbling, and the terms of the satellite needs to be placed into a safe mode, which is then autonomously scheduled and handled more manually by the spacecraft operator. In addition, a tool called Sequencer was developed to help with automating the ADCS calibration,

which is previously very manual. And this autonomously takes the satellite through different types of maneuvers and then checks that the Adarchy Control System handled them in the right way. And so this allows the team to assess any issues with, you know, maybe software or hardware that has happened on orbit and just make sure that the satellite can

perform all the maneuvers that it needs to to support imaging. With all of these automated processes in place, commissioning a fleet of 40 spacecraft takes, you know, essentially two weeks time and can be done effectively and safely compared to having to take well over a month. And so, you know, I think this really just speaks to a lot of the very hard work and dedication that has come out of the team at Planet to just be able to actually perform all of this for large

constellations. So I think that's very cool. I just wanted to make sure that all of that got in there in addition to what Deanna and I were able to talk about.