1. We actually had the same issue previously. We now use a classification AI model to determine if the current image is a silver line or not and it works perfectly without failing. 2. We check around each green point with a box and then its a simple check what sides are true. Our code is public and in the github linked in the description. 3. We turn different amounts for the angle calculated. Higher angle means we turn more and less is less turning. After a certain angle we turn on the same position so we don't overshoot.

​@@Overengineering2Thank your for your answer, but sorry , in my third question I mean that if I use 4 straight for the robot, it will stuck by the wheels when it is turning.but if I change two wheels to the omni wheel, it can turn smoothly.(I am using omni wheel now but sometimes it may slip, so I want to change the wheels to 4 straight wheel. Then the problem that I said will appear.)

Thank you very much!! it helps me a lot :)

Its in the github linked in the description.

@null5464 Yes, these are the usual courses at the european/world championship. Normally the courses on the first day (Run 1-4) are simpler than the ones on the 2nd day (Run 5-8). If you want to know how the courses from the european championship looked you should check out the videos from Bitflip. The issues we had were because of the way we built the robot, causing it to cut corners a lot and falling. The other issue is that our center of mass is very high, so we have had a lot of issues with downwards ramps and a seesaw before that is even worse.

​@@Overengineering2 I wathced all videos of bitfilp. (of course yours too) But i ve never seen that course like a mansion.

Thank you! We mostly use OpenCV and NumPy for the line following part. We will release our code in the github organization linked in the description very soon, so you will be able to read up on that there.

@@Overengineering2 Nice! That will be awesome. Cheers from Brazil!🇧🇷🦾

Thank you! The robot follows the line by initially searching for seven points in the image. In addition to identifying the lowest point on the line, both for the full image and a version cropped in height, the highest, leftmost, and rightmost points on the line are identified. The robot typically follows the line by centering the highest point of the cropped image. If this point is not at the top edge of the cropped frame, either the left or right point is selected for following, depending on their distance to the edge of the frame, to prevent overrunning the line. The point that the robot is currently following is highlighted in red on our GUI. At intersections, this becomes more challenging, particularly when standing at an angle, as the correct line may no longer be the only one at the upper edge of the frame. For this reason, a theoretical point (yellow in our GUI) is constantly calculated by connecting and extending the lowest and highest points of the cropped image to the upper edge of the frame. In the case of an intersection, the point at the top of the frame closest to the yellow point is selected to follow. If a green marker is detected, the point on the corresponding side of the line is chosen. The detection of these is based on checking the four sides around the marker for any black lines. We will release all our code including documentation etc. soon in the Github organization linked in the description, so you will be able to read over everything there.

@Overengineering2 Thank you for your reply! I am working on a program based on that. What does "a version cropped in height" mean? I think it refers to the top row of the current image. Is that correct?

@@null5464 Yes, we remove part of the top of the image so we can follow the line more closely, since the way our robot is built causes a lot of corner cutting, which is a problem often times.

@@Overengineering2finally i did it. thank you so much!! :)

@@AdilsonVCasulaWe use a Raspberry Pi 5 with two cameras (Raspberry Pi Camera Module V3 for the line-following; USB wide angle for the evacuation zone) and a Google Coral USB accelerator for running our custom made ball detection model (YOLOv8) with sufficient FPS. Additionally, we deploy some Arduino Nanos for reading out sensor measurements (mainly infrared distance and gyroscope sensors) as well as servo controls for the arm and victim storage system. The “simulator” you are seeing in the videos is a screen recording of our custom made GUI (using CustomTkinter), which displays our image processing (mainly using OpenCV and NumPy), the output from our ball detection model, sensor reading, the rotating model of the robot (these are pre rendered frames using blender mapped to measurements from our gyroscope sensors) and much more information for debugging purposes.

@Overengineering2 that's great. Thanks. We use only the Lego suite today and are thinking of jumping ahead. Thank you

@@antoniat9531 As you can see in the video, after rescuing the dead victim at the red evacuation point, we simply follow the wall, checking for any unexpected distance changes measured by a distance infrared sensor mounted on the right side of the robot. If there are any of these changes the robots turns right and checks with the camera whether the stripe on the ground is silver or black.

The chassis was printed with PLA/PLA+. The wheels are made out of neoprene.

We use a Raspberry Pi with 2 arduino nano's. Our code isn't gonna be of any help to you. We will probably release our code on the github organisation linked in the description somewhat soon if you do want to look at it.

@@Overengineering2 ok

New competitors are very welcome :)

Thank you! Honestly we didn't expect for it to work on the 2nd try we got on the slope haha.

Thanks! We will publish our code somewhat soon on the GitHub linked in the description, including poster, TDP and journal log (probably this month). The basic explanation is that we use a YoloV8 detection model trained on a self made dataset of around 3500 images. The model runs on a Google Coral USB Accelerator so we can achieve ~21 FPS.

Haha. Wir haben aber auch 3 Jahre gebraucht um den so schnell zu machen.

Please refer to our previous answers. We will publish the repository when we can.

Will you give an update when you make the repository made public in your YT channel ??

@@loky2187 No, you can follow the Github organization and check if we published it. As we said in previous comments, expect it to be published this month. Continuing to ask again and again will not make us release it faster.

Thank you

Thank you!

Thank you! The text may have been a bit misleading, but its a timer that counts down before the robot starts driving again. If we switch the lack of progress switch in that timeframe the robot knows it failed to dump the victims of x color.

@@Overengineering2 Alright, that's pretty clever. Great way of thinking

Thank you! Its a custom GUI we made using CustomTkinter. The code will be available in our Github once we publish that. (few weeks)

Thank you!

Thank you! And congrats to you again too.

Thanks a lot! There was no official website with the scores, but PDF's in our teams personal page (each team got a personal page with announcements and scores etc.) that contain all our scores. They will be in the repository which we will publish on our Github organisation linked in the description somewhat soon (give or take a few weeks, am too lazy to write a readme haha). That repo will also contain all our code, including technical challenge and superteam.

We just found the link to the official scores page rescue.rcj.cloud/events/2024/Scores/RoboCupJunior_Rescue_Line_Overall_Score.pdf.

@@Overengineering2 Thank you so much!

We just finished the world championship and are working on cleaning up the repository so we can publish it. The first video is being edited at the moment and should be online tomorrow.

@@loky2187 sorry, but we do not know that. Our mentor got these around 7 years ago from a soccer leauge team

@@limaotop3913 Thank you. The arduino that reads out sensor data we have it print the data into the serial console and then have the pi read it out through pyserial. The arduino that drives our servos is connected through 4 digial pins. The first one is a control pins that says if the arduino is allowed to move the servos at all. The other 3 are the ones who tell the arduino what position to move the servos in. For example a combination of 001 would be move the servo's so the arm goes to the default position.

In the GUI visualization, the left image is from a Raspberry Pi Camera Module V3 Wide Angle. The right image is from a Arducam B0268 Wide Angle Camera

We use a power only type c cable that is connected to our step-down converters

We use 2 Adafruit BNO055 Gyroscope sensors

@@Overengineering2 Why 2 sensors?

@@mostafahagras4831 we use 2 because they have a slight drift over time so we can average them out

Most likely yes

Tnx a lot!

We use a detection AI with a self made dataset for detecting the victims. We only use OpenCV for detecting the corners.

We use a relay to turn the LED array on and off and it's controlled through our Raspberry Pi 5.

No, we use 4x 12V DC geared motors

Thanks! What do you mean by "engine shield"?

@@Overengineering2 which shield to control your motors do you use. And what camera do you use?, thanks, good job

@@limaotop3913 We use a L298N Motor Driver that is connected to our Raspberry Pi 5 through the GPIO pins. The top camera (left image) is a Raspberry Pi camera V3 and the bottom camera (right image) is a Arducam B0268 Widge Angle Camera

@@Overengineering2 thanks, good job

We use a power only type c cable that directly goes from the step down converter that is set to 5.1V to the Pi

What do you mean by simulation software? There are no simulations.

I mean that video of vehicle following the line is displayed in a specific area that is the time is showing, axis are showing, following the line visual is showing

No, none of the interfaces in the video were developed or provided by RoboCup. We have created our own GUI with the help of CustomTKinter, of which you can see a screen recording. The markings in the camera image are part of our image processing.

We use 1m of 12V COB LED strips by revoART for that

The world championship ends on the 21st of july. Some time after that we may open source our code.

We use two different self made AI models for that.

@@Overengineering2 can you tell us for lerning

@@hamidoosama We use Ultralytics YoloV8 AI models with fully custom datasets.

It's private because we are still actively competing in competitions. The next one is the World Championship in Eindhoven, Netherlands. The code may eventually be public when we finished all competitions.

We are using a single 7.4V LiPo- battery and a 12A step-down converter. We really recommend using a high amperage step-down converter, especially for the Pi 5. A 6A step-down converter caused problems with random crashes before.

Danke! Wir haben herausgefunden, dass wir nicht wirklich mehr als ein Sichtfeld von 105° brauchen, da wir mit dieser Kamera schon einen großteil der Zone überblicken können und ein größeres Sichtfeld nur zu Verzerrungen am Bildrand führen wird.

​@@Overengineering2 Ah ok, danke

No, we use a Arducam B0268 Wide Angle Camera for victim detection and a Raspberry Pi Camera Module 3 Wide Angle for line following.

No, we use a Arducam B0268 Wide Angle Camera for victim detection and a Raspberry Pi Camera Module 3 Wide Angle for line following.

We have a infrared sensor inside the gripper so we know if something is inside of it

@@Overengineering2 Thank you, congratulations.

what infrared sensor did you use on the clamp?

@@limaotop3913 A 50cm Pololu irs16a infrared sensor

We use a mix of OpenCV and NumPy methods to do all the image detection tasks. The full code will probably be available on our Github once we finished all our competitions.