You hear me?
All right.
So, my name is Ricardo Delphin.
I will be giving me a talk today on production
and anything wrong when you have no choice with basal.
Before I get started, just a little bit of background on myself.
Mainly work previously as a production engineer
and a variety of fields, starting in servers
and moving on to robots, be it autonomous vehicles
or at the moment humanoid robots.
So, a lot of my work has been around.
Has been dedicated around production,
izing systems, getting them working on real deployments
and getting them out in the case of vehicles on the road
to actually turn them into real products.
So, with that in mind, I've got to start it.
So, why do you pick Ross, right?
I assume given the amount of talks on Ross who've had here
most people here, you have used the Ross,
you were familiar with it.
And one of the bigger reasons why people lean towards Ross
and the next perfect sense is it's a very standard tool
to use in robotics research.
It's very easy to set up.
You can just compose things, you add more nodes,
you add more things you're launching and things
just kind of work out of the box, right?
It's a very valid reason to use robotics framework like this.
However, it does have a few issues, a few caveats
that can cause issues when you're going into production,
especially some of the big issues you sometimes see.
I mean, this is a personal gripe,
but the package is the primary deployment mechanism
I think can be a bit of an issue.
You're tied to specific Ubuntu releases.
There's of course ways around this,
but as a core, this is kind of what you're centered on.
There's, you know, I think we've all found
non-deterministic bugs at some point in Ross.
You know, I've, I've myself encountered multiple times
issues with shared memory topics
and when you're working with different kind of components.
You know, a lot of this can cause issues
once you're actually deploying kind of a large set of systems, right?
Now, unfortunately, sometimes you don't have a choice, right?
Like, you come into a company,
there is a system.
It's been built in oftentimes
rebuilding a thing from scratch.
It's not a good idea, right?
It's just not a reasonable thing to do
and can be a waste of time.
So what, what you want is you want to find a way
of working with a system you've got, right?
So some of the things that I generally recommend
when you're looking at how to kind of improve a system like this
is for something that you want to have clear dependency definitions.
You want to have some form of build isolation, right?
Something that actually gives you her medic builds,
something that gives you portability and makes it easy
for you to move your system from one thing to another.
And to add new architectures as you go, right?
And the build isolation can be really important.
And this is where basal really comes in
and shines quite well, right?
So you can absolutely use basal with Ross.
I will be basing my examples off of this
good hub repo that I made.
Just a couple small examples.
You're welcome to look at the,
pause them page to, you know,
this lies in everything are there.
So you can absolutely use basal to build Ross.
My recommendation at the moment is to use this set of rules
by Melan Vukov, fantastic.
They work really well.
There's other ones like Open,
the apex AI has their own set to do
very similar set of things and a bunch of other ones.
But the key thing here is that this lets you do things like building
Ross from source and have no working launch files
and a bunch of other features, right?
It makes your build independent from your Ross list,
it limits this to you because you're just building from source.
And you can do other things then with basal
to improve permitticity, right?
It also kind of limits this set of actual system dependencies you have.
So just to show you what that actually looks like
when you start writing code.
As you can see here on the left,
this is your basal rules.
So you basically just define a binary,
put in your dependencies, our CLCPP is there.
You add a, you can do similar thing with Python.
You can define Ross launch files
and you can see a Ross launch part here on the right.
It looks very similar to what you usually expect.
The only difference is this executable name.
The repo has some examples and how to do that
or the rules repo has some examples.
I do have a video if you want to look at this on line,
but you can essentially just do basal run,
start the node, start a launch,
and just have it running.
And it's quite quick to set up
and it gives you a good baseline to work with, right?
But this doesn't give you immediate hermitticity, right?
And it doesn't really isolate your environment.
It doesn't isolate your run environment entirely.
It just gives you a base to build things on.
So once you're actually deploying,
you've got a lot of options,
and the simplest is just using containers.
This is what I will recommend.
Most people do as their first instance.
Just if you have nothing,
just deploy on a container.
Because this will take you from having,
you know, running on your bare system to just
running in something that is isolated
and where you decide what devices you're actually talking to
and what you have access to, right?
It's very easy to set up.
And the nice thing is you can also just make it run at Boots, right?
One of the common issues with the loss
when you're deploying into real systems is you
need to find a way of making it run from Boots.
And just the easiest way is you can get a container
and put a system to service around it.
I recommend this two set of rules,
rules of CI for building a Docker containers in basal,
and rules of this tool list for using the
Docker containers when setting these up, right?
So you can see right here,
kind of example, what that looks like.
You define a tarball.
You include all the run files.
So the run files here being,
both the binary that you're running and all the dependencies
that come down from underneath it.
So this will generate a tarball.
You just slap them on an OCI image.
I based it off of,
it's basically just a bunch of 20204 image
with a couple of system libraries installed on top.
And then you just have this OCI load thing.
That just lets you load it into your Docker environment, right?
And again, feel free to look at this video offline,
but you can just do basal run that target
and suddenly you've got a Docker container that just works, right?
Another option you have is the point things
by a packages, right?
So this is going kind of back to WMPackage to a degree
but separating it out from your distro.
Basal also has in rules package a bunch of things
for building the deviant packages.
And much like before, you can just figure out a way
of doing system deployment by setting up system D service, right?
And so that's what you're seeing here.
You basically have your same package tarball
with all your dependencies here.
You set up a system D service,
like the one here on the right.
And then you just define a package, a deviant package, right?
And it'll tarball everything up.
You can even define the post install and pre-remove scripts
so that you can set up the system D service to start and run.
And that basically just works, right?
So this is again something that I really recommend you try out
if you haven't really done a lot of work deploying
raw-son systems and you're trying to figure out
a productionizer here, a robotic system.
Another option you have is deploying with images.
And I think this is kind of a very common next step
that you go, right?
So at some point, you will encounter the issue that your drivers
on your robot are kind of different across different robots, right?
Like someone maybe has some scripts that they run on the robot
to install some random kernel packages that install
the camera drivers for DMSL or whatever.
And someone forgot to install them on the next one
or they have a different version.
A very common recommendation here is instead of trying to do that,
manually try to check everything into your repo,
set it up as an image that you generate,
and then flash that image.
That way you kind of have your own custom,
almost cost them operating system, right?
Yachto is a very common way of doing this.
So it's definitely one of the ways I've seen it done the past.
And what you can do is you can build this Yachto base image,
generates a sisterute, which you then pass on to your basal build
so that you're building off of exact same libraries
that you're actually using to deploy on your robot, right?
You can use a bunch of other things as well.
Like, I'm desktop, I'm even, again, rules distorless.
Let's you export out a tarball.
So you can use that as a sisterute or as a component in an image, right?
Which is basically what part of what this is kind of showing.
You can layer up a bunch of different components from the
Docker image right here.
Kind of a distor almost to the run files for your Python environment
as well as for the actual image, right?
So once you pull that in, you have a tarball,
and you can set it up however you want.
You can set up a .img file.
You can put a slap on a bootloader on it,
and then suddenly have something you can just flash on a robot.
And it's going to start up in your conversion, right?
So now you've got an image.
Maybe you've got some deviant packages on top,
containing the actual robot components that you're setting up on this robot.
How do you deploy this on a system that's on the on the road,
or in someone's in a customer's warehouse,
or wherever the how you are deploying these robots, right?
There's a lot of OTA solutions over the updates that you can use.
This is one of them, and it's quite a common one.
As we come in robotics, you can find plenty of others,
but I've personally worked with this one in the past.
But what you want to look for in one of these solutions
is something that has the basic deployment capabilities
and a very common thing you want with this is AB partitioning
so that you can deploy two versions.
And when you do an upgrade, if an upgrade fails,
it switches you back to the previous version.
You want something ideally with modern health checking.
You can do it by the same solution, or separately.
And remote access to this is something that you're able to do
in your specific deployment, right?
So Mender does provide basically all of these.
It makes it in a way that's easy to configureable and changeable.
So it's definitely a solid option for where you're looking at
doing OTA updates.
With that in mind, that is my final slide.
So I want to say thank you.
If you want to, all the slides are going to be uploaded
in the, in the Boston page, but yeah, enjoy.
Thank you.