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
Team
- 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 (robotika.cz)
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:
Observations:
- 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.