[Inici de la transcripció]
Institut Cartogràfic i Geològic de Catalunya
ICGC organitza
"UNION Technology Workshop & Demonstration: Bringing precise positioning to mass-market", 6 de febrer de 2023
Bon dia a tothom.\NDear colleagues, good morning
and welcome everyone to Barcelona\Nand to today's workshop.
I'm Miriam Moysset,
the ICGC General Manager,\Nand I have to say that we are really happy
that all of you are attending this\Nworkshop and demonstration
here in person at the ICGC or in the live\Nstreaming that we are performing.
So thank you for coming and joining us.
Today,
the consortium formed by Rockebon\Nand the ICCC is going to present the Union
project, the technology developed\Nand the results obtained after two years.
Now that the project is reaching its end,
we would like to thank the EUSPA,
the EU Agency for this space program,\Nas this is research
and Development European project\Nfunded by the agency Union.
As the acronym of and different\Nand Combined Positioning Engine,
is a new satellite positioning technology\Nwith the goal to provide accurate
navigation for mass market devices,\Nbut without forgetting about the current
user of positioning services,\Nas the ones who trust
on the Catalan Integrated Geodetic\NPositioning Service provided by the ICGC.
Just to give all of you a brief idea\Non the technology,
let me say that Union is based\Non leveraging the strength of RTK and PPP
techniques, plus the Galileo Height\NAccuracy Service palliating.
Some of the main limitations of those\Ntechniques when used separately,
such as the poor scability of RTK\Nand this low convergence time of PPP.
All this will be shown and explained
in more detail in the\Nfollowing presentation.
This project has been very important\Nfor the ICGC,
who is currently\Noperating the Catalan Integrated Geodetic
Positioning Service and the active\NGNSS Cat network with all its service.
In this regard,\Nit is necessary to say that the Kathnet
network is one of the three pillars\Nof the Union project and in the opposite
direction, the Unit project is one\Nfindable way to expand the cabinet
positioning services\Ninto this mass market wall.
Last but not least,\Nthe Union project is completely in line
with the positioning services currently\Nprovided by the ICGC,
burden with their accuracies\Nand consistent with the official eTRS 89
frame reference frame publish\Nit and maintaining by the ICGC.
I want to say thank you to\NJoel and Jordy Sanchez david.
David Gomez, Dalao de Sara ilaknes\NLados to organize this commit.
Thank you.
Thank you for joining today's\NUnion worship and demonstration.
I will just thank also Me and Moiset\Nfor his nice introduction of the project.
And right now I will just move\Nto the first presentation.
But before it is,
I would like to introduce our first\Nspeaker, who is Mikhail Gastio Fernandez.
Just to give a brief introduction of him.
Just to say that he's\Nthe Cofounder and CTO of Rokubun.
He's a genss research engineer\Nwith more than 15 years of experience.
He received his Bachelor of Science\Nin Telecommunication Engineering in 1999
and his PhD in 2004\Nrelated to GNSS data processing,
both issued by the Polytechnic\NTest University of Catalonia.
His most recent experience before co\Nfounding Rockbool includes the position
of JPL in the Naza,\Na postdoctoral position
in the Research Center\Nof Sustainable Human Square
in the University of Kyoto,\Na contractor scientist
in the GNS Technology and Navigation Group\Nof the Gemma Aerospace Center,
and the position as a project\Nand program managing Stala Barcelona.
He is also an associate editor\Nof the GPS Solutions Journal.
And without any further delay,
I would like to introduce the first\Npresentation, which is the Union new
Strategies in GNSS Technology\Nfor accurate and scalable applications.
Mikhail, the floor is yours.
Okay.\NHouston, you hear me?
Yes, Valley.
All right, so thanks Jewel,\Nfor this nice introduction.
So I'll be talking around\N15 to 20 minutes, hopefully less,
just to give you some\Ninsights of what is Union?
Right?
So what have been we have been doing\Nin these last two years with ICGC?
What are the objectives of the project?
What have we achieved?
So that you have a brief idea\Nof the framework of this project?
Right?
So let's start with definitions.
So what is union?
So Medium before mentioned the acronym,\Nbut if we have to summarize it in one
sentence, one long sentence,\Nmaybe we can use that one.
So, Union is a satellite positioning\Nengine for accurate and real time
navigation for mass market devices\Nsuch as smartphones and vehicles.
For those of you who are already curious
about that, just feel free\Nto browse to this webpage.
So there are actually two keywords in this\Nsentence that I'd like to highlight.
One is accurate\Nand real time and mass market.
These are the three keywords that we\Nwant to stress in this presentation.
All right, so I mentioned a sentence,\Nbut what does it mean in practice?
Right?\NSo what are the objectives,
what do we want it to achieve and what\Nis what we have achieved at the end?
Right, so basically we need or we wanted\Nto fulfill these three objectives.
So we wanted to develop a positioning\Nengine that it's flexible,
that it can cope with the new\Nsignals that are out there in GNSS.
We want to achieve decimetric accuracy.
When we say accurate navigation,\Nwhat do we mean?
Right.
In practice we mean the symmetric\Naccuracy in mass market devices.
As you will see, the symmetric\Ndepends on the environment.
Obviously, it's not the same an automotive
receiver than a mass market\Nreceiver such as a smartphone.
So the symmetric accuracy works
for premium mass market devices such as
Ublox chipsets and low end GNSS receiver.
But being more realistic for devices such
as smartphones or wearables, the symmetric\Naccuracy is really a challenge.
So we are targeting more\Non the meter level accuracy.
And finally, one of the issues that was
briefly mentioned before in Medium\Npresentation was to overcome
the scalability of current\Nposition technologies such as RTK.
We'll talk a bit more about that later
and I think Juan will also make\Na presentation about that.
So in terms of metrics, right?
How do we translate those\Nobjectives into metrics?
So basically in three of them, right?
So we want to ensure continuity so that we
have a consistent, accurate\Npositioning during long ranges.
We are talking hundreds of kilometers\Nin article networks where you have
handovers between stations,\Nthis accuracy can be impacted.
So we want to at least ensure that we have
a continuous flow of accurate\Nnavigation over long distances.
We want also accuracy.
That's kind of the de facto metric\Nfor all positioning engines, right?
We want the symmetric accuracy\Nfor automotive and metric level accuracy
for lower grade receivers such as\Nthe ones we can find in smartphones.
And finally, tied to continuity,\Nwe want also availability.
So we want to maximize as much as possible
the availability,\Nso the points at which we have positions
and we don't have parts of the territory\Nwith lower degree of accuracy.
All right, so just to give some figures\Nabout the project itself, right?
So as Mina mentioned before,\Nthis project is a two partner consortium.
It was ICGC on the ones on the one hand
and Rokubun, who was\Nleading on the other side.
So Roccobon put the idea on the table,
put some development as well,\Nwhile ICGC was basically providing
the infrastructure of the base stations as\Nwell as the infrastructure to generate
the virtual reference stations,\Nwhich we will give more details later on.
So this is a combined effort\Nbetween these two institutions.
It's a private public effort.
As you can see, the project lasted two\Nyears, or is going to last two years.
It's not yet finished.
It will finish soon, but not yet.
So it started on March 20 21st and it will\Nend by the end of February this year.
So, total of two years and a total budget
of less than half million,\Nsplit between the two partners.
It has, I would say,\Na rather classic approach.
In terms of work packages,
we have a definition stage where we define\Nthe network that we want to implement,
we define the algorithm\Nwe want to implement.
Then it was followed\Nby the detailed design, right?
So we would put the specific details\Non what we wanted to implement.
Obviously, it has a development stage
where all the effort\Nbasically was concentrated.
And obviously after the development,\Nyou have to test the outcome.
So there is a test\Nand validation phase for that.
Obviously being public grants,\Nit has to have a dissemination stage where
we publish our results,\Ndisseminate our results into conferences.
And finally,\Nso there is an important and important
work package, which is\Nthe commercialization.
So we don't want this project\Nto be left in a drawer somewhere.
We want to have some market\Nviability out of it.
So part of the project also was obviously\Nto try to find a business model behind
the exploitation of the\Nresults of this project.
So basically, just to get\Ninto more like technical details.
So we mentioned, there are two things\Nhere, accuracy and scalability.
So there are two concepts in the project.
There is one part, which is a positioning
algorithm, and there is another part\Nwhich is scalability of the service.
Regarding the algorithm,
we call it Undifference\Nand uncombined Processing engine.
Assuming that you are here and you're
familiar with the GNSS technology,\Nyou already know that there are kind
of state of the art in terms\Nof algorithms, is that you have precise
point positioning,\Nwhich typically uses the anospheric
combination to get rid of the ionospheric\Ndelay and so on and so forth.
So it combines the measurement of the GNSS
receiver and then you have the other\Nalternative, which is the real time
Kinematic, which as you may know,\Nit uses data from a reference station
and it makes differences\Nbetween the base station and the router.
So you can see two words here, combined\Nand difference, which were trade.
Well, the genesis world was simple.
So you had GPS, two frequencies only.
So things were rather simple in the past,\Nbut they are not simple anymore.
You have GPS, you have Galilee, Obedo,\Nyou have many more constellations,
you have many more signals,\Nyou have many more frequencies.
So now the question is,\Nwhat should I combine?
Right?\NI have to take one reference code, right?
Or what should I difference?
I have to take which satellite, right?
So the bookkeeping becomes very\Ncumbersome, more complicated.
So now there is this trend of instead
of combining and different data,\Njust process the data as is, right?
It makes a little bit more complex
to processing, because when you combine or\Nwhen you differentiate data,
you remove things that you\Nare not interested, right?
But you don't have it anymore.
When you process the measurements as is,
so you have the Troposphere, you have\Nthe Anosphere, you have some biases.
So what do you do with those, right?
So what you have to do is estimate them.
So you don't remove it,\Nbut they are still there.
You have to estimate it,\Nbut you can do that, right?
You have more signals, you have\Nadditional data, so you can do that.
This approach is not invented by Roku
and so it has been in literature for\Nsome years already,
but at an academic level,\Nwhat we have done in Union is bring those
knowledge and implement it so that it can\Nbe a commercial and viable technology.
Okay?\NSo I've talked about the algorithm.
Now just some few words\Non the service and I won't mention too
much because then I don't want\Nto step over Joel's presentation.
Just to let you know that what we have\Nimplemented in Union is what we call
permanent virtual\Nreferences station concept.
So, as you know, in RTK,\Nthis is a bi directional system, right?
So you have a robot receiver you want\Nto position, and then you have a set
of bases, stations and the service\Nthat provides corrections for that rover.
The rover needs to send an approximate
position to the service,\Nand the service will compute a kind
of stream of data that is\Nsuitable for that receiver.
This works fine when the number\Nof users is relatively moderate.
But as you can imagine for mass market\Napplications, where you have millions
of devices, maybe not millions,\Nbut hundreds of thousands of users
in a very small area,\Nthis can become a problem, right?
So you have to try\Nto be like as much broadcast as possible
without interacting too\Nmuch with the users.
So that's where the permanent\NVRS comes into play.
Instead of making the users send\Nthe position and then replying
with the stream, we set a predefined\Nset of stations, right?
It's the map that you see here.
So we configure the network,\Nensuring that the baseline is 20.
Then we provide\Nthese virtual stations to the users.
The user simply has to connect to the two\Nor three stations that are closest to him.
This is scalable because there is\Nno bi directional nature here.
It's just one way.
So it's from network to the user.
So how does it translate in practice?
So, what we have basically done is create\Na caster with all the beta stations,
virtual visa stations that are\Nprovided by the service.
So you will see here in the caster\Nthe stations from ICGC, right?
And from then on, you'll see\Nall the virtual visa stations.
So the user would basically pick\Nthe ones that are closer to him or her.
So
another\Npart of the project that has been done is
working with a Galileo\Nhigh accuracy service.
As you know, has is a concept that it's\Nalready broadcast by Galileo is a signal.
It's a series of data that is broadcasting\Nthe Essex frequency of Galileo.
And these are basically corrections
on the broadcast orbits,\Nclocks and the CV biases.
Right?\NSo Yuspa is validating.
It actually it finishes the validation
and it's already broadcasting\Nthe data as we speak.
And in the context of Union,\NGalileo has been implemented,
the processing of the Galileo Has into\Nour filter.
And we just participated in the validation
campaign that has been done\Nduring the execution of Union.
All right, so here you have an example
of processing some data\Nfor a professional receiver.
This is entry aesthetics.
This is basically horizontal error,
the cumulative density function if\Nyou use has or if you don't use it.
So, as you can see, basically by applying\Nthese extra corrections coming
from the Galileo haz, you can really\Nremove the error quite substantially.
So one of the activities that we're done\Nin Union besides validating that is making
these corrections available\Nto none Esix users.
Right?
So smartphones can track L One if\Nit's one of the flagship receivers.
Maybe you can track L One\Nand E five if you're lucky.
Right.
Other receivers like Ublox.
They can track l one\Nor E one and E five B.
But E six is usually\Nlimited to genetic receivers.
So really expensive receivers.
So low cost, medium cost receivers won't\Ntypically have access to E six frequency.
So what about them do they\Ncannot access to E six.
So one of the things that actually usepai
is also trying to do it is rebroadcasting\Nthis information through Internet.
So we actually did that as\Nwell in the Union project.
So basically what we did is we have\Na September receiver in our premises.
We just take this E Six data or the has
within the E six data,\Nwe convert it to standard RPCM three
format and then we rebroadcast\Nit through the Union caster.
That's what actually you\Nsee here in this line.
So there is an extra line\Nin the caster that is an SSR stream.
So a receiver could basically\Nconnect to that mount point and would
obtain RTCM Three messages\Nwith the has corrections.
This is already implemented\Nthat it's publicly available.
So now this means that a smartphone,
that it's only L one,\Nas long as it has Internet connection,
can connect to that and have access to\Nthe SSR corrections provided by Galileo.
So another thing that has been done,
especially because we had to develop\Nthe algorithm and test it, right?
So we basically implemented\Nthat as low level as we could.
So basically\Nall the algorithms are implemented in C,
which maximizes our possibilities to cross\Ncompile it in different platforms.
We can try it on laptops,\Nwe can try it on desktops.
But actually we wanted to embed
that into our receiver,\Nwhich is an arm based receiver.
And also to Android smartphones.
Implementing the whole thing in C allows
us to make this cross\Ncompilation much easier.
This allowed us to make extensive\Ntest and validation campaign.
So we tried multiple scenarios bicycle
pedestrian with a smartphone\Nand with Amadea
we used automotive campaigns\Nthat lasted like 100 km or more.
So this had been actually done\Nfor the project as well.
As I mentioned before, there is a part\Nof dissemination in this project.
So we presented\Nthese concept in conferences,
published some papers in Ion conference,\Nhad some press releases as well.
In order to let the concept be known,\Nwe also performed several ethographies
trying to explain the concept behind\NUnion on a more commercial level.
And finally commercialization,\Nthis is a key point of the project.
So that's the whole point,\Nespecially for Rokubun, right?
At the end of the day,
we have to somehow make the concept\Nmake the concept available to the market.
So we mentioned we created the commercial
name for the undifferent\Nand uncombined processing engine.
We call it sphere.
There is also a new photographic in our
web page, in Brockcom's web page,\Nif you are curious.
And all the validation testing that we've
been performing in Union is actually\Nbeing used to prepare a white paper.
A white paper is basically a document\Nthat we are using to approach the industry
and say hey, this is the accuracy you can\Nget in this scenario and this other
scenario with this platform\Nor this other platform.
So we are taking this tool as a means\Nto prove the accuracy and the availability
of this algorithm, because there is\Nactually some need of that.
So there are chip manufacturers,
chip integrators that they\Nimplement the hardware,
but at the end of the day, they lack the\Nexpertise of processing the data itself.
So there is actually a need to develop or
license some algorithms that can\Nmake most of the hardware.
That's our market goal in terms
of the location stack or\Nthe algorithm algorithms.
So in fact, we just signed a few weeks ago\Na collaboration agreement that is
currently ongoing\Nof an initial integration of this
processing algorithm\Ninto a navigation onboard unit.
So we are step by step coming in here\Nin the commercialization phase.
Besides this,\Nwe are also working on expanding
the permanent virtual reference\Nstation to more territories, right?
So can we exploit that?
Can we make some money out of it?
So, these are questions that we will try
to answer by the end of the project and a\Nlittle bit with further project as well.
So, thanks a lot.
I hope I didn't just took six\Nminutes from you as well.
Sorry about that.
In case you have any questions,
just feel free to browse the web or\Njust ask me or I'll be around here.
Thank you.
Thank you Mikhail,
for this nice introduction\Nand presentation of the project.
I will move to the next presentation.
Just before this, I would\Nlike to introduce myself.
For all of you\Nwho do not know me, I'm Jog Rabadette.
I'm the head of the Geodegy unit here
at the Cartographic\Nand Geological Institute of Catalonia,
with more than 15 years of experience\Nin geodesian and subeying.
I received my Master of Science\Nin Geodesian cartography in 2005
from the Valencia Polytechnic University\Nafter having obtained my Bachelor
of Science in Subbeing 2002 from the\NPolytechnic University of Catalonia.
Just to give a brief example,\NI have to say that together
with my colleagues,\NI've been in charge of calculating
and disseminating the Ed 50\Nreference system update to ITRs 89.
And I think I have to emphasize one of our\Nmost recent achievements,
which is the acceptance of ICGC as\Nan airwave dedicated analyze center.
I think that this has been a very\Nimportant achievement for us.
So just to share it with all of you\Nand without any further delays,
I will start with the presentation
mikhail already
been talking about the permanent\Nbeautiful reference station new concept.
I would like to go a little bit,\Na little bit more in detail.
Okay?\NSorry for the technical issues,
just briefly, because for sure most\Nof you already know cabinet network.
But just to give you a brief idea\Nof the current status of the network,
just to say that all stations\Nin the cabinet network are tracking GPS,
GLONAS, Galileo and Beto Constellations\Nwith the receivers with full capabilities.
All rate stations have geodetic
and individual calibrated antennas\Nmounted on it or all of them.
And just to point that most of them are\Nconnected through 4G with CGC facilities
but in some of them we already\Nhave land connectivity.
And also just to point perhaps the most\Nimportant services that we already have
in Connect just to focus on entry which\Nhas been very important for this project.
And the Geoffrey and the Rennex Shop\Nwhich are just for post processing users.
In fact the beer to our reference station\Nconcept which is the classical concept
that we have been already\Nusing for so many years.
Just to move on, just to say that
this service is\Nworking on this way service at ICGC are
creating virtual reference stations\Nfor each user in its coordinates.
So the user just needs to send
the approximate coordinates\Nand the service here at ICGC just create
the builder stations and start\Nsending data to the users.
The problem as Mikkel said before here
could be the scalability of the solution\Nwith the users that we have right now this
is not a big deal but what if we are\Nfacing the mass market approximation?
I will talk more in deep about this
on my next presentation which is\Nthe current status of the realtime service
at Taxi GC and the scalability\Nfor the future.
But here we are for just letting you know
about the new concept that the union\Nproposes which is the permanent
Beerswell Reference station concept\Nwhich is meant to have no scalability
limitations in the main sense\Nof the concept which should allow also
the interteral navigation when\Njoining together with PPP.
And as perfectly explained,
Mikhail also including Dalileo has just\Nto make these observations available
to all the receivers that are not\Ncapable of doing it by its own means.
This is just to give you the concept\Nof the idea behind the idea.
The permanent Beer to a reference station\Nconcept consists in the creation
of a regular grid of beer\Nto our reference stations.
Just understanding the concept as\Nthe classical one we have
designed the solution just to have a grid\Nspacing of 20 by 20 km which we understand
and should be enough to fulfill\Nthe BRS like accuracy.
And these are the stations which are
called the Permanent\NVirtual Reference Stations.
These are published in the Union caster as
you have probably seen\Non the presentation before.
So any user will have at least\Nthree stations closer than 20 km.
This we understand.
It's enough just to provide a time
to first fix similar to the one that we\Nare obtaining with the BRS
classical concept\Nusers can or in fact have to choose
and connect to the closest\Navailable stations.
And here is where\Nthe positioning engine that's going to be
described after this\Nis going to enter in play.
There is no need to send coordinates as
on the classical concept,\Nas all the paramount and mutual reference
stations required are already\Navailable and accessible to everybody.
So the users are capable of choosing
the closest station\Naccording to its position.
There's no need to transfer\Nthis need to the server.
So the server does not need to create
a new virtual station for each user\Nas all of them are already in place.
You have seen this map before.
This is just the grid that we have\Ncreated here, just covering Catalonia.
This is the naming that we have\Nthought that could be useful for this.
And why this naming?
Because this naming allows\Nus to go worldwide.
We are using four digits, which is the\Nusual way to identify permanent stations.
And we are using the station where we are
moving its character\Nfrom A to Z and Y to Nine.
And this allows us to move with this\Nspacing all over the world.
So we have plenty of stations,
a grid of 20 by 20 kilometres,\Nwhich covers all the walls.
So in case we need to go to any other\Nplace, we just continue using the same
naming, with the same software,\Nwith the same concept.
This is the idea here,\Njust to show you what I've been saying.
The parameter stations are created as if\Nthey were using working in the field.
This is the software that we are using\Nto manage the stations and the service.
As you can see here, we have the physical\Nnetworks yay, Abel, Bell, Sono and SoC.
These are the stations and this grid are
the permanent and built\Nreference stations.
As you can see, all of them are created
from a single stations, as if they\Nwere virtual reference stations.
The data that we are getting from these
stations is the one that we are\Nbroadcasting to the Union casters.
In fact, it's exactly the same\Nas if they were users.
So they are already created\Nand they are already available.
And this is the way that it\Nperforms the Union and Tripcaster.
When these stations are available,
union and Tripcaster provides access to\Nall these synthetical stations nowadays.
As I said, the Canon network is the one\Nproviding the corrections,
but the two works with any other\Nsimilar network anywhere in the world.
We're just using standard formats so you\Ncan spread it all over any other place
which is using similar\Nservices that we're using.
Obviously, physical stations are also used\Nin combination with the permanent ones.
You can see here more or less infographic
which is showing the grid\Nof permanent stations.
Also with the classical stations.
This data is all going to the Union
entrycaster which is then\Nmade available to the user.
But there's no need,
as you can see here on the comparison,\Nto create a specific user station.
Here the main difference between the\Napproximation that we are using nowadays
and the approximation\Nthat the Union proposes.
The first difference is that the
communication between the user and the\Nservice is no redirectional in the Union.
So we just need to broadcast\Nthe corrections and the user is
responsible for choosing\Nthe appropriate ones.
The second difference is on the caster,
which is just broadcasting\Nthe information coming from stations.
But here the caster is also waiting for\Nthe approximate coordinates on the user.
And the other one is obviously the\Nsituation from the user point of view.
Here, when the user gets access
to the data, the server creates a specific\Nbiotin reference station for the user.
But here it's not the same.
I don't care if the user\Nis here or here or here.
It's used on a car,\Non tractor, on a drone.
They will have all the same\Nstations available for it.
The permanent MBRS system is based
on Python software, where we have\Ndeveloped in the consortium.
And this is more or less the working\Nstructure that we have designed to be.
So all the data\Nthat the software developed in the project
is accessing is already available\Non the public services.
The first one is the data from the VRS
three M service and the other\Nis the data from the stations.
All of them is full constellation data.
As I said, everything is combined
in the Union mining tripcaster,\Nwhich is based on the BKG solution.
This is just to give you an example
of what we are having with Union\Npermanent virtual reference stations.
You can see here the age of the data,\Nall the data provided to users.
It's below 1 second.
In fact, it's below half of a second.
This is the availability of data.
Nearly 99 9% of the data.
This is for one day has\Nbeen available to users.
And here you can see the number\Nof satellites that we are providing.
I have to say that right now we are
providing even more Beto satellites\Nwhich are already available for tracking.
Just to give the idea of the server\Nthat we are using for the Union,
because this will be useful on my next\Npresentation just for comparison purposes.
The software is solely based on Python.
On Python and it is running\Non an Ubuntu Linux 64 bit server with just
two CPUs, 4GB of memory\NRam and 80GB of disk.
But the point is not here, it's here.
We are monitoring the usage of the server\Nand you can see that the CPU usage is 1%.
We are just using 2GB of the four and we
are just using 15GB of the 80,\Nmost of them just for the OS.
This will be important\Nfor the scalability.
Just to give finally a brief idea\Nof the accuracy, obviously we are worried
for the accuracy of the service\Nthat we are deploying.
What we have been doing here is just\Nto install a geodetic receiver in a mask
that we have here at the rooftop\Nof ICGC headquarters.
And we have done some measurements.
First of all, with the service\Npublicly available, the BRS.
Three M, which is a full\NConstellation service.
And then we have checked this
with the three closest permanent builder\Nreference stations available in the area.
The receiver was here and we were checking
against these permanent\Nbuilder reference stations.
You can check here the differences.
We are most of times below 5 CM, so\Nthe value is not important.
The most important here to say is that we
are quite coherent with the services\Nthat we are providing.
So we are capable of providing more or\Nless the same accuracy that we are
providing with the services\Nalready available.
And last but not least,
my conclusions just to say that we\Nunderstand that mass market is feasible.
So from the user point of view,
it is essentially the same trusted VRS\Nconcept but on a different cluster.
And using the up, the software that it's\Nembedded on the receiver,
it's capable of providing the same\Naccuracy as current services.
It allows the combination with PPP
positioning whenever required\Nfor the uncombined and undifferent
approach and it allows using\Nextra services as has.
And so could it be continuous worldwide?
Obviously the accuracy would not be\Nthe same if we have permanent stations
there or not, but at least we can use\Nthe service so we could have positioning.
And from the provider point of view,
it allows scalability\Nwith the same resources.
Yeah, we need one additional server just
to be able to run the Python code to\Ngenerate the reference station permanent.
It takes benefit from the what expected\Nextended entry of concept.
It allows providing extra services
embedded in the same cluster and it\Nallows covering the wall to readily.
And what we should understand for wall,\Nit's our responsibility to decide it as we
can combine via risk\Nwith PPP or with Hash.
And that's all for me\Nfor this first presentation.
So I give back the word to Miguel.
All right.
Before this presentation I talk about
the concept of the project\Nor Union project itself.
But there is one important key point,
at least for Rokuburn as a private company\Nis what is the strategic interest?
Why do we want to do that?
Well, yes, we are private.\NAt the end of the day,
we have to pay the payrolls and we have\Nto make at least some money, right?
So we at least need to make out of it\Nin terms of commercial exploitation.
So I'll give some brief vectors on\Nwhat Union fits in the market in terms
of precise positioning, both on the\Nprocessing engine side and both on
the correction service or\Nthe network, if you will.
So basically, the thing is\Nthe number of devices that needs
geolocation has been increased,\NI would say exponentially.
Albeit the GNSS technology has been there
for us since the 80s, right, with GPS,\Nbut with the appearance of first
the smartphones, then the cars,\Nthen with IoT,
so the number of applications\Nhave been grown exponentially.
Right?
So this is the context\Nin which we are placed, right.
So, geologication of an increasingly
humongous number of GPS receivers that\Nneed to deliver accurate positioning.
So, as I just briefly mentioned before,
how does Union try\Nto answer this new context?
Right.
So we are trying to approach this field\Nor this segment by making two proposals.
One is the spear.
So it's basically\Nthe provisional location stack.
I'll mention what a location stack is that\Ncan be licensed by chip manufacturers.
As I mentioned in my previous
presentation, there is several groups\Nof hardware manufacturers that
they are aware that, okay,\Nthey have a very good hardware.
But how do we process this\Ndata and make most of it?
So this is an actual need.
So Spear tries to address this need.
So we have our engine,\Nso let's license it.
The other one is the network,\Nthe permanent virtual reference service.
So we have a network and this can be
considered as we will mention\Nthen as an added value service.
This is important because the market for\Nadded value services is increasing a lot.
Right, okay.
Location stack, what is a location stack?
Location stack,\Nbasically a software library.
A software library that can be\Nembedded in devices in few words.
Right.\NSo on the bottom, on the bottom hand,
you have on the left hand side here you\Nhave the GNSS or location value chain.
So sphere,\Nthe algorithm that we are trying
to develop is basically serving these\Ntwo components in the value chain.
So we have a component manufacturer.\NRight.
So chips.
So Ublox makes chips even though they\Nhave their own processing engine.
But there are others that make chips,\Nbut they don't have processing engine.
This is the component manufacturers.
There is also receiver manufacturers.
You can consider them.
So yeah, between these and the system
integrators, I have one GSS chip\Nthat gives me the measurement.
I have another chip that brings\Nthe computational power.
What do I put in the application processor
just to have a good\Nsolution in positioning.
Right.\NThese are the system integration.
So the Spear could actually serve\Nsystem integrators as well.
Right.
Okay.
Correction service.
What is a correction service?
As I mentioned, this is\Nan added value service.
It is not a receiver,\Nit's not a piece of hardware.
It's something that assists the hardware\Nto give a better positioning and better
can be in terms of accuracy,\Nin terms of time to first fix.
For instance, like assisted GNSS.
All of these are added value services.
Permanent Virtual References station\Nis also an added value service.
And just for you to know,\Nthe revenue for added value services is
increasing like or it's going\Nto increase like 72% by 2031.
So there is a lot of demand for that.
There is a lot of companies\Nthat are already there.
We are obviously not the only ones.
We are just teeny tiny,\Nbut there are big monsters there that are
already providing added value services
for that so in terms of corrections or
added value services that rely\Non correction services, what do we have?
Right?
So we have like two schools or two means\Nof providing corrections to the services.
Each one has its own pros and cons.\NRight.
We have OSR, which stands\Nfor Observation State Representation.
And this, as you may know,\Nis basically RTK, right.
So the base receivers deliver directly
the pseudo ranges, the observations\Nto the rubber so that it can perform RTK.
This is OSR.
SSR is space state representation.
Instead of delivering the observations,\Nthe service delivers corrections.
Two parameters of, for instance,
the orbits of the satellites,\Nthe clocks, biases, etc, etc.
It doesn't provide the full observation\Nof the receivers of the base receivers.
It's just corrections on the products
that are already being used\Nby the rubber receivers.
Galileo has is an example of SSR\Ncorrection RTCM, three streams with SSR
corrections is obviously an SSR\Nservice provision as well.
So, as we mentioned, there are\Npros and cons for each of the approaches.
In both cases, we are aiming\Nat sentimental accuracy.
The main advantage of OSR\Nis fast convergence.
Obviously it's not\Ninstantaneous, but almost.
Right.
Whereas SSR has rather\Nlagging in terms of conversions can take
a while, especially if\Nthe ionosphere doesn't help.
So you have to converge the biases\Nand so on and so forth.
Which translates that you want to get\Nthe fast converges as RTK, for instance.
Right, which is a matter\Nof seconds or even.
Yeah.
One of the main disadvantages of RTK,\Nand that's why SSR corrections are
considered, is the fact\Nthat they are not global.
Right.\NRTK are limited to 20.
It depends on the area.
But going beyond 50 can be\Na challenge to get good accuracy.
Right.
So whenever you talk to service providers\Nor hardware manufacturers and you say
there is this technique that's called RTK\Nwhere you can get sentimental accuracy,
the immediate question that you\Nare made is, is it global?
And then you have to explain no,\Nit's like 20 km.
So then what's the point?
The point is that you have to rely\Nto other techniques, such as SSR.
Right.\NThe corrections are valid worldwide.
It has its downsides,
but at least you get better accuracy\Nthan with standalone positioning.
Another problem with OSR,\Nwhich can be overcome, as we have seen,
is that it's bi directional,\Nnot with permanent VRS.
This is a slight improvement\Non the technique.
Right.\NBut SSR is a broadcast system.
It's a onetooney approach.
You simply just deliver all
the corrections for satellite\Nclock orbits and biases.
It's true that, for instance,\Nfor Spirit and Tropospheric corrections,
it's regional,\Nbut in general terms it broadcast.
And another big advantage is\Nthat it has low bandwidth.
Since you don't have to deliver\Nmeasurements every 1 second, for instance,
then the amount of information that you\Nhave to send over Internet or overall your
channel is way less than\Nin RTK corrections.
Right.\NAnd principle.
The problem is that of SSR is
that the hardware, well,\Nmaybe not 100% compatible.
Why?
Because the messages that are transferred\Ninto the SSR might be proprietary.
So there are several companies\Nthat develop their own messages,
SR messages, but obviously they\Nwon't work with all receivers.
So this is something else that you have
to bear in mind, just as an example\Nof what's out in the market.
So we have OSR providers.\NOSR.
Remember RTK?
So we have networks,
some of them,\Nlike on a more crowd sourcing like
on Okoye, which is a recent initiative,\Nwhich is actually followed by Geotnet.
There are several others.
And obviously we have\Nthe regional services like ICGC.
In the case of ICGC principle,\Nit's public, it's free.
So there are private companies\Nthat want to make money out of it.
If I'm not wrong,\Nthe Swiss network is a premium service,
so you have to pay to get\Naccess to the corrections.
So you have various business\Nmodel involved here.
Example of SSR.
There is actually a lot\Nof money invested now in SSR.
We have probably Swift Navigation\Nis one of the most recent start.
Well, actually it's not a startup anymore,\Nbut it received a big amount of funding
to develop this worldwide\NSSR correction service.
We have Ublox that acquired Subcorda,\Nfor instance, which was kind of a
consortium initiative,\Nbut then Ublox took control of it.
Also an SSR provided provider.
We have also trimble and Exagon.
I think we have some colleagues out here
from Exagon that could\Ngive us some details.
All right, so this as far as the added
value is concerned, so what\Nabout the positioning engine?
Right.
So as I briefly mentioned, there is\Nactually a need for that as well.
So there are companies and here I just put
a couple of examples that you can\Nfind easily in the web, right?
So, for instance,
St microelectronics that makes\Nchips, measurement engines, so to speak,
they deliver good\Nrange measurements in the rubber.
But just they made an alliance with 0.1\NNavigation to get a partnership
to process these measurements\Nand get a good position.
And obviously everything has\Nto be automotive grade, right?
It's not only that we can deliver
the position, but we have to deliver it\Nwith a certain regulatory standards.
Right.
So the software that you can have or\Nthat you have to put in a car is not
the same as you have to do it\Nfor a research activity, for instance.
No.
So there are some extra constraints\Nthat need to be taken into account.
There is this other company,\NKecktel as well, that it's.
A system integrator is one of these
examples of system integrators that have\Nseveral pieces, measurement engine,
application, processor,\Nand then they lack the hardware,
the software sorry, to process\Nthese measurements.
So the industry, the hardware industry is
already looking for solutions where\Ncentimetric accuracy, accuracy
can be achieved for these specific\Nmarkets that we mentioned right.
The automotive market,
especially with the autonomous driving,\Nelectric car, et cetera.
So this is gaining momentum as we speak,\Nbut also on the smartphone as well.
So we haven't talked much on smartphone,
but there are also different companies\Nthat are specifically targeted to improve
the measurements that you can get out\Nof smartphones,
especially in urban scenarios,\Nright, where it's most critical.
So what is the next steps\Nthat we plan to follow?
So basically\NI briefly mentioned it before,
but we want to just package spear\Ninto a model that is based on licensing.
So we want to go to these\Nfirst two elements in the GNSS value chain
in order to license\Nthe spear on their chips.
That's activity number one.
And then finally\Nis the provision of added value services
through the permanent VRS\Nor other services either here in Catalonia
or in other regions of the world right,\Nwhere this is needed.
So yeah, that's this\Npresentation for me, I think.
Jewel, you are next, right?
Yeah.
Thanks mikkel, thank you very much\Nonce again for your nice presentation.
Okay, so, hello again.
I will just now present the current status
of the real time services at ICGC\Nand Scalability for the future.
I would like just very briefly give
an introduction of the status\Nof the services here at ICGC.
But right now my presentation will be not\Nfull of answers but full of questions.
It's just the way to let us think\Nabout the future that could come.
So just to try to understand\Nwhere union is meant to be.
Okay.
So first of all, just very briefly where\Nthe core networks are today,
they are amongst the most used resources\Nwhen the highest accuracy is needed.
Nowadays the core stations exceeded\Nthe reference frame computation or
maintenance, which is\Nthe classical approach.
So services provided based on these\Nnetworks are nowadays need let me say they
are based on three main pilots,\Nwhich is obviously the Junitzer reference
stations, obviously the network control\Ncenter where we have here in our case
at the ICGC headquarters and the service\Npositioning platforms,
for example the worldwide web or\Nthe entrycasters or whatever.
As Mikhail explained it\Na little bit more detail.
Just corrections can be provided in mainly
two different representations,\NOSR and SSR.
Here at ACGC we are based on OSR\Nfor providing network RTK corrections or
corrections\Ndirectly broadcasted from sessions and RTK
or near RTK can be transmitted\Ninto different services.
Approximations we are just using right\Nnow the BRS user approximations.
And I want to point here
that the computation realize as we\Nhave seen before on the user side.
Okay,\Nand why do we need course as we also
previously have seen it's just to try\Nto sort all for correct the errors that we
have even in the atmosphere or in the\Nsatellite side or even on the user side.
This is just to give an idea of the errors\Nthat we could have when we are positioning
ourselves in the field and the different\Nkind of services that we can use,
the local positioning services like RTK\Nor the global positioning ones like PPP.
Union is trying to combine\Neverything together.
And I just wanted to show here perhaps\Nthe most important or used services
at ICGC, the ones with the symmetric\Naccuracy, the one with virtual reference
stations or the one coming\Ndirectly from each station.
They are just GPS for GPS\Nand gross constellations.
And on the centimetric accuracy side,
we have also perhaps I think the most used\Nservice, which is the one with full
installation, which I think is being\Nused by the 90 or 95% of the users.
As we have previously said here,
the data flow is just from the reference\Nstations to the data center.
Then the user is using Internet\Nto interrogate the data center,
just to get the data sending\Nits approximate position.
And now we start with the questions.
I just want to show here\Njust a couple of graphics.
The first one is the different users per\Nday that we are having here at ICGC.
I'm showing the information from 2014
to the very beginning of 2023 and the\Nhours of service provided per day.
In the case of the different users per
day, we have been passing\Nfrom 50 to more than 350.
This means a 39% average increment.
And the question is what in for example,\Nten years are we going to be serving
nearly 1500 users, four times\Nthe users that we are serving today?
I don't know, that's the question.
And from the hours provided, we have\Nmoved from 100 to nearly 2000 hours.
This is 51% average increment.
What, in 2033, just in ten years,\Nare we going to be serving 8000 hours per
day with these four times the hours\Nthat we are serving today?
I know what we will be\Nserving in ten years.
What we already know is\Nthat the serving is growing.
That's a fact.
I know where we will be in the future,
but I know that in the present\Nthe service is growing a lot.
For example, just to give a brief example,
which is I think next it\Nscenario, which is the precise farming.
We know that precise\Nfarming nowadays is a fact.
In fact, we have a lot of users\Ncoming from precise farming.
They are using the services,
the real time services,\Nthe most accurate ones,
for fertilizer distribution,\Nfor application of herbicides,
for fetusanitary treatments, for sewing\Nand harvesting, for everything.
And they most of the times need
the highest accuracy, as if they\Nwere surveying in the field.
Here you can just see three small\Nsnapshots where you can see the users.
These are obviously\Nfarmers just working in their parcels.
Just to give you a brief example of what\Nwe're having and if we look
at the statistics,\Nthis is more or less the same.
This is saying just exactly the same\Nthat we have seen for the users.
We are facing a 20% average increment\Nfor the annual entry users connected.
Should we expect 4000 different\Nusers per year in ten years?
I don't know.
There's a 71% average increment for the\Nannual hours provided for the farming.
They are quite an intensive users.
They start working and most of the time
they are using the service continuously\Nfor twelve or 18 or even 24/7.
They are quite, quite intensive.
Should we expect 10\Nmillion hour in ten years?
I really don't know if this\Nwill be the situation or not.
This is just the current picture.
This is just the usage that we\Nhave here in Catalonia.
We know that we have guidance machines,
we have farming,\Nwe have civil works for canals, pipelines,
they're using Batimeter\Ncivil works, surveying.
This is the real usage that we\Nhave right now in Catalonia.
Obviously, I don't know of the future,\Nbut this is the current situation.
And just to give the summary of what we\Nhave here, the entry of services
in general, we know that they\Nhave been growing a lot.
The precision farming, just to give\Nan example, it's also growing a lot.
And what if right now we are\Nat the beginning of 2017 growth that we
have seen for the agriculture,\Nbut for automotive or Lbs sectors
and we know about machine\Nguidance and precision farming.
We are right now in the situation\Nof starting thinking about autonomous
driving or smartphone positioning, as\NMikkel already said in his presentation.
But what about for example,
door navigation, sports monitoring,\Nemergency serving, fleet management?
Which is the user that's going\Nto need our services in the future?
We really don't know,\Nbut perhaps we are moving
to a new standard\Nand we need to start to think about it.
If you remember, I showed this information
previously on my last presentation where I\Nshowed you the need of resources
for the permanent BRS system\Nworking on a Linux server.
I just want to show here the real
performance of a server just giving right\Nnow the services of the Kinet network.
The Kinet is running on a couple
of servers windows Server 2019 service,\N64 bit servers.
They are mounting four CPUs each,
so eight CPUs, twelve gigabits of memory\Nper each, so 24 and a hard disk of 320gb.
It has nothing
to be in comparison with this,\Nbut the servers, if you remember this was
working at the 1%, but these\Nare working between 30 and 70%.
This is two days.
Just to let you know that the servers are
working a lot just\Nto provide the services.
Obviously you are just here\Nseeing probably the peaks of use.
So when there's more demand in the field,\Nthe server needs to process even more,
just not to solve the network,\Njust to provide the service to users.
So this is increasing.
As you can see, there's a big\Ndifference between this and this.
This will be needed as the service,\Nas the service that we are providing right
now needs to be there just\Nto be able to generate this.
But how much this can be\Ngrowing in the future.
And the same for the bandwidth.
This is the bandwidth that we are
monitoring right now when providing\Nthe service to the users.
Now we know that we have more or less ten
megabits of data throughput just going\Nthrough the net to provide the services.
This is the traffic going out.
But what if instead of having 150 users,
we have, nicole said\Nthousands of thousands.
I don't know what's the amount
of bandwidth that we'll need,\Nbut here is where Union is meant to be.
I mean,
we know that\Nwe need to start thinking in some other
solutions just to be able to fit these\Nneeds that could arise in the future.
And as I say, my conclusions,
we don't know where the future\Nand positioning will bring us.
At least I don't know.
But we know that usage is growing\Nand technology is evolving and we don't
know if Union will be\Nthe technology to be adopted.
But we already know that the new
technologies will come\Nand Union is already here.
So Union is a technology,\Nas we have already said,
based on new technologies or classic\Ntechnologies that we are already new.
They are already checked.
So we know RTK PPP has but we are also
implementing a new concept, which is\Nthe permanent builder of the stations.
We are combining everything\Nin a new location stack.
As Mikhail said,\Nthis is the software that's running
on the back of Union just to be able\Nto provide all this to the users.
And this was my reflection here.
So I think right now we are\Nmoving to the demonstrations.
So Mikhail is going to show\Nsome videos to us.
I think he's going to join with some\Nof his colleagues at Rockobon.
So yes.
So before we go into the demo,
I just wanted to give a couple of\Ncomments on your presentation.
Jewel, let me just reuse
you had yeah, this one,\Nif you remember from my last presentation
I mentioned, added value services are\Ngoing to explode in the next ten years
and are going to increase by a rate of\N72%, which is close to that figure here.
Right.
So I'm happy to see that actually this is
not a forecast, but also somehow\Nbacked by actual numbers.
So at some point I probably would
suggest you to talk to the guys at Yuspa\Nwho made the GNSS market report and let
them know those figures because I think\Nthat's a valuable set of data you have.
Because it's actual data,\Nit's not forecast.
So that's also relevant.
Another question I'd like to\Nmake on top of your presentation is
the fact, yes, so we overcome\Nthis escalability problem.
I think we have some minutes, right?
We have partially solved these scalability\Nproblems in terms of permanent virtual
reference stations because we\Nremoved the bi directional nature.
But there is also
the fact that we can still saturate\Nthe server if a lot of users are asking
for the service for a specific particular\Narea.
Right.
So one of the possible solutions\Nto that is by edge computing.
So segmenting the whole network
into different subnetworks that are\Nserved, for instance,
for base stations that are attached\Nto telephony or cellular networks.
Right.
This is actually something\Nthat is being investigated.
So how can we segment a network and serve
specific local streams of data\Nto a massive number of users?
This is probably not\Na communication navigation problem.
It's more a communication\Nproblem but still is there.
Right.
So this is something that might palliate\Nthe effects you mentioned here
on bandwidth, on computation power,\Nbecause you are also segmenting the amount
of processing load\Nthat you need to perform.
Right.
So these are just a couple\Nof digressions that I had.
Okay.\NYes.
As Jewelle was mentioned,
we wanted to show you\Na couple of videos for that.
For that I'd like to invite Maggie here.
So unfortunately,
we have two presentations or two\Nvideos we want to show here.
One automotive and one smartphone\Nthat is going to be presented by Maggie.
Unfortunately, because of the logistics,
we cannot say bring you into a car\Nand then a 100 miles drive.
Right.
So we had to refactor this demo and we\Nmake a short video, like showing
how it performs in different\Nurban or in different scenarios.
Urban, automotive,\Nloss of lock, et cetera.
This is a really short video.
I think it's 1 minute.
And you will see basically\Nthree windows here.
This is actually the front ends\Nof Medea, right,
that you can see when you're running\NMedea with our processing engine.
That's what you would\Nsee in your smartphone.
Or if you are connecting\Nto Medea with a laptop.
This is from a laptop, right?
So basically Medea raised\Na network and then you connect
to the network that is\Ngenerated by the receiver.
And then you can see this.
That's actually what you would see.
What you see is what you get.
All right, so we have\Ndifferent windows here.
We have the position, we have velocity,
the snr of the different satellites\Nthat you are going to be seen.
Obviously a map.
That's a given, right?
For a positioning solution,\Nyou need a map always.
And here, for the sake of this\Ndemonstration, we just put two positions.
So the one you get with our engine
in yellow or orange\Nand the one of the truth,
which is basically RTK position\Nby say, commercial solution.
Commercial and proprietary.
Right.
The test was taken with a car\Nwith automotive antenna antenna.
It's a magnetic mount, so it's not\Na geodetic antenna, so to speak.
And both the reference receiver and our\Nreceiver were in a zero baseline test.
So they were seeing exactly\Nthe same observations.
Here we also put the reference,\Nthe horizontal error between the two.
So you will see that they are mostly\Nwithin 1 meter or even less centimetric
decimetric,\Nwhich basically fits on the main
requirement for that demo, which is we\Nwant to achieve lane level navigation.
Right?\NSo we'll go through this.
Let's see if just no.
Okay.
Not this button.\NOkay.
So this is in your scenario, right?
If I'm not wrong,\Nthis is Sanadro De Lavarca.
Then we went through a highway.
This is open sky.
In principle, it's good conditions.
We were receiving OSR\Ncorrections for that.
So, as you can see,\Nwe are achieving a lane level navigation,
which is one of the objectives\Nof the project.
So far, so good.
And here is one where\Nwe lost the visibility.
So whoops.
We got the reference receiver.
As far as I know,\Nit's propagating the solution.
So that's why you could\Nsee some points inside.
And then finally we got here\Nsome station change, right.
As we weren't moving through the highway,\Nobviously there were some permanent
stations that were lost,\Nso we had to attach to other ones.
So that's why we wanted to make\Nthese long drives, right?
So to test the different transitions\Nbetween one station and the other.
So this is as far as\Nthe automotive is concerned.
We can repeat them later on if you want.
So, Maggie, you want to join us?
So while Maggie is preparing this,
maggie is a GNSS engineer as well\Nthat joined Broguehon several years ago.
Like two years already, Maggie.
Two years and three months.
Yeah, quite a lot.
Do you have this, maybe?
Or if not, you want to use this, maybe.
No, it's okay.
So what Maggie is going to show is,\Nas you say, as we said before,
we implemented the solution\Nfor automotive and also for a smartphone.
So Maggie has been working on the\Nsmartphone side of things, right?
So she has been taking the positioning\Nengine and then embedding it into Android.
So preparing all the libraries that are
needed to interface the smartphone,\Nwith the libraries also
making the campaigns, the test and\Nvalidation campaigns on the smartphone.
On the smartphone side,
smartphone is a more challenging\Nenvironment, as you will see.
It's the receiver.
So a smartphone doesn't\Ndo positioning, right?
A smartphone, what it has\Nto do is save battery.
Battery life, right.
So for this, it has to sacrifice GNSS.
It will sacrifice GNSS.
So the antenna is not great either.
So it's a whole different beast that is\Nsometimes difficult to tame, right?
Yeah, that's in the desktop,\Nyou have a demo.
You want the slides or the slides?
We have just three slides for you.
All perfect.
I think you can use this.
Fantastic.
Or it will not be that visible.
Okay.
So as Mikhail said before,
spear is an agnostic platform,\Nwhich gives us the opportunity to work
on different devices more\Nand less professional.
So on top of the C code with all\Nthe algorithms, we added the library.
In Java with basic interfaces
for the developers so that they can\Nlater on use Spear in handheld devices.
And internally,\Nwe're handling all the data reception
first, data management,\Nsending and receiving from Spear.
Actually, I would add one comment
to previous presentation of Miguel because\Nhe mentioned that the market is quite
competitive, which is true\Nfor more professional devices.
But I think in case of smartphones,\Nthe one competitor is just Google.
We have a lot of applications which are\Nresponsible for creating,
not articulate also, I think, but Ryanx\Ndata or reception of the signals.
But no one really created the algorithms\Nto receive the position in smartphone.
And why?\NBecause it's super difficult.
The data quality is not that good.
The overall data management, moreover,
like GPS chipset, is quite a black box,\Nbecause when we buy a smartphone,
we don't really have much information\Nabout GNSS in the smartphone.
Sometimes the manufacturers tell us about
the Constellations, but not\Noften about the frequencies.
And then data management also admit,\Nas I said, data memory consumption.
Moreover, the fretting,\Nwhich is also a big problem.
So that on top of all these layers,
I think many companies decide to create\Nthe products for more professional devices
because they are sure of the quality of\Nthe data rather than for the smartphone.
So that,\Nyeah, we make it more challenging for us
to create the positioning engine, which\Ncan be used across multiple devices.
But we need also some\Nindependency of Google at some point.
And especially we can focus\Non Galileo with the European project.
So coming back to Union,\Nwe run the test and store the logs so
that here you can see that\Nsmartphone connected properly to the Union
caster, received the data\Nand decoded the data.
And in the table you can see the messages,
the artisan messages and the amount of the\Nmessages received from the Union casters.
So we receive all the four constellations\NGPS, glen, Asbedo and Galileo.
Later on, they are being held\Nand processed in spirit.
Okay.\NAnd that's the real time solution.
I'm sorry, I might need\Nhelp to switch it off.
Okay, thank you so much.
Okay, so we do a lot of testing.
We do a static test because we have\Na permanent antenna in our office.
We use cycling tests,\Nautomotive test also.
But for sake of this presentation,\Nwe decided to make a test also nearby
in the Monguig and in the plus,\Nwe see two solutions.
One is from Android Fuse\Nlocation provider.
The other one from Union.
And
what we can see also is that Fuse Location\Nprovider is a mix of GNSS solution, plus
sensors, plus smoothing,\Nplus assisted GNSS.
So overall it's much more smooth.
But at the moment,
we are masterpiecing the GNSS positioning\Nengine
and we can see an extreme improvement\Nfrom the first day when we started using
the positioning engine\Nin smartphone till now.
And just worth to mention, because during\Nthe network, the networking session.
We'd like to invite you if someone would
like to go out and test\Nthe smartphone positioning engine.
We have pixel four that we're\Nusing a dropkobun.
We can go outside and we can do\Nsome tests if someone is up to.
Also just worth mentioning is like we\Ncheck the sky plots around here
and basically we have no visibility\Non the north side of the sky.
So in case another side is covered
by building trees, whatever,\Nwe can expect some accuracy decrease.
And now let me show you the video.
Okay, so also see it.
Thank you.
Also I can add that\Nthere's a realtime demo.
So we will see the solutions.
One is provided by Fuse location provider.
The other one from Sphere,\Nbut also Sphere.
Exactly.\NIt speed it up.
I was walking, but it would be too long.
So
the orange circle is our sphere\Nand default blue dot is
I think it's visible\Nand the blue dot is fused.
Location provider from Android.
We also collect data so we can do\Nreal time and post processing.
From my experience, sometimes Spear\Nprovides better accuracy than Google.
But as I mentioned before,
Google is much more smooth because that's\Ntheir priority, what we've noticed.
So we can also see that at the moment when\Nwe entered the park and we were surrounded
by trees, there was a moment when\NSpear got lost, but quite fast.
Cut the correct position again.\NThat's it.
Thank you.
Okay, so thank you.
I think that we have reached\Nthe end of the presentations.
I think that we are also a little bit
ahead of the schedule,\Nbut we can move to the questions.
If you have some of them,\Nwe'll be here trying to answer them.
So now it's your turn.
One at a time.
Yeah, sure.
Thank you very much\Nfor your presentations.
I would like to know how your system is
affected if any of the course\Nis down from the system.
The Paramedical reference Station,\Nyou mean more or less that's performing
exactly the same way that it\Nis performing for users.
I mean as the station.
If a station falls down,
so it's not able to provide the solution,\Nthe software in charge of providing
the solution just starts recomputing all\Nthe permanent VIP for reference stations
and start providing the solution\Nfrom the closest one.
It's just like any other user.
If a user is just working close to later,\Nbut the user fall down,
the server itself just change the station\Nfrom Avalanas for example,
which is the closest one, just to start\Nproviding corrections from this station.
So in the permanent and built reference\Nstations, it works exactly the same.
In fact, we did some testing just this,\Nlike this, just closing some station,
just checking that sometimes this\Ncan affect to 20 or 25 stations.
But just in, let me say a second or\Na couple of seconds,
all the permanent Ambitor stations are\Njust up again, this is why in the figure
is shown the data availability,\Nyou just see 99 nine or 99 eight.
This is the gap that we are\Nsuffering when station is down.
I mean we we were just checking what's
happening on this situation and we were\Njust seeing that the software was capable
of reprocessing this very fast,\Nbut obviously it requires some time.
Okay, thank you.\NThank you.
Any other question, please?
Yes, thank you for nice presentations.
My question is probably to both of you\Nand it's about portability
for a standard commercial\Nnavigation solution.
Would it make sense to embed Union on it?\NIs it possible?
Is it straightforward?
What's the stages of that?
At least from from our point of view,
I think that it should be feasible as\Nthe service is already there
and the software performing the permanent\Nvisual stations is already there.
But I think that from the user point\Nof view, Mikal, for sure we'll give us.
So there are two things to consider here.
One is the compatibility between\Nthe network and GPS receiver.
But as Joe was saying,\Nit's a standard RTCM messages.
So from that point of view\Nit's not a problem.
Everything should work out of the box.
Now there is a thing of embedding\Nthe whole algorithm into the platform.
This can be tricky because
even though we process low level and it\Nworking on an Arm devices,
there is still some work to do\Nin the sense especially if you want
to target to automotive applications,\Nfor instance, right.
You have to pass certain\Nrequirements of safety.
These have to be met.
But as a general rule,\Nas the state is of now,
it can be compiled and it can be\Nembedded and it would in principle work.
It depends also on the architecture\Nof the receiver itself.
Are you considering to extend\Nthe zone of Union out of Catalonia?
Not from our point of view at least,
because we are really faced in providing\Nservices here in Catalonia.
I don't know if in the framework\Nof the project this would be feasible
and I don't know if Rocomon\Nis thinking about it.
Yeah, the savior architecture.
We know already how an architecture\Ncan be built with permanent BRSS.
The natural step would go beyond probably\NCatalonia to the rest of the Spanish
territory where they have RTK networks,\Nbut they don't have such a system.
For instance, there are other\Ncountries like France for instance,
but they already have quite a dense\NGPS network receivers.
So maybe it doesn't make much sense\Nin that case,
but there are other countries that they\Ndon't have so much of a dense network.
And then it could be viable to go to these\Ncountries, maybe in the form of public
institutions that have already some\Nnetwork deployed,
and then we could leverage that or maybe\Nleveraging some privately owned networks.
Such as I was mentioned before,
the Swiss network Sweepos has already\Nan RTK network at its premium.
But it could be also\Nexported to that case.
Yeah.
Sorry, I have a new doubt.\NSure.
That's your turn.
We have been speaking about\Nan unidirectional service.
First you connect.
The system needs to know where you\Nare to provide your corrections.
So I imagine you need\Nto send your neme position.
How is it managed inside the system when
you are moving and you\Nchange your position.
So it needs to give you the information
from other different permanent\Nbeer to all reference stations.
This is in fact managing the utility.\NYeah.
So basically we have the source table.
The source table has all\Nthe mount points in the receiver.
I mean, so you have all the mount points
as well as the coordinates\Nof each mount point.
So the user can select if you tell it okay
one out of asing like\Nfor instance for one station.
So it would look at the closed mount point\Nand then attach to this mount point if you
tell it to be I want to be connected to\Ntwo or three simultaneous mount points.
It will look for the three closest based
on the source table\Nand connect to those three.
Does it answer your question?
So it is you the one that selects the\Nmount points where you want to connect.
Exactly.
Eventually the receiver decides\Nwhich mountain to connect to.
Okay.
Any other questions if not smuggie said?
Now we are having the some networking\Nsnacks just where we got the coffee.
At the very beginning.
And after that, if you want, we have the\Nharwer here just to do some life test.
If you are interested in this,\Njust let us know in the networking snack.
So we can just make a small group or\Nwhatever if we want to go, all of us,
and we can just\Nmove out just to show you and you can just
check it by your own or if you have any\Nother thing for sure we will be there.
Just come to us if you have\Nanything that we can address.
So I think that's all for the\Nworship and demonstration, more or less.
Thanks for coming here.
Thanks for joining us in the life event.
We hope that it was very useful
for you and and we'll be here just\Nin case you need to reach us.
Thank you for your time.\NYeah, thanks.
Institut Cartogràfic i Geològic de Catalunya. Generalitat de Catalunya. Departament de Territori.
Gencat
[Fi de la transcripció]