OK, so now, next talk, Francisco Martin Rico,
on Francisco Miguel Moreno, the University of Rejoin Carlos,
and I'm going to talk about isinab, which is a cool new,
alternative to NAF2.
Thank you.
Hi everybody, we are very happy to be here
and represent in a good war, isinab,
in our first, first time we are here,
and it's amazing, here.
We are in the leading role of this lab,
and we are going to talk about the University,
and we will talk about the products we play with.
Well, I'm going to talk about the University,
and the leadership of the leading of this lab.
I was curious, and I'm going to tell you,
I'm going to talk about the first two,
I'm going to talk about book,
I'm going to talk about the first two,
and I joined the lab like three years ago.
I haven't done many things in my life,
because it's been a bit shorter.
Right now, I'm sorry.
I am less experienced.
Right now, I'm just trying to keep my kid
have as green as his, which is a very, very difficult task.
Yeah.
I am also after off-road two-planning system,
cascade-like cycle,
spaces two, and many other packets in my.
Some introductions.
Okay.
We are going to talk about robot navigation.
It's a fundamental skill for mobile robots.
I think it's more complex task that a robot has to do.
It's not solved.
So many people say of their navigation is solved,
and the eighties, no, it's not true.
And if you say that, you have never make a robot navigate.
So, a great flag.
And until the open-source framework appear,
before that, every time you have to navigate with a robot,
you have to develop your own navigation framework,
navigation system.
Probably it dies when the project finished,
when you change the robot, you have to implement it
until it rolls up here.
Because we rolls.
It was the first time a framework like movies.
It was the navigation framework for, for, for, for,
a make navigate thousand of robots in hundred of companies
and universities around the world.
This is the famous marathon that they did in 2010.
And after that, when Ross Chu appear,
Steve Masiski decided to do a really sign
a representation of base called,
that many of you know.
With practice, in Ross Chu, many components,
very reliable.
And well, this is the famous marathon Chu.
I am one of the author of the,
I am one of the two reference paper,
so I am a contributor.
And actually the marathon was carried out by a laboratory
in the world of universities that is Madrid in Spain.
So this is like, not too looks like.
No students were harmed during the experience.
Yes.
Yes, it was, uh, Ultramarathon is 22 hours navigating
without stopping the robot with an emergency stop.
And it was 80 kilometers in around three, three days.
Okay. All that you see here at the point,
that not part of the static map are students in the corridors
of the university.
Okay.
So, um, today we came here to share our new open source
of the Asian framework, which we called,
east navigation or a sorted east enough.
And you may be asking, why?
Why another navigation framework?
Why?
Is it needed?
What?
We have been working with some projects,
some robots mainly outdoors.
Maybe you can have, uh, go back for a second.
Some scenarios where you have maybe stairs,
maybe you have a golf course, and, you know,
the air is not flat.
And sometimes, and when you're using that too,
you have restricted to using the cost map.
You can use maybe the, the, the, the box alone,
but if you want to make those applications work with
enough too, you can.
But sometimes you have to rely on some hacks.
We've done it.
We've done it before, but sometimes, you know,
everybody does.
Everybody does.
So, uh, the idea was that we wanted to offer more options,
and to have another framework to work on these projects easier.
And we also wanted to provide a community,
these options.
You know, so being able to adapt to the different scenarios and so on,
and we are hearing for them,
we obviously believe in free and open source, right?
And we believe that open source is also having the freedom to choose,
okay?
And some of us, well, some people use,
or choose to use Ubuntu, or just don't.
It's okay.
We can all be happy.
And we believe that having alternatives is a good thing.
And that it was granted the whole ecosystem.
Yeah, I don't know.
Well, happened at Braille Stima Siski,
things, oh, I get all these money,
and I close enough to, maybe that can happen.
I hope that happens.
I hope that doesn't happen.
So it's good to have more options.
Uh, the key here, uh,
we have never aimed to replace enough to, okay?
We did, we do have my, uh,
not to.
It's been clear inspiration in, uh,
in the design for isn't that.
And we still continue to use,
and even to teach enough to our students.
So the, our goal was just to offer more flexibility,
and to provide an alternative to those specific use cases,
where not to, is maybe,
not the most suitable thing.
Okay.
So now have our little demo time.
Yes.
Like demo.
Yes.
So I'm going to start, you know.
I'm going to run the,
the simulator about headless,
because I don't want to waste, uh,
uh, GPU here.
And I'm going to run is enough.
As scenario is, uh,
Roast to run, only one, one five, one process,
with only one configuration five.
Single process, single parameter five.
Um, this is how it looks like.
And armies, which is open.
Yes. Now, uh, in this scenario,
you have several stacks.
This is the cost map stack.
It's only to demonstrate that at least,
we can do the same.
I've enough to.
So the robot is here.
You have the inflation inflation.
You have a cost map.
You can put here.
I know, uh, goal and the robot go to the goal.
So more or less the same.
And enough to can do.
You can, you see here,
the map because it supports dynamic object.
That's what it says.
The apps that they run.
So what? Okay.
Let's close.
This is our first demo.
Let's return to the presentation.
Great.
So, uh,
when we started this like almost a year ago,
it's not been a long time.
Uh, as I said before,
obviously,
not two was an inspiration.
And not two is a complex piece of software.
It's not a simple thing.
It has a very well designed.
So we also put, uh,
some effort into having a,
a good design as well.
So, uh, these are the main four points.
Uh,
the, the,
the,
uh,
that we follow when we design.
The first one is probably the most important one,
which is that the framework is not dependent from a map representation.
As you know,
you have used enough two every,
the cause map is inside.
The code,
and it's very hard to change.
Yes.
We want you to be able to use
optimal grid maps,
one side,
whatever map representation you want.
A very important thing here,
which is,
I think it's been a,
repeating topic today,
which is determinism.
Performance and so on.
For us,
this has been also a very important thing.
We use Ross for inputs and outputs,
but internally everything is monolithic.
We have a single process.
And now,
Ross communication inside that.
That's right.
That components are,
Ross two notes,
but inside we have a blackboard to communicate everything.
And we don't rely on the executors or
timers or anything,
the execution of the,
of the loop.
We have two threads,
one real time,
and not real time,
that perform different things.
Now fine.
It should be light and easy to use.
It's easy to use.
It was not so easy to develop.
We have one single binary executor,
but you saw how to run it.
And we have a single configuration file
where you can define all the different modules
and its parameters.
And similar to what Napsu and other frameworks do.
The system is modular.
It's based on plugins.
So all the different implementations for the localization,
the mouse manager, the path planner,
and contouring someone.
It can be,
it's smaller.
It can be implemented in plugins.
And you can change them for each application.
This plugin composition is a bit
trickier than usual.
And for us, it's like a puzzle.
Because if you have,
if you allow different map representations,
then you need to make sure that the plugins are compatible.
If you are using, for example,
a cosmap,
to represent the world.
But then you want to use a path planner
that is meant to work with all the maps.
That's not going to work.
That doesn't.
It doesn't match.
So, one thing to have in mind
is that when you're composing your plugins and building your
your navigation stack,
you have to choose compatible.
Which makes sense?
There.
We can see a composition of a cosmap or a cosmap
with the NCL that uses cosmap.
I start for planner.
Cosmap MPV contour.
Here we have another representation.
The over simple stack is more simple.
Like we used for initial steps.
With another,
with another plugins.
Of the grid map or the map,
we will solve soon.
Maybe the controller
you can use in every configuration
if the planner,
the output, the planner are paths.
A standard map message message path,
as well.
What happens if you don't want,
or you don't need a map,
or you don't need localization for your application?
What is just one navigation stack,
which is just purely reactive,
like follow a person.
Like the doctor.
Then you may be to not need a map.
You can put a dummy module,
which does nothing.
Yeah, in that way,
you can provide your planner,
for example, follow a person
and reuse the BPA controller.
For example, here,
you don't need a map,
but you have over GPS localizer.
That is based on robot localization.
And you have a plan error of a stray line
to the robot.
Yes.
And all this,
of that composition,
is done in a single configuration file,
which is a general file,
but you just can put the plugin for each module,
for the localizer.
I'm going to use a simple localizer
or an AMC localizer.
And each plugin will have the parameters in that place.
One important point is the sensor node,
is the entry point for all the sensor information
of the system.
Okay, passed.
And now, the tricky part,
please don't get scared because of the arrows.
It's a bit messy.
The execution model,
as we said before,
everything is running in a single process.
Okay, we have two main threads.
One thread for the critical task,
which has elevated real time priorities.
Okay, which is where we run the processes
for the sensor update,
the post prediction,
and the control.
So it has a higher priority than the other tasks.
And then we have another thread,
which is normal thread,
non-real time,
because it is lower priority for the,
well,
also the logging,
which is not here.
Logging, maps update,
the path planning,
and the whole correction.
So I think the red arrows are for the real time flow
and the green arrows for the real time.
We have another,
you know the important of the DFs.
So we have a TF buffer,
say,
you know the code is a single time.
It's a real time,
TF buffer,
and you can access directly there from any place.
Yeah, the idea here is that there is only one TF input
for the system,
which is also running in the real time buffer.
So we can get the TF data as soon as possible.
Because if you have the sensor data,
but you have not received the TF yet,
then you cannot use that sensor data,
that's useless.
You cannot transform data that is coming from the future.
But there's more.
Yeah,
that's very nice,
because when you configure the,
the plugins of every model,
you,
you are all yellow to select one,
except the,
the mass manager.
In the mass manager,
you can select any representation you want,
even more than one.
And even some representation,
because I execute it in order,
can rely on the output of the previous one.
For example,
in that way,
we have the cosmap,
for example,
after that,
the rooted manager,
the rooted maps manager,
for rootest,
based on the cosmap.
Yes.
You will see this in the next.
Yeah,
the moment,
but you can have multiple,
my representations working at the same time in the system.
Yeah,
we are going to use this,
it's a bonsai representation for a special,
obstacle,
and the napma,
is our representation,
we made for suit faces,
for aviation faces.
Okay,
let's see how it works.
It's a good moment,
because David,
I just entered the room.
Yeah,
um,
should meet.
This is not headless,
because I want to show you
this scenario.
This is a very cool scenario in our university.
Yes.
Over the university is there,
and this is where it should be another building,
but it's not.
Oh.
Okay,
but it's not plan on the scenario.
Okay.
I'm going to run,
to run,
this is a different navigation start.
Instead of using cost map,
we will be using enough map for the navigation surfaces,
and bonsai for the obstacles,
and for the localization.
Okay, I'm going to change to
instead of inflate the obstacles to elevation.
Let's see rainbow.
Let's see,
for example,
how to navigate
to this point.
And you see,
how the path,
and the MCL.
It is running forward,
localization is running MCL,
but in 3D.
And this is the path in 3D dimensions,
of how to navigate at different levels.
At the lead support level on top of level.
Okay.
Can you show the,
the water side?
I don't shy.
Yes.
It would be a lot of points, but of course.
Yes.
It is also there.
The percentage of that boxes.
Yes. So here we're using the other map,
the map map mesh for the navigation,
for the surfaces,
and we're using the bonsai for the MCL,
for the localization, and for us.
Yes, for the observation model of the MCL,
we need the obstacle,
all the obstacle.
Okay.
So,
three minutes.
Okay.
We'll just start.
The QI.
Oh, the QI.
Yes.
Nowadays, if you don't have a QI,
you're not cool, so we did one as well.
Unfortunately, we are not using the ratatouille,
so it's not very pretty.
But it's been very, very useful,
because we used it to,
we have the window with the tracing information,
taking the processing time for each.
This is the blackboard for each part,
and we have here the state of the whole system.
It's the post of the robot.
Yes.
Okay. I'm going to close everything.
On continue the presentation.
So, the two in addition to the QI,
we also have a combined line interface
to query the states and symbols and do many more stuff.
And regarding the code organization and so on,
we have everything hosted on GitHub.
Okay.
The license is GPL D3,
not everything except for the NAFMAP,
which is Apache.
Apache 2.
And right now we're using GitHub actions for the CI.
We have CI pipelines for all these distros
for those who have just executed.
And rolling,
we are also generating the doc sheet and
a class reference documentation,
which is uploaded.
It's nice seeing everything in the ring,
although the states will have in some problems.
And recently,
yes.
It's green.
We just did releases for Ross to just see and killed it.
But only for the code repository,
we still have to release the plugins repository
with all the plugin implementations for different stacks.
Yeah.
In this scenario, it's the core.
They see plugins are,
they usually call a really different plugin.
And we also have some other repositories that are not here,
which include the simulation playgrounds,
in Casivo, which are the ones you saw in the demos.
We have one with the top tabo,
another one with the summits and so on.
Regarding the documentation,
we believe this is a very, very important thing.
So we have released the doc sheet and reference,
and we also have documentation based here on GitHub pages.
With all the API tutorials,
how to scan everything multi-robot,
router, how to deploy in a real robot in a create free,
for example.
We have to update some parts.
Yeah.
And if you remember Ross won wiki,
and Ross won wiki,
you have a page template for the Ross packages.
We have something very similar for the modules.
So when you develop a plugin,
over we do it,
we have a template page, which is all the information,
parameters, what the state does,
does it need,
the map representations that it's compatible with,
the key that is added to all the plugins in the web.
The case of the blah, blah, blah, blah.
Everything you need to understand this.
And if you develop your repository,
your own plugin,
you can create this page,
and we can index in the official image.
So where are we,
and where are we going?
With the develop,
yet another navigation system,
which is robust,
and we believe it's easy to use on the design.
This work hasn't been done in six or seven months,
we still have a lot of things to do.
It's light,
and more or less the terminist,
we try to have something as a terminist as possible.
It's able to add up to problems,
we're not sort of right some hacks,
and we already have a lot of things,
or platforms you saw in the demos.
And right now we just want to build more community
around it,
that the people know it,
and we still need some
effective controllers,
that work a bit better than what we have now.
Yeah.
And that's all.
Thank you very much.
Thank you.
Anybody has any questions?
We have time for some few questions.
So I find this very interesting.
How does this backport,
or let's say,
how does it backwards flow into existing architectures imagine?
I have a robot already,
and I'm running loss to humble.
I have some whole bunch of behavior trees.
I'm relying on a whole bunch of plugins,
everything is natural.
What's the workflow for me to migrate to easy enough?
Is it,
do I need to rely on certain,
another build system?
Because I don't think we spoke about the build system here?
Is it still a call call,
or do you have something custom?
Yeah.
It's a call call.
So everything else stays the same.
All the plugins,
all my packages upstream,
all come from the same sources,
and I can just,
or the next time, basically.
Yeah.
You have to,
or install the binary package,
so I put that in a single space build,
and that's one.
You have to do a parameter,
a file of parameter for you,
but probably it's only,
we only one point,
but are your sensors at us?
Yes.
There is one key difference from not two,
which is that if you're using,
you don't have use of the behaviors,
we don't have that,
because we believe that those kind of behaviors
do not belong in an navigation style.
Be long to an upper level of behaviors.
But you can just use the existing navigator,
but easy enough not.
No, no, no, no.
If you want, for example,
instead of if you have to do a patrolling behavior,
probably I can do it,
changing the behavior between an navigation, for example.
But I think it's,
it's how it's belong to another level,
to not a level of the skill,
a level of the task, I think.
It's a world opinion.
There's one question from somebody online.
How easy is it to make new plugins?
It's very easy, it's very easy,
because you have to inherit from the base class,
and only feel update or update
or update the function,
and you receive the blackboard reference to the blackboard.
You only have to check the plugin you are using,
check what are the keys,
so the blackboard extract,
the information,
and at the end,
write the blackboard,
the result,
you're expecting another plugin.
All right.
Any more questions in the room?
Okay.
Are you at the right of way?
So you mentioned,
you don't need any of the hacks that you would need.
What?
I'm not using NF2 at the moment,
but what kind of hacks does easy enough?
Let me avoid that I would have to do enough too.
Even in the last month we have told
with many people that use NF2 for agriculture
are robot, for example.
All of them,
think as they worry,
it's flat, but it's not flat.
And you have problem, for example,
when the road moves,
and the last set,
start to appear some obstacles.
For example, when you have to go in a ramp,
and you have to do some hacks
to don't mark the ramp as an obstacle.
So if you choose a good representation,
you don't have to do it.
I make agricultural robots,
so it's very relevant to me, thanks.
All right, I think that's all, thank you.
Thank you.