Our team has programmed their robot with two ultrasonic sensors. We have built half a practice field with PVC piping, plywood and foam squares. We installed the skyrise base and autoloaders. The team got the autonomous program to score a skyrise consistently on our practice field, but when they competed they couldn’t get it to work the same way. The robot would just miss the skyrise base by a tiny bit. Does anyone have any idea why this would be and what we could do about it?
The sensor on the lift detects the skyrise in the autoloader and the sensor on the chassis detects the skyrise base. The problem at the competition was in the chassis sensor detecting the skyrise base and the life moving down to score the skyrise in the base. It just missed it over and over again. When we got it back our practice field, it scored every time. What could be the problem?
Lots of teams have problems with their autonomous routines working very well at home and then not working as well (or at all) at the competitions. Many teams have to readjust their routines at the competitions.
I imagine others will offer some advice on how to mitigate this, btw. Perhaps use other sensors besides sonars and make sure your placement of the autoloader is where it is supposed to.
Thank you for your comments. Maybe it is a problem with the placement of the autoloader. I didn’t think of that.
I just added links to the photos on flickr. I couldn’t get the photos to show up in the post. How do people do it anyway? What website works to put the photos on? I tried google+, shutterfly and flickr.
There are lots of small factors that might affect your autonomous. Placement of the field elements could be one thing, but even the way the ultrasonic bounces off objects around the field might have minute effects or the grippyness of the foam tiles. To make your routine more consistent, it is best to use a variety of sensors such as encoders, line trackers, and ultrasonic.
The way I always add images is by first adding them as attachments to the post in the manage attachments area below the area you type in. Then, when you click on the image, it will take you to the link where the image is, and you can copy that link into the post when the insert image function.
What in your code finally determines when to release the SkyRise section onto the base? For example, does the release come after a certain amount of time or distance driving forward? Or when the ultrasound sensor gives a specific reading?
Could the problem be caused by your wheels rolling a little farther on different types of tiles (after being told to stop once the sensor detects a specified distance)? Could your front wheels be touching the seam of the tiles at a critical point, thus causing some uncertainty?
On flickr, go to the sharing options for your photo (the curvy arrow), then use the BBCODE option on the image. Copy and paste that guy into the post. Preview the post and it should come up.
BBCODE edits for width and height commonly used on other message boards do not generally work on this vex forum. So choose the size to share and embed into your post over at flickr and paste that into the post.
Thank you for writing. We don’t have time to add more sensors before our next competition, which is on Saturday, but I’ll talk to the team about adding more before our state championship, where they are competing later in February. Thank you also for telling me how to get images in my posts.
On the red square, the robot starts facing the wall with the autoloader, moves left until it detects the skyrise, picks up the skyrise, moves right, turns counterclockwise until it detects the skyrise base, moves forward towards the base and drops the skyrise. At the competition it consistently dropped it a tiny bit to the right (away from the wall with the autoloader), but on the practice field it scores it every time.
When the ultrasound sensor gives a specific reading, then the robot moves forward towards the base for a specific amount of time (400 ms).
I am attaching the autonomous program if anyone wants to look at it and give feedback.
Thank you.
[quote=“FullMetalMentor, post:7, topic:28289”]
What in your code finally determines when to release the SkyRise section onto the base? For example, does the release come after a certain amount of time or distance driving forward? Or when the ultrasound sensor gives a specific reading?
Could the problem be caused by your wheels rolling a little farther on different types of tiles (after being told to stop once the sensor detects a specified distance)? Could your front wheels be touching the seam of the tiles at a critical point, thus causing some uncertainty?
[/quote] 7843C_2015_Competition.c (8.86 KB)
A PVC pipe practice field is likely to have small differences from a standard glass-boundary field. The PVC pipes are thicker than the metal framing, as well as rounded, so there is likely to be variation in where the plates “rest”.
If you have time to practice before official matches on a “real field”, you might be able to tweak the numbers for better performance. But realize that even “standard” fields may have a small amount of shear that will result in small differences between Field #1 and Field #2. As others have suggested, multiple sensors can assist with this.
I’m going to make a wild guess that when it makes the counterclockwise turn, the wheels slip a little differently on different surfaces. So the result is that your robot’s center pivot point isn’t in the same place each time. Consequently, after it detects the SkyRise base, it is off a little bit.
I wouldn’t feel bad. I think these sorts of errors are common with autonomous programs, especially ones that depend on time to control distance. My kids very often tweak their code as they play in a tournament. If the error is consistent, then try simply putting in an offset value.
OK, after looking at the pics and the code I have a few suggestions as to why it could be different
Why is the one motor set to 75 while all the others are at 60? That would not give you a pinpoint turn on the center of rotation. Maybe you are doing that for a different movement pattern to avoid the skyrise? That does not vary from place to place, but just seems odd.
The field you have is made of wood. The competition field is steel and plexiglass with variations in the surface where the plexi meets steel. That could account for difference in operation as the sound waves may bounce differently off the wood versus the steel or plexi. The shapes of the competition field are nowhere need as smooth as your wood walls either and could cause bouncing of sound waves.
I am unsure if two sonars on the same direction is a good idea and could be receiving each other’s signal. Try unplugging the bottom one and see if it operates differently. Like I said about the field with the plexi, it could cause a bounce from the bottom received on the top. But you use the bottom one on the way back so that may not be the right thing. As you come back with a skyrise in place sound waves bounce off the skyrise piece going willy nilly everywhere outward on the top sonar. So it may not interfere that much. However, when the skyrise piece starts getting off angle, is the top sonar able to see there’s no skyrise piece in front of it any more? (could be reading -1 since it is so close)
You don’t use encoders on the wheels. Battery life may account for some time based functions but not the sonar based ones. But that would be error in other steps of the routine.
You could move the robot until you stop seeing the base and judge how much room you have and move back to the mid point of the base. Encoders would help on this one to limit time/power based errors.
Using the sonar in CM can get greater resolution. Do that in the sensor set up.
Set up a different base finder to a rounded plexi with a button. Turn X clicks and let the guide reset the robot, go backwards a little, and drop it in.
Thank you to everyone who posted their advice and thoughts on why this happened. Our next competition is two days from now and I just worked with the programmer on the autonomous program. We didn’t have time to add encoders, but we will before the state competition. That will help. The programmer decided to try to correct the program with coding if the robot misses the base at the competition. Right now it scores consistently. At least now we understand why it may not work the same on a different field, and it’s nice to know other teams have had the same thing happen.
And thank you for your polite, well-written feedback. I know the forum members try to provide the best advice they can but all too often we never hear back from the people asking for help.
Hello! Everyone gave great advice! I would just like to say for state or any other large competitions I would advise against sonar. My team at a large competition had problems with it reading correctly. This was due to the fields being so close to the speakers. Just a little heads up:p
Ah the struggle with failing autonomous at competition! I know the struggles.
I spent around 25 - 30 hours over the span of a week developing a reliable autonomous for our team. It was very accurate at scoring 9 points each time… until we made it to competition.
The field that my team built was slightly off. It had a different material for the mats and the homemade walls were off by a couple centimeters. I was told they were exact to the real walls. Also one of our schools teams who didn’t come to the competition stole 4 batteries out of the 9 we have. The 3 robots who went to the competition from our school had to share 5 batteries. Of which we learned when we came to the competition they were all dead. All of these factors resulted in the fail of our autonomous routine.
All that time wasted. It was a depressing day once I found out the autonomous routine kept failing at the competition. Worst of all my team mates were quite mad that the autonomous I made didn’t work. They still are.
In conclusion, I’d invest in a real field. Without the correct measurements your autonomous could be a huge waist of time.
We have a 8 point autonomous right now with only timing and a sonar but a simple small factor can not get any points at all. The sonar when you think about it is pulsating a “sonar” in the direction it is placed, if it is placed in front of a round object, like the peg base. Since the base is round a lot of the sonar will wrap around the base and only some will be deflected back towards you robot. This can make small mess ups within the autonomous.
I would advise getting a gyroscope to help with that, which we are getting monday so mainly depends on how difficult you want the programming.
And btw if you can’t invest in a real field, make it the exact dimensions as the field which is posted on the vex website and triple check everything.
