Okay, so everyone, first thing first, as we say on social network, I'm thrilled to announce
that that's the very first time we talk about this, okay?
So, feel free to give us a lot of feedback after the meeting after the presentation, okay?
So, today we will talk about the technical stack, so I will present bottlenecks really quickly
the product as well, which is XE, and then we will dive directly into the technical things.
First thing first, let me present the team, so I'm Antoine, I'm the CTO and co-founder of
Botronics, so that's why I started with some gray air.
Then you have Enzo, which joined Botronics early in 2024, is one of our monster in navigation
and Rostou, and then we have David, who joined us in September, 2020, to divide straight
from the ULB, so, from this university.
Okay, so let me present Botronics, as you can see, with a slight template, we are a startup.
We found Botronics in 2022, we are, of course, in Belgium, or it quarter is in Nivel, in Dutch
which we say in Nivel, right, that's 40 minutes from Ian Vicar, and yeah, we just closed,
so that you know, or situation, we just closed the seed round of 1.6 million rubles in September,
2020, 25, we are only 10 people right now, out of them are engineers, and yeah, we basically
love open source, we contribute to it in different ways.
One of the ways is that we are a friend of NAF2, it means like, that's a pay-sponsorship
of NAF2, that's a way to pay for, I mean, we pay for smart and people that I am to contribute
to open source, then yeah, some of us are always a super thing individual, so it means
you pay annually to sponsor the organization behind Rost, and then you contribute to open source
as well, so we do code, so we participate to all the tutorial and tests, parties, we build
some Rost packages, you saw Christoph and Nicolas before talking about some packages we
built, and then yeah, in October last year, if you have from Belgium, you may be know
that we create the very first Rost-Metop in Belgium, okay, then so it was Botronics and Botronics
built XE, so this is the product, this is the first ever autonomous gold trolley, so you
have to know that goldfills have to carry their bag when I play gold, that's 20 kilometers,
that's five hours, so that's quite painful, and that's why when you are more than 50, that
becomes quite difficult, so they play with a gold cart, that's not really a gold cart,
that's a trolley, really a trolley, okay, we sold 300 units in codefunding last year, and
so now we are in the industrialization phase, so bringing the prototype to product, okay,
and the final price we are really on a premium product, so that's something like 5,000
euros in the end, let's talk about now the product constraints as a robotics engineer,
right, so you see, let's talk about the features of XE first, so that's a very first
gold trolley with a large core of touch screen, okay, so that's really something important
for this touch screen, and then you have some mechanical constraints as well that we want to
push forward, like the stability on the golf course, there is a lot of steep slope on golf
courses, so you have to deal with them, and then of course we have a camera, which is AI power,
let's say so it means we can do a lot of stuff based on this camera, we have three main kind
of features I would say, the first are the autonomous things, so it's able to go to some point
of interest on the golf course, so they are able to go to the next E to the green and that kind
of things, then you have a lot of seamless interaction things, so for example, if you want the golf
trolley to follow you, you can put your end in your back, the trolley, recognize your end and try
and start to follow you, okay, and then you have advanced features like filming your swing,
giving you some advice and so on, and this is a B2C product, so it's really a constraint,
it brings some constraint at least, so for example, the price, so the final price is 5,000 euros,
the 18 included, right, so if you remove the VAT, you add something like 4,000, and if you consider
after sales, if you consider stock and so on, while the bill of materials become something really
important, right, so we can't afford expensive sensors or solution, we have to avoid initial setup,
so let's imagine this is a B2B product, we saw it in the golf courses, we can go to the golf
courses and say, okay, we need to push an airtica, an airtica, docking station, and then we can do
a slam manually or that kind of thing, we can't do this because like, or trolley,
they will bring the it to different golf courses, and then of course the user experience must be
really, that's a premium product, so from day one, you have to provide something really reliable,
that's also a node of robotics, so you have some constraints linked to this as well, okay, so
now we talked about the product, it's dive into the technical stack, and so we solved, that's basically
a technical stack, that's not a architectural diagram, right, that's a slide, but that's basically
what we'll talk about today, we'll talk about the user interfaces, there is two kind of user
interfaces, there is a mobile application of course, but there is also this embedded screen,
and then of course we will talk about the co-application, the embedded application,
we will talk about one important capability, we provide which is the remote update capability,
and then some additional things like testing and observability,
so we're going to start with the co-application, without too much surprise, it's based on Rostu,
and so why the choice of Rostu, so first of all, it's open source, I think it will not be too
difficult to convince you that it's a huge asset for a solution, for us it's mainly on the fact that
we have control on the solution, we know what's inside, but other capabilities and the limit,
and so we have a more possibility to master it, also Rostu has a really large and active
community, and for us it's a huge asset, there is a lot of features, a lot of package available,
and also it's really easy, I would say, easier to recruit and expand the team,
that we have a fully custom solution, and you know, everyone needs to retrain and to be
re-informed about it, and it's more durable, it's designed, and it really allows us to
expand the stack and I think to skate it properly with a different update, as said in the previous
talks, Rostu has some limits, but for example, in our use case, we don't have a real
real-time constraints, I don't know if you have already seen a golf play, but it's not the
constant sports to life, so I would say the odd real-time is not something really to blocking
for us, the non-distarmistic behavior is not also a big default to the same reason, so yeah,
so about the version of Rostu, so we are using Rostu jersey, and so we have done a release
some migration, we start on Rost1, we have Rost Noetic, we migrate to Embell, and more recently
we have done the migration to jersey, so the migration subject is something really important,
because it can take some times, it's challenging every time, or you manage your dependencies,
or you are able to, you know, make scale, you stuff, and so we have made the choice to make
a frequent migration, to have access to the Rostu features, and also from the package,
we have done some contribution in a different project by the past, but we are a bit limited,
because, you know, for example on NAF2, if you want the last feature, you need to target the latest
release, otherwise you need to backport a lot of things, and so in the end, the gain of time
to stay on the same release, it's not always evident, so for the moment we only target the LTS,
but because we have some, you know, we are working with CUDA, that gives us a lot of capabilities
for AI models, but in the end it bind us a bit with Ubuntu, Jetpack version, that depend on Ubuntu
version, and so we have explored your CID before, that with Pixi, we think that we could simplify
your migration process for the next release, so that's why we are trying to do, and the next
release to be able to target the LERIC cloud list for the next release LTS. So Rostu, as I said before,
it provides a lot of out-of-the-box features, such as all the wrapper for Python, C++,
also the Rostu controls suite, that's a really help us a lot to gain a lot of time to
know, start experimenting with the robots, integrate the hardware, interface, and
also the community project that you will see after in the presentation as some core of our stack,
such as NAF2, a robot localization, and in the end the Rostu framework, it really gives us
a kind of guide line and a standard way to integrate our custom business logic for the sense
of driver, and also for all the business related to how we put our navigation
behavior at the top of the stack. So yeah, there is a new monster in tone, right? Let's talk a
little bit about RMW and our choice and in fact, our journey. But first, that's only based on
our experience, okay? So we have an experience with the localhost only model, meaning that
all our nodes are running on the same device, okay? When we start, so we migrate from Rostu
from Rostu, to Rostum, and we start with the default DDS implementation, which is
fast DDS. We try to use it, but in the end we run into a bug with the integration with Rostu
control at some point it stopped, and so we try to figure out what's missing, and at some point
we are like, okay, we open some issue and get up, but didn't find the solution, and at some point
we say, okay, maybe we can just try cyclone DDS, that's what we did, and in fact, we cyclone
DDS, we were really happy with it, we had some configuration issue at the very beginning,
but then at some point it was working really cool, so we worked with this during like two years,
but then we wanted to explore shared memory, okay? And at this point we found some issue to put
shared memory in practice, and that's why in fact we decided, okay, maybe we should try with Zeno
to see if it's easier with Zeno to use the shared memory, and yeah, it's quite easy, so that's
four months ago we moved to Zeno and now we are using Zeno and we are really happy with it and we
won't move anymore, I guess, right now, until the next solution. There is three important things,
the first thing is that yeah, that's really easy to integrate the shared memory even for dynamic
size messages with Zeno, then we win 10% CPU usage just by moving to Zeno with shared memory,
and final thing is the initial setup is really easy, I mean you just have to change some
environment variable, and then you have something working, of course we can still optimize it
a little bit, I mean for no, for example the shared memory size is not optimized, but it definitely works,
and so we can move on, and now that we talk about the value on top of this, you have everything
regarding sensors, so let's share some guidance and experience we have, some people call it
pain, but that's experience, we have with sensors, for some sensors you will have
host two drivers provided, and that's great, that doesn't do everything, but that's great, okay,
for other sensors we have some cheap sensors because of the final price, and in this case you don't have
any host driver provided, in this case we recommend really a reader, a RIP, which are good guidance
provided by the host community, to implement your host to driver, okay, so that's really
something that's not easy, don't underestimate this, but do this with RIP, in mind it will be easier
than to implement and to integrate the host to driver with your whole host tag, that's definitely
not always plug-in play, even if you have the host to driver implemented, I mean at some point we had
to configure the kernel to integrate a new sensor or to install some driver, so that's not
a low level driver, the host to driver is a high level driver, yeah, we also had to
patch the kernel, it was to integrate 12 Bluetooth working with multiple devices at once, so that's
something you will have to do in the end, so really when you estimate the task of introducing your sensor,
don't underestimate it, in any case, well what I suggest is before diving into the, okay,
there is a host to driver, let's use it and it works, no, hit the datasheet, understand it,
try some basic tests without choosing a host at all, and then go step by step,
okay, thank you, Antoine, so I guess now everyone has a clear idea of the quote Hardware is hard
and now let's talk about the fact that even though you have achieved that point where you can interact
with your hardware, you're still not finished yet, so basically what we advise you to do after
to check your data, for instance, we were working with GPS and we simply weren't understanding
why our robot wasn't getting this data coming from our GPS, by looking back on the message that
we were getting from the GPS, we were seeing that in the header message, actually the data was
correct and the time was correct, at this time it was long time ago, we didn't have any RTC on
our trolley and hence from our robot perspective, this message is coming from the future and it's
simply this regard, this message, second tip, visualized your data, in our case we use plot
juggler, shout out to David Fagonti, botronics love you, so if you don't know plot juggler,
allows you to visualize your topic dynamically and even analyze them, it's really, really good,
a really good plugin, and the last recommendation is don't be to bind it with your hardware,
and when I mean what I mean here are two things, the first one is from the sensor perspective,
don't get a sensor that is a jack of all trade, you will have a lot of trade-offs with this,
for instance, at botronics, we were using a GPS that was also a magnetometer,
having this GPS, so obviously the GPS has to be in the upper part of the trolley,
but unfortunately we have clubs with iron, which implies that we will have magnetic disturbances
or magnetometer listen to, to the magnetic field obviously, the second one is to avoid the
all-in-one SDK, obviously take for instance cameras that come with a pre-made SDK that does
object detection and tracking, we don't want to bind our software, we really want to have a
hardware-agnostic software and isolate our piece of software every time and having a
piece of software that depends on our hardware is not the best idea.
Okay, now that our sensors are working well, we can think about the localization,
and for this we rely on the robot localization package, so we will not dive into too much
detents here, the big overview of the framework is that we have some relative
measurements coming from certain sensor, let's think about the IMU, for example, or the
odometry of what else. We will fuse those sensors into an extended
Kalman filter to have a note put related to the displacement of our robot.
Afterwards, we will have our GPS data that is being given in a lower frequency.
We want to fuse all of these and make the use of the NAVSA transform in order to transform
this position into UTM frame in order to have them in Cartesian frame, and as a product we have
basically the position of our robot.
And so more specifically, particularly on what we've been using and some advises with the sensor
that we've been using. In our case, we use a stereo vision camera which implies that we can use
visual odometry. In our case, didn't work quite well because of the fact that there are many
features in golf fields. Obviously, we have some trees and nothing else.
Yeah, we don't rely anymore really much on this visual odometry. Another fact is an important
in our case is that we ship our trollies in many places on the world. Obviously, the magnetic field
is not everywhere the same and we have to think about this magnetic declination, obviously.
And so what we had to do at Botronics for XC is to dynamize a dynamic magnetic declination that
is computed based on your position on the earth. And obviously, the magnetic field of the earth
changed with time and obviously we have to recompute it each year. And the last part is related
to the fact that we have a B2C product. As Anton mentioned, we cannot pre-install devices
on the golf field. And so a challenge is to compute the initial pose of our trollies. So when
consumer uses our trollie, if he wants, he doesn't want to calibrate anything, he just wants to play.
And that's a big challenge. And so the big lesson, let's not say related to the localization,
is make sure that your localization is reliable before diving directly onto navigation. Since navigation
rely assumes that your localization is perfect. If you have issues with your navigation, it will
probably be due to the fact that your localization is not good also. So for the navigation, we are using
Neptune. It's a really complete framework. It provides a lot of advanced features out of the box,
which is basically me when we switch to Ross 2. And so when I look at the Neptune instead of move
base. And so it provides a lot of out of the box features such as planar controllers and collision
monitors that provide safety software. So it's highly modular and it relies on Baviotry and it
helps us a lot to manage the concurrency between the different Bavios and also provide the capabilities
to use custom plugin. It's really important for us because in the end, at some point you have
the choice to make all your custom logic, implements you know, every new Bavior from your part.
And we make the choice to rely on the plugin, the plugin configuration of Neptune. And it gives us a lot
of flexibility to manage our stack. And it's as it's a complete framework, it provides a lot of good
practices. And to propel to that and to behave your trees in January, make something robust and
really reliable. Also, it's a really well maintained project framework. It's quite popular. There
is a lot of new features, update, backfix. So for us, it was definitely a good choice from our
point of view to rely on Neptune. So how we use Ross to a Neptune in the XC case? So it's quite special
because it's other robotics. We rely on GPS. I said David before. And we don't do slam. There are
not some that much features on the golf course. And we have the chance to have a full data set
of the different golf course around the world. So based on the loud static map, we process them,
make them available for the robot. And as we know, basically, the GPS position of every of the
circles on the golf course, such as the burn curves, the ponds. But also kind of a semantic
of circles, such as the greens. And the starting areas is particularly not obstacle, but more restricted
area. So based on that, we are able to manage our navigation only from that and from that too,
to positions at Mesf map, based on the initial location of the robot. We also use obstacle avoidance
based on vision. And as Antoine said, we cannot afford a 3D LiDAR of this kind of thing for the
application. So we had to be smart about the computation and also reduce it. So we have only a
front camera. So we have only a small field of view to detect the obstacles. And to save
computation, we use depth to let us cancel. We compute the depth image from the camera to let us
cancel to have it to the understanding of the environment. And we use a special temporal
layer to make sense of it and take the most that we cannot this relatively limited field of view
to understand the obstacles. And the custom plugin, we used it a lot during our development.
I think the best example that we have is the follow feature. It's basically, you see, we have the golfer
here, is a follow by the caddy because you don't want to take care of it all the time. And so
based on vision, we perform this following. So we integrate it as a custom plugin. So we have a
custom behavior tree and an navigator to be able to have no balance between going to goals.
Following and don't have concurrency between this behaviors. And we take a lot of benefits
from this choice because relying on that to it gives us a lot of feature integrated on it,
such as the access to the cost map, to the localization and a lot of features that
in the end really help us to integrate new features. For example, the collision monitor for specific
behaviors, the fact to detect some features such as the bankers to be sure that even if you are
supposed to be followed in the restricted area, it's going to stop. So in the end, you really
expand what we can do on this custom plugins.
Okay. So as Antoine said, for the follow, we're basing ourselves on a computer vision stack.
So the idea here again is to have a hardware agnostic software. We know that specific is the case
from specific cameras provide an object detection algorithm and a tracking algorithm.
But in our case, we wanted to do it by ourselves. And for instance, for the object detection,
we used the yellow model that we've tuned to by applying transfer learning. So we just
trained the last layer of the model in order to fit our data, which is golf specific data.
So we have, obviously, we have human. But we also have the backhand that triggers a follow.
And we also have the better, which is some kind of golf club.
Concerning the object tracking, obviously, your object detection model doesn't make any difference
between Antoine, which is at the left and a quick stuff, which is at the right. We need to use
an object tracking algorithm. In order to assign an ID to this person and also to estimate the
next position at the next frame of this person. To do this, we rely on the open source,
bots are tracking algorithm. So now, let's talk a little bit about remote update, which is called
OTA update for Overture update, right. Let's talk about Ojourney again. So we rely on an
envidiate JSON. So basically, envidiate JSON provide the jetpack, which you can see in a custom
Ubuntu-like distribution provided and maintained by Nvidia. It provides some Overture capability.
We start with it, but at some point, we are like, okay, we don't want to depend on
Nvidia lifecycle for the jetpack. And we don't want to depend on the hardware, in fact, for the
Overture capability. So we were looking for something else. We found the OCTO as a lot of people
in this room. We start with the OCTO. It was nice, a full-time job, to maintain it. So at some point,
we were like, okay, we capability with Mender, which allows us to do the Overture update. But at
some point, we were like, okay, we started with, don't want to have a full-time job to work on this
image. Of course, that's really optimized. That's really something interesting. You only
ship when what you want to, to have a turn-time. That's really great. We had some issues with it,
but that's okay. But we were like, okay, that's really, it takes too much time. And then,
okay, we say that maybe we should create a simple YCTO image and install the Docker engine in it.
So that we can render Docker in this YCTO simple image. That's, and at some point, we were looking
on the internet. We find Ballena, which definitely, that's the purpose of Ballena. So that's why
we, we know use Ballena. So Ballena is quite simple. That's a basic YCTO image. That's, this image is
open, so you can modify it if you need. But at a finger cross, we don't have to right now.
We don't want to return into this YCTO hell. And yeah, that definitely docker on top of it.
So that's definitely what it provides. So that's really what we use now. And it provides also
Ballena Cloud, which is not a free solution, that's because that's a Cloud solution. But it's
relies on an open-end giant, which is open-source. So yeah, that's definitely all go to solution
right now for this God-for-e. And the one important thing is that because of the Bitosy product,
we have some requirement like the, we need the user to confirm when he wants to make the
update. So that's really something we had to customize Ballena for this a little bit.
So that's definitely a development flow today. So it's quite simple to understand. We rely a lot
of on VS Code Defcontner for laptop or laptop as on Ubuntu, at least for the developers. And with NVIDIA GPU,
so that we can test the model. We have ONN and X models, so other independent model, but in the
N, we have to convert it to TensorFlow T, so that we are other dependent, but really optimized
model. Then we deploy them to the Def-for-e, which is still based on the Defcontner in VS Code.
But this fully is based on the Jetpack. And yeah, we have a clean SSH configuration we share together.
And then only at this time we deploy to Ballena to make our test at this point, the only difference
might be some small differences in the kernel itself, because yeah, of course, Docker relies on the kernel
installed. So let's move on our testing pipeline. So this slide comes from the Roscon 2025.
I'd love to have the best testing Pyramid pipeline with the cheap test is first.
And at the end, we have the test on the real robot. Today at Botronics, unfortunately,
we are following the right one, which is do a lot of things, not on the robot,
after word test on the robot, and do a lot of tests on the robot. We obviously want to change this.
We want to follow this Pyramid. The team is growing, it makes sense.
Nowadays, to change it, and we're working on to change this testing pipeline.
So obviously, to have a more robust testing pipeline, we need to have a robust simulation environment.
As of today, we have localization and navigation that is implemented in to navigation.
Unfortunately, the vision stack, so the computer vision stack isn't yet implemented in our
simulation, so we cannot simulate for a loss. For example, as you can see on this gazebo screenshot,
the dynamic of our robot is an really well explained on simulation, but we're working on it,
obviously, and we want to upgrade all these specific points. So the test on the field,
what do they look like? So today, we have two kinds of debugging. The first one are the
live debugging, so we can use graphical user interfaces such as RVs and plug-jigler that it's
forgotten. And the RQT over VNC, so that on laptops, we can directly visualize what the robot sees.
Afterwards, what we also have since our CEO plays golf, he goes on the field and tells the
trolley, what we've implemented is a button on our UI, on our mobile application. And by simply
pushing this button, he can report a bug, and we've implemented custom bugs with rolling windows,
so that we have a bug that takes what was happening sometimes before, and what was
happening sometimes after the bug. Afterward, he only has to plug the trolley to
internet, and we can directly download the bugs through an essential channel.
So no observability. Well, basically, we implement the X-Tack, which is famous for telegraph,
in FixDB, and Grafana. It is what happens in our trolley, so you have two different things,
you have the embedded with what is returns on the trolley directly, and then you have cloud,
which is what runs over the internet, right? So the main piece is on the embedded devices telegraph,
telegraph, super, two kind of input for trolley, to big kind of input, which are telegraph input
that are plug-in, that you set to collect data by default, like CPU, disk, and that kind of thing,
and then we use ROS diagnostics, which is the famous package to collect other
diagnostics, and we send it directly to the telegraph, and telegraph provide two kind of outputs,
which are file, and then on the other end, directly to In FixDB, which is a time series that
is, and then you have Grafana plugged on In FixDB for dashboard. There is several interesting
thing here. About ROS diagnostics, it provides several things. First, a user interface, we can access
directly offline over VNC on the trolley, so that we can see what's happened. Then we have two kind of
diagnostics, with ROS diagnostics. One is common diagnostics provided directly by the package,
that's some note that collects like the shared memory usage or the kind of thing, and then we
implement custom diagnostics so that like covariance for GPS or status for a mandatory
and that kind of metrics, and then we rely on a new ROS diagnostic package, which is the
diagnostic remote logging that allows us to collect metrics and send them directly to telegraph.
On the output, the In FixDB is quite normal, but we have also a file output, because at some point
we have some trolleys without any internet connection on the field, so it allows us to have
everything in a file when it's needed. In fact, that's quite an unusual way to use it,
is that we give this file to an LLM, and it gives us what's wrong with it. It quite work well.
That's really something like Artisanal, I don't know. But in fact, it helped us
exploring tool by tool at the very beginning. I think at the end this file will disappear,
but right now it allows us to set telegraph and then consider the internet connection,
stuff issues, and so on. So that's really why we choose this. There is one important thing on
why we choose the tick stack is also because of the pricing model, which is a pricing model
oriented on dollar per megabytes or by queries or something and not by device, because of the
B2C product, most of the time, a pricing by device is quite expensive for us.
So we are building a B2C project, so there are the question of user interfaces,
and we have two user interfaces, we have a mobile application and one running locally on the screen.
So basically, the general takes that we have is a key crossover away from your UI.
Because in the end, we are developing this application, we want to keep them as standard as possible,
and we don't want to require robotics developer to maintain a web app. You see the logic behind.
It's quite clear, it's easier to maintain, it keeps something as the architecture of the application
standard, and in the end, we are able to separate the concern. We can change our solution
and keep the different stacks separated, and just to rely on bridge to communicate between them.
So for the mobile app, it's the first step that we have developed, and we have tried a lot of things.
We start with the classic Rost Bridge Server plus Wi-Fi, and in the end, we have observed
that it's not suited for B2C, because people don't point on the normal operation to connect
on the not spot, don't have the 4G access on the iOS, it can be a bit complicated.
So the not spot Wi-Fi solution in the end for our configuration was not optimal, so we tried Bluetooth,
and so we went to Bluetooth Classic at first, and we have again iOS, there is a bit of issue,
with a certificate, and it's not as well maintained as BLE, so we moved to the BLE, the Bluetooth
low energy, and it provided really good performance of what we are doing, and for the moment
we're using BLE, which is a Python library, but we're exploring a Rost option blue R, and maybe
it could be the first use case for a R-cell address in our stack. So that's why we are deployed on
and so we have basically by the end with this choice, something relatively classic, a
rack native application running for the UI on the phone, and a kind of Bluetooth API to communicate
with our stack, and so a Bluetooth API on the Rost site to communicate and just give the query.
So we have also observed interestingly that there is no Rost from what we know, no Rost to package
using Bluetooth, so we had to make something about something like that, and for the tactile application,
we have well connected directly on the device, so we have just a web socket, it's wired communication,
so we have a web socket, we have a stack with RGS and electron, so in the end is a desktop application
running on the device. With this stack, we achieve to make something reliable, easy to deploy,
we are running it into a Docker, so it's just another container on our Balena configuration,
and based on the APMage, in the end, it's quite easy to deploy and push new images, so in the
end we are quite happy with this stack. We have designed a custom web socket instead of relying on
the Rost GGS for the reasons that I have seated before. So basically this is the end of the tour for
stack, so we are up into question, as Antoine said, it's kind of the first time that we present it
like that, so we are up into feedback and question to the top, so thank you in advance.
Thank you, thank you, Enzo. Thank you, everyone. One last thing, thank you for being here,
as a robotics enthusiast, we love seeing that much people engaged in a robotic, and we also
want to contribute to this robotics ecosystem, especially in Belgium, and I can say that
I have the honor to announce you that we are for the first time in Belgium,
opening the Rost GGS.
So save the date, it will be on 25 and 26 November, this year obviously, so we're Rost GGS,
it will be held at Nivell, so as Antoine said, it's 40 minutes away from here, Brussels,
and it's something really important, it will be held in English, because in Belgium we don't know
which language to speak, we have. We've made a common agreement that English was nice,
and we're obviously looking for speakers, feel free to contact Antoine, and we're obviously
also looking for sponsors, again feel free to contact Antoine, and that's not finished yet,
second announcement, we are hiring, so as a senior robotics engineer, you've seen another
view of our stack, if you think that it might be interesting to join our team, feel free to apply
on LinkedIn, and yeah, that's it, you can have a look at the job desk on LinkedIn,
and obviously you can question every single member of the team concerning the job application.
So yes, thank you everyone, we are open to any question.
Hello, thanks for the presentation, thank you, just wondering what kind of
certification was this required as a product?
Well, I think that the basic CE certification, right, so there is not a lot of direct machine
because we don't fall in the category, we fall in, of course, in the category of the machine
directive, but we don't have a lot of big constraints, I don't remember the kind of category,
because I'm not the safety expert, right, but that's not that big, yeah, we don't have to,
we don't have real-time big constraints.
Also, as a golf course, it's a private environment, and we don't fall in the configuration of a vehicle,
for example, so we don't have, you know, I would say the difficulties that could have
autonomous car, for example, on thermostatification, so it's way easier for us.
I hope it understands the answer to the question.
Okay, I had a question, did you ever have a problem with the trolley that's bricked?
It can't, like, note a failed and it overwrote some boot sequence or something like that,
and you had to go and fix it, do you have special, something special to prevent that sort of thing?
In fact, we rely a lot of life cycle on life cycle node, so life cycle node, that's for the boot.
Okay, yeah, we rely on life cycle node, we have a lot of diagnostic as well, so that we can understand
what's going wrong, that's why we have some magnetometer status, for example, because magnetometer
is one of the things that can fail quite easy, so we have to monitor those things, and so that we can
and the same for the covariance of the GPS, the GPS covariance will allow us to say, okay,
there is an issue with the GPS and so based on that, we have a node that is able to
deal with it and to say, okay, I can't do autonomous navigation right now, that's an advantage,
we have is that in fact, we are, the goal trolley is always with its golfer, it can be at
100 meters from its golfer, but it's never something like, okay, it doesn't work and it
is always an hours in place, no, because the golfer will say, okay, I can take it remotely,
if needed. And also we have, it was described quite quickly, but we have also this all V and
C debugging sort of stack that allows together data from the field, and so we can do basically
remote debugging as a support, so it's really, you know, it's wasn't spared a bit by the
all this like experience, we know if the remote support. Hi, just that a quick question,
I mentioned using Belena for the OTA updates, but I was curious, do you have anything set up for,
do you have a standardized kind of build environment for building releases or do you currently kind of
do all the release management manually and how does that see I and release them inside work?
Well, that's really linked to the testing Pyramid. Right now we are doing it on a server,
we have, but yeah, in the end we will have to build it in a CI and GitHub, we'll use GitHub,
but yeah, right now we are doing it on a separate server that's already something, but
definitely we need to go one step further now, you know, that's start-up life after all.
And yeah, we're a team of really few robotics developers, so next release.