Today, I was extremely excited to pick one of my favorite songs of all time for my robot to dance to, however, my song was rejected as “too controversial,” despite it being the national anthem of a country >:(
I also learned how to use functions. I got my robot to shuffle in virtual worlds, and I’m going to make it move to the beat of “Eye of the Tiger.”
I still haven’t decided what songs to choose, but I have some move ideas. I’m thinking that I can make the robot move across the room, and wave its arm up and down. I might even make the robot move on the spot as well. I think I could probably make the robot move in a zigzag pattern to the beat of the song. If possible, I’d like to get LED lights working on the robot. Also, maybe I’d add to my robot to give it more parts (moving or sensors), to find more combinations of moving parts that my robot could utilize. Maybe for a certain part of the song, I’ll have the robot go backwards. I’ll try to include both point turns and swerve turns.
I will probably choose the song “Eye of the Tiger” as my song.
What was this challenge about?
This challenge was about programming our robots to traverse a course. We did this through the use of a new tool that we had previously not used known as “shaft encoders.” Initially, I believed that this would be a simple challenge, however, through the many, many technical difficulties we faced, I learned that making the correct code is only half of the battle.
A shaft encoder
What did you know before the working on the challenge?
We knew basic movement and motion commands in RobotC for our robots, however, we mostly used virtual worlds instead of a real robot, as we were quite inexperienced. We also knew a vague definition of what a shaft encoder is, but we never tried using one at all. Before this challenge, we hadn’t done too much with our robots, so we didn’t see too many technical difficulties.
A screenshot of an older version of virtual worlds on RobotC
What are the technical difficulties for completing the challenge? List them out and explain why they are difficult.
During this challenge, we faced many technical difficulties. In fact, we probably spent more time trying to fix technical difficulties than we did actually working on the challenge. Some of them include: the shaft encoders not registering, the firmware not updating properly, one motor going faster than the other, motors not working, batteries not working, and wires getting tangled/removed our robot. These are just a few of the many technical difficulties we faced, and they were difficult because the time we spent trying to fix these could have been spent on actually doing the challenge, which left us with less time to work on the program itself. Many of these problems required us to literally take apart our robots to replace the parts with new ones. We spent entire lessons simply surveying the class to see if other people were having the same problems as us, and trying to narrow down the cause of said problem.
One of the many errors we faced was a firmware issue, there should only be one light on.
Describe the approach(es) (e.g. time vs shaft encoder) you tried throughout the problem solving process.
To get our measurements as precise as possible, my team used mathematics to solve for the values required for the robot to go certain distances and to turn certain angles. We found the distance that the robot would move after one full rotation of the shaft encoder (it was 35 cm). We then found the full length of the portion we were using (with measuring tape), and divided it by the distance of one rotation to find the amount of rotations needed for the specific distance (8.4 rotations). Using this number, we found the number of rotations required to get through a specific distance by multiplying it by 360. For angles, we did the same process. We found the required value for a 90° turn, and used this ratio to solve the angles required. To get the angles in the first place, we used a protractor.
In the end, our mathematics did not work flawlessly. It was very close, but due to age from the motors and/or shaft encoders, the mathematically accurate values did not work perfectly. This led to us using trial and error, slightly adjusting values and testing repeatedly until we got a good enough demonstration.
Some of the calculations we used to solve our distances and angles.
Did you use the virtual world to test your program? Was it useful?
No, we tested with our actual robot. Virtual worlds would have been good for testing, however, as I mentioned earlier, some of the motors are old, and there are natural errors that can happen in the real world that are not possible to be recreated in the virtual world.
What have you learnt in the process? Any new insight?
I learned a lot about how to use VEX robots and RobotC, and I’ve learned a lot about good troubleshooting methods. Some of the methods I used could have been more effective, and I now know that. For example, if I had double-checked the motor and sensor setup from the start, I could have saved time replacing parts that could have possibly been working properly. Overall, I’ve learned a lot about troubleshooting, as well as how to use VEX robots in person, and on the computer with RobotC.
After slight problems last lesson, my teammate and I were able to finally get our shaft encoders to work perfectly. We also fixed all other issues with our robot and our computer. Now, our goal was to traverse the course set before us. We went about doing this by using mathematics, division, and trial and error to determine the correct values to set in our code in order to make the robot move the required distance. We used measuring tape to find the length of each section. Then, we calculated the distance our robot would move when we set the axle rotation to 360. Then we found the length of the portion divided by the length of 360 rotations, and then we multiplied this number by 360. This was done to find the amount of rotations required for the beginning area. However, due to age or human error, the robot was unable to reach this point using our calculated value, so we resorted to trial and error.
For turns, we used a protractor to get the exact angle required. We also found the amount of rotations required for a 90 degree turn. Using a ratio of number of rotations divided by 90 degrees, we were able to calculate the number of rotations for a specific angle (found with the protractor). Despite age/human error, our turns worked very well. All we need to do is some last minute adjustments to our distances (which we are still testing) and we should be good to go for the entire course.
Some of our math we did to calculate the values required (not all of it worked):
|