OSGAR is a long term project which will probably incorporate more than one
robotic platform in the future. The project started in 2014 when we decided to
modify school garden tractor John Deere X300R into autonomous robot. The
project is carried on in cooperation with the Czech University of Life Science
Prague. Blog update: 21/10 — OSGAR v0.0.1 released!
The idea is relatively old — our garden desires mowing every second week and I
would not mind some „helper”. Yes, in meantime autonomous lawn mowers made
serious advance, but it is not only our garden and there are much larger grass
areas which require regular maintenance (castle gardens for example ).
In 2014 we also started school project, where self-driving tractor should cut
grass and regularly monitor trees in a orchard. You could probably use GPS for
basic navigation, but there are many obstacles (trees), which have to be
avoided. You would need sensors for this task and if you have them then you can
use them also for navigation.
This „orchard task” is similar to navigation in the row of maize field in
Field Robot Event contest. We already got some
experience there (and prices) with our robot Eduro. The
very first experiment was to take Eduro, mount it on the top of the tractor
and manually drive it through orchard to collect some data .
14th May, 2016 — Contest „Robot, go straight!”
The Czech season of outdoor competitions for autonomous robots begins in May in
Písek. It is called Robot, go straight!
(in Czech „Robotem rovně”) and autonomous robots should only navigate
straight on paved road in central park. The track is 314m long and only small
electrical vehicles are allowed.
In 2015 we asked organizers if it would be possible to make an exception so
that we could participate with our modified garden tractor John Deere X300R.
The permission was granted but we did not use it — the tractor was not
In 2016 it looked much more promising because the school tractor was supposed
to be at exhibition in Brno, one month before the contest. But there were
problems with hydraulics components and this exhibition program had to be
But we wanted to push the project forward! We joked with Standa and Tomáš, that
we can short safety switch under the seat and use it as emergency stop and then
just put brick on the gas pedal and version 0 is ready. Well, what I
did not know was that this „joke” will turn true and in reality we will need
it for homologation and the first run:
The contest is great. It runs all day (there are four runs), so we had enough
time to continue to work on the robot. In the second run the robot was already
driven by Python code and pedal was controlled via CAN bus. We even collected
several points and „good bye” joke was in the 4th run, when the tractor run
out of gas [we are so used to regularly check the battery status, but not
the gas — new experience].
The contest „Robotem rovně” was great, because it got us started. Finally!
But how to proceed? We were quite exhausted from the contest so we took a break
next Tuesday (our group meets up once a week). And then I realized that
contests are the only way how to push out project further, i.e. complete
steering mechanism. The only related contest (as far as I know) was
RoboOrienteering, but the dead-line was
deadly. We had to finish the robot in two weeks (mainly Tomáš and Standa). The
deal was set that if I can write navigation software in two weeks they will
have the hardware ready. And so we fight again!
The task for RoboOrienteering 2016 was to navigate to differently evaluated
orange cones (their positions are known few minutes before the start — the
teams receives USB disk with configuration text file), and drop there golf
balls. There are two radii: 2.5m for double and 5m for single score.
Version 0 — the simplest thing which can possibly work — was here much
harder. If nothing else to score a single point it was necessary to have
integrated GPS, functional ball dispenser, and also robot had to be able to
avoid collision with obstacle (part of homologation).
My part was relatively easy — if you do not have any feedback data (encoders
or position of steering wheel) then your program has to be very simple. My
primary goal was to integrate new sensor
Velodyne VLP-16, so the first tests
were simple collision detection and STOP, something we wanted to have already
You can have a look at video from the first
outdoor test. It was not perfect. You can see „gaps” which corresponds to
dropped UDP packets, and at one point you can see tractor jumping back when
obstacle was detected. There was a non-trivial lag between reality and
Yes, there was a bug in (my) software. After the program start it was waiting
for start button. The Velodyne socket was already opened but I started to read
it after button was in on position … well, fixed, no so many things damaged,
ready for competition.
The tractor first autonomously steered just few hours before the contest (we
arrived in Rychnov at 1am and started testing at 5am in the parking lot. So far
so good. Unfortunately none of us is expert in hydraulics and we did not know
that there is too much pressure in the system. It broke during homologation (it
was bit uphill so I had to increase the gas) — but over the day Standa with
colleagues somehow magically managed to fix it even without proper tools. [now
it is revised and working fine]
Standa sent me link to very nice descriptive video how transmission works in
our John Deere tractor:
16th May, 2017 — „Robotem rovně” (again) and the first garden test
Last weekend we participated in contest
Robot go straight! in Písek. It was
primarily show how far we moved since the last year (brick on pedal to pass
homologation). The sensor set was: odometry (encoders on front wheels with
position angle of the left wheel), GPS used for reference, laser scanner SICK
LMS100 and dual IP camera with wide angle lenses. For the first two runs we
basically tuned the steering and collected real data of the environment. In
the afternoon we added simple correction from camera data to avoid green areas
(yes, this is a bit strange for lawn mower ).
The second day we tested our newly developed „cones algorithm” in the garden.
For version 0 it is sufficient to prove that we can repeat given pattern 10
times (or better infinite times, but we do not want to wait so long). You can
see it on the video bellow. We tried also to turn the cutting mechanism on,
but surprise surprise John Deere turns it off whenever the mower is in backward
motion. So we switched to a bit boring oval and did some experiments in higher
Please forgive me the quality of the video — it is taken by digital camera 12
years old (which is still good for pictures but not for videos).
11th October, 2017 — Spider 3Rider (first tests)
There was no update on this blog, but it does not mean that there was no
progress in last 6 months. You can check
github, that there was some activity over
the summer and also traces, but only some of
them were uploaded. Nevertheless, what I wanted to write about today (at least a
paragraph) was about Spider 3Rider, which is another machine we are
preparing for autonomous navigation.
You can have a look at
introduction video (in Czech).
It is very nice machine where each wheel is steered independently, and it
supports car like" and spider"" modes. Spider3 is already 3rd generation of
successful radio controlled slope
The original machine was modified to support also control over CAN bus, and
thus allow autonomy mode. While we are still struggling with the full
control (note, that Spider3 weights over 1 ton, and you do not want to make
stupid mistakes), we are already able to collect data from manual drive.
On the following picture you can see angles of all 4 wheels. Their position was
printed only on change, so it is „compact graph”.
You can see that the resolution is 9 bits (0 to 511). In the middle of the
graph you can see an experiment when we tried to twice turn the wheels for
360 degrees in spider mode.
18th October, 2017 — Mapping cones (ver0)
Yesterday we collected some data with autonomous John Deere for creation of a
map with positions of traffic cones. The traffic cones are used both for
definition of the area where the robot should perform mowing and also for robot
localization. Currently the laser scanner LMS-100 is still used as primary
measurement sensor and camera as backup.
The navigation algorithm for version 0 was quite simple:
select cone which is in front of you
steer wheels towards the cone
while the distance is more than 2 meters go
otherwise turn 90 degrees left and repeat
Sure enough we expected that this version will not be perfect, but the basic
idea worked quite fine. We managed to run only 3 tests before the nightfall:
one in front of the CZU machinery hall on the street and two in the test field
area parking lot. In the first test there were the cones placed too close to
each other and JD did not manage to turn and align to the next cone in time. We
faked it with „moving cone” to return semi-autonomously back to base.
The other tests on the small parking are were more interesting. In particular
the choice in front of you defined as the closest angle to straight line was
not very good. A small tree trunk as well as strong steel cable supporting
some construction were, from laser point of view, classified also as cones. So
the robot moved towards them instead of the original cone. Next version will
have to take into account also distance to the detected "cones" and ideally
verify them with camera.
The traces as well as the code are publicly available:
You probably noticed that there is a new contest for outdoor autonomous robots:
Robotour Marathon 2017/18. In order to
participate, your robot has to be able to autonomously navigate on paved road
mapped in OpenStreetMap. Jakub and Standa
recorded last week following video:
Note, that the video was cut, due to human intervention (you can download the
whole log file here). For
navigation was used
from the last year.
In general, autonomous navigation from point A to point B is useful also for
small garden robots, so hopefully you will see some updates there next year
Yesterday was the D-day for our Spider3 Rider, which finally (after 2 months?)
autonomously moved. It was a small step for a robot but a leap for robotkind!
Yes, sure enough it was hacked to get it moving, so what you can see in the
following video from Martin S. (our new team member) is: for 5s set value to
50, for 2s stop (set value to 0), for 5s set value to 0x100 - 30, for 2s stop
(set value to 0). There was manual emergency STOP (remote) at the end … you
may notice that the robot was still moving although the value was set to 0
(TODO configure properly the center position).
Now should come the fun with omnidirectional motion, test of Spider vs. Car
mode, integration of encoders etc. There is new GPS RTK sensor and
SICK TiM 571 (yes, we already recived
Christmas presents ) to be integrated. Also
Velodyne should be hopefully soon
recalibrated in the factory (I wonder how many Puck 16 in the world have this
The OSGAR package was released today for the first time — see
https://pypi.org/project/osgar/. It contains the basic functionality for
logging of various data sources together with replay feature. This initial
release supports John Deere and Spider3 (both quite uncommon, I am
afraid), but more will come soon, I hope. If you would like to try it on your
robot, please let us know. The step 1 is to describe your inputs and outputs
(both the devices configuration as well as the communication protocol used).