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.