The aim of the virtual competition is to reduce as much as possible the gap between simulation and reality in order to provide a satisfying event for sim2real learning.
However, we do not want team who implement realistic models to be penalized with respect to teams who would use very optimistic models because they did not account for some elements which make controlling the robot much harder. Therefore, the models submitted by the teams will be checked in order to make sure that they do meet some constraints.
We think that it is best to build this list with the league to make sure the constraints are not excluding robots from the competition but still complete enough to make sure we obtain realistic robots.
This first post presents the latest version of the model specifications that should be built.
Cyberbotics is currently assessing the impact on performances of integrating the ODE implementation of backlash. Depending on the results it might be integrated for RoboCup 2021. Otherwise, they already have proposed another scheme to mimick backlash.
We, that is the Hamburg Bit-Bots, strongly disagree with using the InertialUnit (https://cyberbotics.com/doc/reference/inertialunit) from Webots.
The modeling of the noise and drift for this sensor would be very complicated since it is multi-modal and each of the modes is affected differently by noise. Furthermore it measures values which are not really available in the real world and feels a lot like “cheating”.
We think that modeling noise on two real sensors rather than one fake sensor is significantly easier.
Simply using an accelerometer and gyroscope sensor and letting the teams apply their favorite filtering algorithm (this one is our favorite, its very light weight, we run an adapted version without ROS on a microcontroller on the real robot) is much more realistic in our opinion.
Noise modeling of the gyro could be done by applying some gaussian noise and applying some random offset which might even change during runtime.
Noise modeling of the accelerometer could be done by some gaussian noise. We believe that this is less critical. Due to the nature of simulations the measured force (and therefore acceleration) is already quite noisy.
We believe that this is closer to the real world and therefore more interesting for the league. This is also easier to implement.
Thanks for your input Jasper, the draft has been updated according to last night discussion (see first post).
I think that your proposal makes sense and that we should follow it, I’ve updated the specification to remove IMU and include both accelerometer and gyroscope, if anyone is concerned about the fact that InertialUnit can’t be used directly, please discuss it.
Thank you as well for providing the reference that might be very useful to teams that were using directly the data provided by a 6-axis IMU.
We have parallel elastic actuators in the knees of our robot (see image below). They consist of a torsion spring and a Dynamixel servo. The spring reduces energy consumption and provides additional torque when extending the leg (e.g. during a kick). Is it allowed to model this in Webots? Just taking the datasheet values of the Dynamixel servo would not correctly reflect the real torque of our robot.
Thanks for the comment Marc. I agree that passive actuators are important for the league and it should be possible to use them for the virtual competition.
From a ‘Webots’ point of view, I think it should be possible to use mechanical loops, to implement this with two different controllers.
From a ‘competition’ point of view, since the elastic actuator torque depends on the joint position, but not on external command, I think it should be implemented on the simulator side, which has currently not been planned for.
@olivier Would it be possible to include this kind of architecture for the competition and what would be the best way to add it? Create a new passiveHingeJoint or maybe have some controllers implemented by the league and allow to choose whether a joint is passive or active depending on a special tag in the name?
I confirm it is possible to implement this device using a mechanical loops as suggested by @Ludovic. You will also need to set proper spring and damping properties in the joint parameters. There is no need to implement a passive hinge joint, as it is already available by default: the hinge joint by default has no motor: it’s passive. So, I believe you can go ahead and implement your model with existing Webots building blocks. I will be happy to help if you have any question.
The mass of cables must be concerned on protos?
If that, I don’t know how to apply the mass of cables, because the cables are long connected from head to foot.
And,
In Robot Model Specification[Preliminary], said that “a LUT is used to specifiy the response of the sensor”.
It means I need to submit LUT? Is there any form in there?
The global mass of the robot should roughly match the weight of the robot. For cables, one of the solution is simply to distribute the extra weights on different body parts, but you can find other schemes.
Regarding the LUT, it should be specified in the field as presented here.
Our model has many Circuit board in its chest.
But in model guidelines say about model complexity.
So, is it good if I remove all the Circuit board inside of the chest of the model and make the chest of the model empty? (Mass and Center of Mass follow real robot)
And is it good if No cable model, No bolts and No nuts in the model?
Yes, you definitely don’t need to model all the inner details of the robot. Modeling cable would definitely be a problem since it would require to have a simulation for non rigid bodies.
For the parts inside the robot, it is perfectly possible to simply remove them as long as the mass and center of mass is set according to the real robot.
A good compromise if your model has lots of details (circuit boards, small bolts and nuts, cables, etc.) is to take a picture of the appearance and map it as a texture to your simplified mesh. This way, the model will run very efficiently and appear realistic from the cameras of other robots. Moreover it will look better from the main view. Using PBR texturing will provide an even more realistic modeling. See the PBRAppearance node in Webots for details.
In the rules states that “The robots must wear colours that distinguish them from each other”.
It means the robot should wear jersey.proto file? Can’t it be replaced by changing the color of the robot’s chest?
Postures.json file has “Longest extension posture”.
The “Longest extension posture” mean the posture with arms outstretched upwards?
Color does not need to be provided through the jersey.proto file. What is requested is to parse the field name and adapt the color of your robot. If you change the color of the robot chest and your chest has a sufficient surface, it is valid.
It is a little bit more complicated than that, it is the posture which maximize the maximum distance between two points of your robot. Those two points might be the end of one hand and the end of a toe, but it depends on the structure of the robot.
