Remark: The organizers tried to describe the tasks and assessments as good and fair as possible, but all teams should be aware of that we might need to modify the rules before or even during the contest! These ad hoc changes will always be decided by the jury members.
Aim of the Field Robot Event 2022
The aim of the Field Robot Event 2022 is to compare robot programming and behaviours in a modelled and real field. That’s why we decided to go for a hybrid format. We will try to minimise the difference between the virtual field and the real field as much as possible. Therefore, it will be a big challenge for the organizers especially to create and adapt the field simulations including crop plants, weeds and other objects.
All tasks runs in simulation, field performance and awarding will be broadcasted to the internet by the platform DLG connect with access after free registration.
The simulation will be during the morning and the field runs will be during the afternoon. Each task will be conducted for simulation AND for a real field.
During morning from 10:00 to 12:00:
A task will be conducted virtually in a simulation of ROS Gazebo. (explanation)
Using a standard robot model or an own machine model.
In the afternoon from 14:00 to 16:00:
The same task will be conducted on a real maize field.
Using the standard robot or an own machine.
The organizers expect that a general agreement between all participating teams is that the event is held in an “Olympic Manner”. The goal is a fair competition, without any technological or procedural cheating or gaining a competitive advantage by not allowed technologies. The teams should even provide support to each other with all fairness. Any observed or suspected cheating should be made public immediately.
The jury members are obliged to act as neutrals, especially when having relations to a participating team. All relevant communication will be in English. For pleasing national spectators, the contest moderation could partly switch to a national language.
If teams come with more than one machine the scoring, ranking and awarding will always be machine related and not team related.
During the machine runs for each task the team members are not allowed to be in the inner contest area where the maize plants are and close to the robot during the performance. If the robot performance fails, it has to be stopped from outside with a remote switch. To enter the inner contest area is only allowed after (!) the robot has stopped. The control switch activating team member then can go to the machine and manually correct it. When the team member has left the inner contest area only then the robot is allowed to continue its operation. This procedure shall promote the autonomous mode during the contest and make the performance more attractive to spectators.
All participating teams must contribute to the event proceedings with an article describing the machine in more details and perhaps their ideas behind it or development strategies in general. The submission of text is after the event.
The use of a GNSS receiver is not allowed except for the Free Style. The focus for the other tasks in terms of localization shall be on relative positioning and sensor-based behaviors.
The crop plants for the tasks is maize (corn) or Zea Mays [Plant density 10 m2, row width of 0.75 m, plant spacing 0.133 m]. The maize plants will have a height of approximately 20 – 40 cm. The concrete appearance of the crop plants is depending on the location specific growing conditions and varies from year to year.
A damaged plant is a maize plant that is permanently bent, broken or uprooted. The decision about a maize plant to be damaged by a machine will be made by the jury members or assistants.
During the contests, all robots have to wait in the parc fermé from the beginning on. Therefore, no more machine modification to change the machine performance is allowed during the task runs with regard to fairness. All PC connections (wired and wireless) have to be removed or switched off and an activation of a battery saving mode is recommended. This shall avoid having an advantage not being the first robot to conduct the task. The starting order will be random. When a robot will move to the starting point, the next robot will already be asked by the parc fermé officer to prepare for starting.
The drive paths of the robots shall be between the crop rows and not above rows. Large robots or robots which probably partly damage the field or plants will always start after the other robots, including the second chance starting robots. However, damaged plants will be replaced by spare ones, to always ensure the same operation conditions for the robots.
General requirements for all robots
All robots must act autonomously in all tasks except for the freestyle. In the freestyle a full autonomous mode would be perfect but perhaps hard to realize. Driving by any remote controller during the other tasks is not allowed at any time. This includes steering, motion and all features that produce movement or action at the machine. Stopping and starting function for manual corrections of the machine is the only exception.
During start, the robot is placed at the beginning of the first row. The starting line is marked with a white cross line. Any part of the robot must not exceed the white line in the start. For signaling the start and end of a task there will be a clear acoustic signal. After the start signal, the robot must start within one minute. If the robot does not start within this time, it will get a second chance after all other teams finished their runs, but it must – after a basic repair – as soon as possible brought back into the parc fermé. If the robot fails twice, the robot will be excluded from the task starting list.
Start & Stop Controller
All robots must be equipped with and connected to one wireless remote START/STOP controller. Additional remote displays are allowed but without user interaction, e.g. notebook or laptop.
Preferably, the remote controller is a device with two buttons clearly marked START and STOP. Alternatively, the coding may be done with clear green and red colors.
It is allowed to use a rocker switch with ON/OFF position with hold, if the ON and OFF are clearly marked with text in the remote controller.
Any button of the remote controller may not be touched for more than one second at a time. In other words, a button, which has to be pressed all the time, is not allowed.
The remote controller may contain other buttons or controls than the required/allowed START/STOP inputs, but no other button may be used at any time during any task.
Before the start of any task, the remote controller must be placed on the table that is located at the edge of the field. One member of the team may touch the START and STOP inputs of the remote controller. The possible remote display must be placed on the same table too.
The remote controller must be presented to the Jury members before the run. A jury member will watch the use of the START/STOP remote controller during the task execution. Other remote controllers besides START/STOP controller are strictly prohibited to be used at any time.
In each task, the robot must be started by using the remote controller START input, not pressing any buttons on the robot itself.
During any task, while the robot is stopped in the field by using the remote controller, it is allowed to use any buttons of the robot itself, e.g. to change the state of the navigation system.
Implementation note: If using Logitech Cordless Gamepad or equivalent as a remote controller, the recommended practice is to paint/tape one of the push button 1 green and push button 2 red, to mark START and STOP features.
Manual correction of the robot
One team member is allowed to enter the field after the same (!) team member has pressed the STOP button of the remote controller and the robot has completely stopped (no motion). It is recommended to install some indicator onto the robot to see that the robot is in STOP mode before entering the field in order to avoid disqualification.
The START/STOP operator is also responsible for the eventually manual robot corrections. Due to the fact that it can be difficult for him/her to monitor the robot’s behavior from a large distance, another team member can be inside the 2 m area between a red textile tape and the crop plant area (see picture 1 and 2 at the end of this document). This second team member could give instructions to the operator, but this supporting person is only an observer and is not allowed in any case to enter the crop plant area or interact with the robot.
After leaving the remote control on the table, the operator is allowed to rotate – not to move – the robot in the field. The only exception for moving is when the robot may need to get back to the path if a wheel or track of the robot has collided stem of maize plant, to avoid further damage of plants. Carrying the robot is only allowed after significant navigation errors in order to bring it back (!) to the last correct position and orientation.
Rules for robot models in simulation
A model of a standard robot (Jackal CLEARPATH ROBOTICS, German dealer NEXT company) will be provided for those teams who want a model. Teams can also come with their own machine models. The models must be realistic in function and physics (kinematics, sensing and other abilities). Basic parameters must be considered and respected.
The basic parameters and rules that apply for custom robots are:
Velocity and acceleration limits.
The limits to the velocity and acceleration are:
|Linear forward velocity||2.0 m/s|
|Linear forward acceleration||20.0 m/s2|
|Angular velocity||4.0 rad/s|
|Angular acceleration||25.0 rad/s2|
These limits are already applied to the Jackal robot in the example workspace.
Limits to sensors and Gazebo plugins used to simulate your robot.
The sensor plugins should be used with the default noise parameters. The allowed sensors and the corresponding allowed Gazebo plugin are:
|Sensor||Allowed Gazebo plugin||Noise parameters|
|Synchronized RGB cameras (stereo)||libgazebo_ros_multicamera.so||Link|
|Inertial Measurement Unit (IMU)||libhector_gazebo_ros_imu.so||Link|
|Realsense RGB-D camera||librealsense_gazebo_plugin.so||Link|
* This plugin will also work fine on a pc without GPU and is the only version allowed because it does interact with the visual mesh of the maize plants.
If your robot model needs additional sensors and plugins that are not mentioned above, please contact the organization (firstname.lastname@example.org) before 1 June 2022. The organization will decide if the sensor will be allowed in the simulation contest and if so, will install the corresponding plugin in the simulation container and publish the new simulation container on Dockerhub. The table above will be updated if new sensors and plugins are allowed in the simulation. You can also subscribe to the competition environment on Github to get an update when something is added.
Limits to the ROS control plugins used to simulate your robot.
To let your robot work in Gazebo, the controller should be installed in the simulation container. By default the following ROS controllers are available in the simulation container.
|velocity_controllers||joint_position_controller joint_velocity_controller joint_group_velocity_controller|
|effort_controllers||joint_position_controller joint_group_position_controller joint_velocity_controller joint_effort_controller joint_group_effort_controller|
|joint_trajectory_controllers||position_controller velocity_controller effort_controller position_velocity_controller position_velocity_acceleration_controller|
If your robot model needs an additional ROS controller that is not mentioned above, please contact the organization (email@example.com) before 1 June 2022. If your team writes a custom ROS controller for your robot, it has to be published in a public repository on Github or Gitlab. The organization will install the needed ROS controller in the simulation container and will keep the table above up to date. You can also subscribe to the competition environment to get an update when something is added.
Make your robot description and ROS parameters public.
Your custom robot description and ROS control parameters (in case of the example robot, you should upload both folders ‘example_robot_description’ and ‘example_robot_control’) should be made public before the simulation contest by uploading it to a public repository on Github or Gitlab. The link to this repository should be emailed to the organization (firstname.lastname@example.org) before 1 June 2022. The organisation will add this link to your robots page on the website. In this way, the organization and other teams are able to check your robot.
Your robot should be realistic.
For example, if you attach a camera to your robot model, it should be attached to your robot with a frame and not floating around.
Requirements for using the standard robot in field
For those teams who are not coming to the event personally, we offer the opportunity that their codes can also be tested in the real field during the afternoon runs.
Teams should inform us about what sensors etc. they want to use. The organizers will decide about if the requested components can be used. After the organizers agreed to the use of a component they will ensure that they can be executed within the composed environments (simulation).
All source codes (models for sensors etc.) should be send to the organising team and made public before the event, because we want to promote the use of open source sensors.
Awarding and Prizes
The performance of the competing robots will be assessed by an independent expert jury committee. Beside measured or counted performance parameters, also creativity and originality (freestyle) will be evaluated. There will be an award for the first three ranks of each task. All tasks together will yield two overall competition winners: one for simulation and one for the field competition. Points will be given as follows:
Rank 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 etc. Points 30 28 26 25 24 23 22 21 20 19 18 17 16 15 14 etc.
Participating teams result in at least 1 point, not participating teams result in 0 points. If two or more teams have the same number of points for the overall ranking, the team with the better placements during all tasks will be ranked higher.