Reset - End of the Year Challenge 2022 Final Submission #140
Conversation
|
@resetteam2023 Thank you for your contribution! We will be reviewing, testing and discussing the changes with you. |
|
Hello @Adman, It would be possible to change the shape of the robot to a cylindrical shape rather than a cube shape. However, we have not tested it out yet as we believe that it may futher complicate the physics of the world. If you would like to change the shape of the robot to be cylindrical, let us know and we will update the world for you. Thank you! Team Reset |
|
@resetteam2023 If it is not too much complicated to test cylindrical shape, let's try it out. I noticed one issue when I run webots R2022b. It prints some DRIBBLER related as well as some physics related warnings
Do you have an idea if it is possible to fix that? Thank you! |
|
Can you please remove |
| @@ -8,5 +8,5 @@ | |||
| data = [True] # Packet cannot be empty | |||
| packet = struct.pack("?", *data) | |||
|
|
|||
| while robot.step(32) != -1: | |||
| while robot.step(8) != -1: | |||
There was a problem hiding this comment.
Why is the time step reduced to 8? Did 32 cause any problems?
There was a problem hiding this comment.
Hello @Adman,
Yes, since the physics computation is now a lot more complicated than before, changing the value for the basic time step of the world would drastically affect the way that robots move and perform. After testing, we found that setting the basic time step of the world to 8 is the most ideal. When we set the basic time step to a value greater than 8, Webots would have trouble computing the physics correctly when collision between robots happen (the physics-related warning message WARNING: The current physics step could not be computed correctly. Your world may be too complex. If this problem persists, try simplifying your bounding object(s), reducing the number of joints, or reducing WorldInfo.basicTimeStep. appeared more frequently). On the other hand, when we set the basic time step to a value lower than 8, the robots no longer moved as we expected and the simulation ran slower.
Let us know if you have any other questions regarding this issue!
Team Reset
There was a problem hiding this comment.
Very nicely done @resetteam2023 -- kudos for putting this together!
I've left a couple of comments here and there, feel free to respond at your convenience 🙂
| def kick_ball(self, state, velocity=20): | ||
| if state == 1: | ||
| self.kicker_motor.setVelocity(velocity) | ||
| self.kicker_motor.setPosition(0.042) |
There was a problem hiding this comment.
@resetteam2023 is there any reason for the exact value of 0.042 in here?
There was a problem hiding this comment.
Hello @mrshu,
Yes, the value of 0.042 here represents the furthest position that the kicker could move to without moving beyond the frame of the robot (the greater the value, the further the center of the kicker is away from the center of the robot).
When we were making the kicker in the Webots world, we only made sure that the kicker position had to be between 0 and 0.042. While this means that the kicker could be moved to positions between 0 and 0.042, the kicker would not be kicking rthe ball as hard in those cases.
If you would like, we could add a parameter to the kick_ball function that would allow the kicker to be moved to specific positions between 0 and 0.042.
Thank you!
Team Reset
| elif kick_time > 5500: | ||
| kick_time = 0 | ||
| else: | ||
| self.kick_ball(0, 20) |
There was a problem hiding this comment.
@resetteam2023 just out of curiosity, what would happen if this call wasn't made (i.e. kick_ball would never be executed with state=0)?
There was a problem hiding this comment.
Hello @mrshu,
If kick_ball is never executed with state = 0, after kick_ball is executed with state = 1, the kicker would remain in the "outward" position (the center of the kicker would be at a position of 0.042). This means that the robot would not be able to kick the ball again and would not be able to dribble the ball.
Let us know if you have any further questions!
Team Reset
worlds/.soccer1.wbproj
Outdated
| @@ -0,0 +1,9 @@ | |||
| Webots Project File version R2023a | |||
There was a problem hiding this comment.
@resetteam2023 would you happen to know what are these .wbproj files used for?
There was a problem hiding this comment.
Hello @mrshu,
Unforunately, we were not aware of those files so do not know what those files are used for. As stated in a comment above, our guess is that those files were created by the Webots program when we were building our world in the R2023a version of Webots (we originally tried to use the R2023a version of Webots to build the world but encountered issues with retrieving ball direction values in the Mac version of the R2023a version) and that there should not be any problem with deleting those files.
We will take a deeper look into this and update you soon.
Team Reset
|
We just committed and pushed new changes to this forked repository. In this comment, we would like to address these new changes as well as some of the questions above that we have yet to answer (that relate directly to these new changes).
If you have any other questions or proposals for changes, let us know and we will try to respond to them as soon as possible. Thank you! Team Reset |
|
@resetteam2023 Thanks for your updates. I have checked it and it looks very nice! I've got further questions:
|
|
@resetteam2023 I've been playing with the robot a little and found out that the wheel is doing "8" while rotating. Do you think that this could be possible to fix? soccer_8_wheel.mp4 |
|
Hello @Adman , Thank you for pointing out the issue and sorry for getting back to you so late. We were on Chinese New Year break so did not get the opportunity to look into those issues yet. However, we will look over the issues you mentioned (sonar positioning, slow simulation speed, light dribbler mass, and strange wheel movement) in the next few days and try to respond as soon as possible. We would like to mention, though, that we have tried to increase the speed of the simulation but were not able to increase it as much as we would have liked. We will continue to see if there are any other ways to increase the speed of the simulation, but as the simulation is now a lot more complicated than before, it may be difficult to do so. Thank you and please let us know if there are any other parts of the simulation you would like to fix. Team Reset |
|
Hello @resetteam2023. How are things going? Let me know if I can help somehow. Looking forward to seeing the updates. |
|
Hello @Adman , Everything is going fine! We have increased the mass of the dribbler (and changed a lot of other parameters of the world to accomodate for it) and moved the ultrasonic sensors out so that they are visible. We have realized that there is an issue with the wheel movement and are working on it. Right now, we are pretty sure that the issue is with the values that we put for either the rotation of the wheel solid or the values for the axis of the motor joint. If you happen to know what values we should use for either the rotation of the wheel solid or the axis of the motor joint, please let us know as it will be very helpful. We will commit the code and update you as soon as we get the code to work (hopefully in a day or two). Thank you! Team Reset |
… Out, and Changed Dribbler Mass
|
Hello @Adman , We just committed new code onto the repository. The changes that we made in the code should fix the strange wheel movement, remove the warning about the dribbler mass being too little, and make the ultrasonic sensors visible. Hopefully, all the issues (other than the simulation running too slow) are solved, but if there are any other issues, please let us know. We apologize that it took so long for us to make these changes. Thank you! Team Reset |
|
@resetteam2023 No worries, thank you for the update! Ultrasound sensors look OK except the front one, where there is a gap between the robot and the sensor (see the screenshot below). Dribbler warning is gone and wheels rotate normally -- that is great 👍 . I'll keep playing with the robots and test different movements. It would be really nice if we could make the simulation faster, because the one second in simulation takes almost 2 seconds in reality. We should make it similar otherwise simulating matches would take a lot of time.
|
|
@resetteam2023 Hello, I was playing with the dribbler a little bit and found out that robot is moving backwards when the velocity of motors if set to 0 and robot is dribbling the ball. Is it the weight of the robot being too low that could be causing this behavior? I guess physical robots most often stay at one place while dribbling the ball. Do you think we could fix this? test_dribbler.mp4 |
|
@resetteam2023 There's also one small issue with the kicker. When the robot is not moving and triggers the kick, robot is shifted backwards and moved back to original position. Check the video. Could this be cause by the kicker itself? Does the friction between kicker and the robot cause this movement? test_kicker.mp4 |
|
Hello @Adman , Thank you for pointing out the issues. We think that the fix to those issues would be to increase the mass of the robot. However, increasing the mass of the robot can cause a lot of problems for the simulation (including the robot slowing down, moving strangely, or at worst, becoming unable to move). In order to accommodate for those problems, we would have yo further complicate the physics of the simulation, which would slow down the simulation even more. However, we will try to work to fix those issues as soon as possible (we are currently traveling so we might take around a week or so) and let you know the results. Thank you. Team Reset |
|
@resetteam2023 Alright, if it slows the simulation down then I guess it should be fine. However, we should really fix the time step issue. Is that possible? |
|
Hello @Adman , We have found a solution that will allow the simulation to run at a faster speed. The current solution (and the only one so far) that we have is to increase the TIME_STEP for the ball and the referee while making the TIME_STEP for the robots the same as the basicTimeStep. By doing so, a 10-minute simulation on our iMac could finish in about 3 minutes. While this solution does allow the simulation to speed up significantly, the issue that this solution presents is that the ball's values are no longer accurate (as the ball's values are updating slower), which goes back to the problem regarding TIME_STEP that was resolved prior to the simulation challenge last summer. A suggestion that we have will be to revert back to the rules that were used in 2021 where the ball's coordinates were given at all times rather than determined using the IR sensors. We think that not only would changing this rule potentially fix the issue, but it would also make gameplay more interesting. With the arc, the dribbler, and the ability for robots to move in all directions implemented this year, it is way too easy for teams to simply have two robots trap the ball and drive into the goal. On a side note, near the end of 2021 or early 2022, as you may already know, we started experimenting with implementing an arc to the robot. While we were not able to get the arc implemented in time then, we eventually ended up not only successfully implementing the arc, but also the dribbler, the kicker, and the ability for the robot to move in all directions (pretty much all the capabilities that the robot has now except for the ultrasonic sensors). In fact, what we created for this end of the year challenge was modelled off of what we started then. Interestingly, we went back to check the simulation that we built using the 2021 Webots version and found that not only was the simulation a lot smoother (we did not have to mess with the TIME_STEP and the robots ran well even when the basicTimeStep was set to 32), but that the simulation ran at around the same speed as the old simulation (the one used in the past few years where robots ran on two wheels). In a 10-minute simulation on our iMac, the simulation could finish in just around 1 to 2 minutes. Unfortunately, the entire system of Webots changed between 2021 and 2022 and as much as we tried, we were not able to successfully emulate what we built using the 2021 Webots version to the 2022 Webots version (even when we made all the parameters of the world the same). However, it did give us reason to suggest going back to using the 2021 rules where data about the ball position is given to the robots instead of having the robots determine the ball position based on the IR values. If you are interested in taking a look at what we built using the 2021 Webots version, feel free to let us know. Additionally, as for the ultrasonic sensors, the reason why the front ultrasonic sensor seems to not be on the robot is because we wanted each ultrasonic sensor to be the same distance away from the center of the robot. Since the front of the robot's cylindrical volume is cut out, in order to make each ultrasonic sensor the same distance away from the center of the robot, we have to either make the front ultrasonic sensor not be part of the robot or make the other ultrasonic sensors not visible. If having the each ultrasonic sensor the same distance away from the center of the robot is not your concern, please let us know and we will change the simulation accordingly and commit the updated Webots world. Since we feel like there is a lot to discuss and that it would be best to finalize the simulation as soon as possible, if you think it would also be helpful, we suggest having an online meeting where everyone could discuss about what we could change and what we need to do in more detail. Thank you. Team Reset |
|
@resetteam2023 Thank you for the investigation. With regards to the ultrasound sensor, the distance does not matter. The robots in simulation should be similar to physical ones - so I suggest that the front ultrasound will be mounted on the robot, having its distance from the center a bit lower. Nothing is perfect in physical robots as well, so programmers need to adapt to these circumstances. If we are talking about the IR ball and its position, I think it would be a step back if we start sending exact position of the ball to everyone. |
|
Dear @resetteam2023, would you mind rebasing your branch on top of our master? I've updated Webots to R2023b version. Let's see if that may help with the TIME_STEP issues. |
Team Reset: End of The Year Challenge 2022 Submission
Main Changes:
The current world only works for the 2022b version of Webots and not the 2023a version (which was released not long ago). A world that is compatible with the 2023a version of Webots has been made. However, the world is yet to be finalized due to some issues.