czech english

Spider3 Rider

Open Source Garden Autonomous Robot

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: 25/04/2023 — Speed control (stop and go)

Spide3 Rider


  • Milan Kroulík — project leader (CZU/TF)
  • Stanislav Petrásek — mechanics (CZU/TF)
  • Tomáš Roubíček — electronics (RobSys)
  • Jakub Lev — software/testing (CZU/TF)
  • Martin Dlouhý — software (

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 mowers.
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.

6th November, 2017 — Spider3 finally autonomously moved!

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 problem):

26th March, 2023 — Web refactoring

Note, that there was a "minor" web refactoring as OSGAR was further developed (mainly for DARPA Subterranean Challenge. The Spider3 Rider is currently pushed into world of fully autonomous robots and somehow I could not find dedicated artifle for it. So the original page was split into 3 and we will track them separately.
There are 3 new websites now:

25th April, 2023 — Speed control (stop and go)

Once upon a time there was a Spider … yeah, I could start with some fairy-tail. From older notes you can tell there "our" Spider is more than 5 years old. This is really hard to believe, but it is true. It is used for collecting data in orchard but the data collection is semi-manually. So what problem are the blocking points?
  • autonomous mode for provided firmware is only in spider mode, which means where all wheels are pointing in the same direction
  • the speed is limited to turtle, which means around 0.5m/s max
  • there is no speed control on the device
  • "gas control" is not symmetric, so if you return to 0, the machine does not stop
Yes, the last point is the main blocker. You can control power with int8 values, i.e. -127 .. 127 (not really sure what 128 would do, but I think that it is negative 0 here). Last week we did a couple of experiments and watched the response times.
I liked this picture even though it is not very useful. You can tell that the brown command has the opposite direction, there is delay of valves (0.25s?) and also before the robot starts to move. The speed is not really visible on this graph as it is a scale of left/right encoders to meters per second.
Maybe more useful is the stairs signal:
  • the two valves positions do not perfectly match
  • on the first step down the robot did not slow down at all
  • on backward motion the zero corresponds to visible non-zero speed
So the task for today is to stop …
p.s. it worked?! … I mean simple PI-controller:
err = desired_speed - self.speed
self.err_sum += err
scale_p = 100  # proportional
scale_i = 10  # integration
value = min(127, max(-127, int(scale_p * err + scale_i * self.err_sum)))
The first test was with 0.5m/s speed, move 1 meter, stop and wait 5 seconds, and repeat backward. Then I slowed down to 0.2m/s and changed wait to 10s so that it is obvious that the 650kg(?) monster is not moving.