Field Robot 2025
Milano, Italy
Field Robot Event 2025 (FRE2025) will take place in Milano, Italy, from June 9 to June 12, 2025, at Agriturismo da Pippo. This competition is open to universities worldwide, offering a unique opportunity to push the boundaries of autonomous farming and agricultural robotics. Blog update: 30/05/2025 — CULS Robotics Team Blog (week7)
|
Official announcement
Competition Challenges FRE2025:
- 🚜 Task 1: Autonomous Maize Field Navigation
- 🌽 Task 2: Autonomous Maize Field Navigation with Cobs Detection
- 🍎 Task 3: Fruit Mapping
- 🍄 Task 4: Bioluminescent Fungi Discovery
- ✨ Task 5: Freestyle
💡 Want to compete? Registration opens on March 3, 2025, and closes on April 25, 2025. The registration fee per team will be announced at the opening of registration.
🤖 Seeking sponsorship? New teams can apply for sponsorship to support their participation, with funding up to €1500 per team by CLAAS-Stiftung. More details and application link: https://www.claas-foundation.com/students/field-robot-event/application.
📢 Have questions about the rules? Join our FRE2025 Discord server now to get updates, connect with teams, and participate in the Q&A discussion: https://discord.gg/56unzZVBqn.
Read the rules now!
🌐 Website Update: Further event details will soon be available on our website: https://fieldrobot.nl/event/
📍 Getting here: The event venue is 12 km from Milano Linate Airport and 17 km from Milano Central Station (Google Maps).
CULS Robotics Team Blog (CRT-B)
CULS Robotics is a new Czech student team for Field Robot 2025! Yes, it took only 10 years to find a group of excited students and „start again”!
The team of 3 students was founded in Czech University of Life Science Prague. The members are all in the last year of their study, so the priorities a bit colide with with
details like finishing diploma thesis or final exams … but their self-motivation is still strong so hopefully we will see them all competing in Italy in June.
CRT will compete with robot Matty M02 — the green one, red one is a backup or it will be used for the free style discipline. Robot is equipped only with
OAK-D Pro camera and it is programmed in Python using OSGAR framework.
Team members:
- Simona (team lead)
- Ondra (software)
- Franta (hardware)
- Elena (ChatGPT)
Content
- w18 - Matty GO!
- w17 - Fake it until you make it (matty-go-cam.json, github, Rules 2.0)
- w16 - NumPy and obstacle detection
- w12 - Refactoring
- w11 - PR Task1
- w10 - Yolo fruit detection
- w7 - Outdoor testing
Week 18 (18/2) — Matty GO!
This was the very first time we met with Franta and Ondra at the university. It was great that they had already some basic experience with OSGAR and they had
the development environment already prepared. The only needed detail was update of Matty driver to the latest version.
Two robots for two students looked like good match.
Unfortunately Franta's Win11 did not recognize the ESP USB-serial, so only Ondra could directly connect his laptop
to robot via USB. Never-the-less the goal was to use onboard ODroid, and for that putty was enough.
The 1st lessons learned was — try screen -dr just in case somebody is already using robot, otherwise:
screen workon osgar cd git/osgar python -m osgar.record –duration 10 config/matty-go.json –params app.dist=0.5 app.steering_deg=-20
… and this will go for 0.5m with steering 20 degrees to the right.
Week 17 (25/2) — Fake it until you make it (matty-go-cam.json, github, Rules 2.0)
The 2nd robotics round was again together with Franta and Ondra. Franta welded (!) new holder for OAK-D camera:
… so it already had sense to collect some basic data. Ondra combined OSGAR configuration files for driving and collection of
depth and image streams from OAK-D camera. At the end he also managed to push his changes to github, and thus resolved
issues with keys etc. Here you can see the proof — matty-go-cam.json.
Finally Simona shared with us the latest rules FRE2025_RULES_v2_0.pdf — which is kind of funny that even now (2025-04-11) there is still old version v1.0 on the official website … (even the location is still in Germany and not Itally).
Week 16 (4/3) — NumPy and obstacle detection
This time the whole team finally met: Ondra, Franta and Simona. The goal was to get started with OSGAR programming (see corresponding Czech notes
here). The plan was to stop the robot! in a case there is some obstacle in front of it. The inputs are depth data from OAK-D camera
which are available as 2D array of uint16 (unsigned 16 bit integers) corresponding to distance in millimeters.
Step one — pick distance in the middle of the image (single pixel) and if it smaller than 330 (I do not remember where they picked that value)
stop. It turned out that 0 is often present, but it rather means I DO NOT KNOW, i.e. the distance is not valid. What to do in such a case? If previous
measurement was long distance, then it is probably OK to continue moving. If it was short distance before then it would be safer to stop. And if you are receiving
zeros for a long time then you do not know anything and it would be also better to stop. Yes, such complex logic on single pixel reading!
This week Python lesson was that division with two / characters means integer division, which is needed for adressing array. So what we were interested
was value of depth[400//2][640//2].
Week 15 (11/3) — Camera holder upgrade, osgar.replay, NumPy mask
The most visible part for this week is a new camera holder. It is 3D printed, allows two degrees of freedom, and
camera can be tilted and/or shifted:
Note, that there are also serious changes inside — properly mounted Odrive, batteries etc.
Coding was this time on Ondra, so he learned how to use python -m osgar.replay --module app
Single pixel in the center of the depth image (data[400//2][640//2]) was replaced by rectangle. There the zeros (unknown distance)
were not as frequent, but they still had to be handled. This was the introduction of numpy masks:
>>> import numpy as np
>>> a = np.array([ [0, 1, 2],[3, 4, 5] ])
>>> a
array([ [0, 1, 2],
[3, 4, 5] ])
>>> a.shape
(2, 3)
>>> a == 0
array([ [ True, False, False],
[False, False, False] ])
>>> a[1]
array([3, 4, 5])
>>> a[1][1:]
array([4, 5])
>>> a[1][1:3]
array([4, 5])
>>> a[1][1:2]
array([4])
Yeah, maybe time to check numpy introduction for absolute beginners.
The artificial fruits and mashrooms needed for tasks 2-5 should be soon ordered. The team size is now 6 = 3 students + [Milan, Jakub, me].
New bumpers were brought for Matty M02, and Franta shoud mount them
next week. Finally Milan promissed to cut new set of corn/maize plants 40-50cm ("nice to have").
p.s. we also started to use git branches for new development, so feature/task1 was created.
Week 14 (18/3) — Row navigation
Robot Matty M02 for the first time autonomously navigated in curved row! Do not expect super-smart algorithm, but …
it worked (video).
Algorithm:
- if obstacle to the left and to the right are at roughtly the same distance then go straight
- otherwise if left obstacle is closer then turn right
- otherwise (i.e. right obstacle is closer) turn left
There was an update to used numpy mask as min/max from empty array is not defined:
>>> max([1, 2, 3]) 3 >>> max([]) Traceback (most recent call last): File "", line 1, in ValueError: max() arg is an empty sequence
… and the same situation can happen with the non-zero mask (i.e. only valid depth data)
>>> import numpy as np >>> arr = np.array([0, 0, 0]) >>> mask = arr != 0 >>> mask array([False, False, False]) >>> arr[mask].max() Traceback (most recent call last): File "", line 1, in File "C:\SDK\WinPython-64bit-3.6.2.0Qt5\python-3.6.2.amd64\lib\site-packages\numpy\core\_methods.py", line 26, in _amax return umr_maximum(a, axis, None, out, keepdims) ValueError: zero-size array to reduction operation maximum which has no identity
Another update was that instead of a line in the depth image we now take into account bigger rectangle — one for the left obstacle, one for the right obstacle and one just in front of the robot to STOP and avoid collision.
Also note, that to address an rectangle you need to specify limits with comma: data[row_begin:row_end, column_begin:column_end].
There was also an issue with numpy.dtype. In particular the depth is unsigned 16 bit integer, so evaluation „left and right obstacle are almost equal” in a half of the cases overflow.
The easiest solution was to cast result to normal Python integer (fix).
The newly mounted bumpers were tested with a new firmware and they worked fine. We will see if new black extenders will not colide with plants, but let's leave it for now.
Accidentally we also tested battery alarm. The Odroid battery reached 14.5V, and yes, the sound was well hearable even for closed box. The good news is that PC worked without any problem
although the minimal limit is officially 15V.
Week 13 (25/3) — Priority override
Number 13 is not lucky number, so we skipped it. … no, just kidding, but … yes, we skipped this week because all three students had to finish their diploma thesis.
Priority override. Robots next week.
p.s. team registered for FRE2025 in Italy as CULS Robotics
p.s.2 order of artifical fruits is still pending
Week 12 (1/4) — Refactoring Task1
OK, robot Matty now navigates in the row, but at the end it needs to turn 180 degrees and enter the next row. This taks is no longer easy to do (or nice to do) with callbacks
and instead a sequence would help with readability (see /guide/osgar#250407).
The code for Task1 looks like this now:
def run(self):
try:
for num in range(10):
self.navigate_row()
self.go_straight(1.0)
self.turn_deg_left(180)
self.navigate_row()
self.go_straight(1.0)
self.turn_deg_right(180)
except BusShutdownException:
pass
… actually the code above looked like this later … on week 12 it was stop at the end of row.
p.s. we have the artifical fruit now and mashrooms … only stawberries are missing …
Week 11 (8/4) — PR Task1
OK, the robot finally started to move back-and-forth. You can see it in the video, which was also a data collection for the fruit detection.
I would consider this task1 (version 0) as completed, so lets create pull request and merge it into master. This is actually
also the first excercise with GitHub and "standard development routine". Note, that the robot moved 0.2m/s, so in 3 minutes it would drive approximately 30 meters. And if the
rows are 20m long then we will just do 1.5 row. 30 points? That would be OK for ver0.
Once feature/task1 branch is merged, let's switch to new branch feature/task2 and create task2.py and config/task2.json. It should be basically Task1 + detections.
The goal is to use Yolo models.
Week 10 (15/4) — Yolo fruit detection
 Fruit detection by Yolo |
OK, this time it was not that exciting, but at least we got new strawberries and we collected some pictures for further annotations. On the picture above you can see output
directly from available Yolo model — banana works great, orange sometimes, lemon never. Also notice detected plant and persons.
The attempt to lower the camera resolution and reduce the log file size failed. Actually the OAK-D Pro supports 4K, 2K and 1K resolution, so
we should be happy with the lowest 1K. Sigh.
This time we (I mean students) refreshed their knowledge of trigonometry and calculated properly the steering angle needed to match the 75cm radius. Franta also suggested
to use single turn even for skipping the row, which could work. But we have not test it.
It was a bit hard to get the detector running directly on the camera (OpenCV and Qt without display), but what worked was
depthai/examples/tiny_yolo. And the problem with OpenCV was discussed
here with solution:
pip uninstall opencv-python pip install opencv-python-headless
Note, that the tiny model is really quite small:
(depthai) robot@m02-odroid:~/git/fre2025$ ls -lh models/ total 6,1M -rw-rw-r– 1 robot robot 6,1M dub 15 21:30 yolov8n_coco_640x352.blob
Week 7 (22/4) — Outdoor testing
There was a bug in Matrix. Yes, my bug: 24 - 8 is not 18, right? So now we lost 2 weeks due to this mistake. So not 9 weeks to
the competition but only 7!
This time we were testing outside (near the Round Hall) and it was great. I mean the weather. The strawberries were planted and it looked almost like a real run.
Lessons learned (where they really learned?!) is that the setup is very sensitive to camera tilt. If it pointing up then you do not see the row for navigation. If it is pointing down
you see ground which looks like an obstacle. BTW we had to disable obstacle detections because of a grass.
The change of light was very significant if you „looked into the sun” or the other way around. 10fps was not sufficient for auto-exposition, so we experimentally increased to 20fps.
Banana detector (YoloV8) was integrated into task2.py — I know that there will be no bananas on the ground, but this one already worked.
Franta brought Apple watch, which could be fun to use to control the robot (as a remote start/stop), but … none of us ever created application
for Apple and the watch is not able to display webpage.
Homework:
- train new detector with collected images of artificial strawberris from outdoor run
- calculate (X, Y) position of detections in the image
- group multiple detections, close positions, into single representative cluster