Today we were given ultrasonic sensors and given the tasks of understanding how it works, how to use it, and document it.

1.

The Ultrasonic Sensor has two 3-pin cables, both connected to the analog pins on the Vex Cortex. Similarly to the shaft encoders, we use “SensorValue()” to figure out the value the sensor measures. However, instead of degrees, it measures the distance an object in front of it is, and is able to measure objects 3 centimeters to 3 meters away, otherwise the sensor returns a value of -1. The sensor uses sound waves at a frequency of 40kHz, higher than the human hearing range of 20 Hz to 20 kHz, thus giving the illusion of working “silently”. 

We could use the sensor to warn a robot we use about when it is close to a wall, to avoid any collisions. For example, if we were to use an “if” statement:

if(SensorValue(sonarCM) < 20)

{

“EAT”

}

then the robot executes “EAT” when it finds an object less than 20 cm away from the sensor.

2.

As said above, it is able to detect objects 3cm to 3m away, and sends signals at 40kHz. It has precision great enough that it is able to detect a pole of 3cm diameter at a range of 2 meters, using a piece similar to a microphone to read the sound waves that bounce back to calculate distance. However, a flaw with this system is that due to its dependency on sound waves, if the surface it is trying to detect is a material that partially or completely absorbs/refracts sound waves, it either: Weakens the signal to where it may not be readable, or results in no signal at all, making the Ultrasonic Sensor not completely reliable.

3.

Here is an example of a code I made that utilizes the ultrasonic sensor on the premade Vex Squarebots.

The first program uses the sensor very simply. It will travel forward until it sees an object 20 cm away, then turns 180 degrees and drives forward. Meanwhile, the second one is slightly more complicated. It travels until it sees a wall/object in close proximity, then looks left and right and determines the side of a greater distance, then travels in that direction.

Ultrasonic Sensor Example Code

Ultrasonic Sensor Example Code 2

What is this project about?

We were given the task of making our Vex Squarebots dance to a song for a maximum of two minutes. We had the choice to choose our own song. We had to choreograph the song in sync and creatively portray the song through the robot.

Why did you select that music? How does it work with the movement?

In my thought process, I decided to have the robot follow a piece of music note by note, as it appeared to be easier than matching it to a video on youtube, where I would have to experiment to achieve in sync timings. Because of this, I chose a song without lyrics, and thus came upon the theme to the Pink Panther. To reflect this, in the song the robot moves relatively slowly as the song is slow paced and in the style of Jazz.

Did you take any reference from other robotics dance?

Since Andrew was doing the Habanera from Carmen, he had the arm do the bass portion of the song while the robot moved to the melody. From this, I realized I could also use the robot arm on the Squarebot to move to the bass of the song. The video Mr.Lin showed us when he first assigned the project of a Squarebot dancing also inspired me to think of how the robot should move before we started working on the project.
What are the challenges you encountered when completing this project? How did you solve it?

In the beginning, a major challenge I had was figuring out how to program the robot to follow a sheet of music, as it is different from just listening to a youtube video or an audio file. To solve this, I first had the piece of music move at a speed of 120 bpm. This means there will be 120 beats in a minute, and since there are 60 seconds in a minute, it made the calculations easy, as in each second there are two beats, which correspond to 1 quarter note in the music score. Then, I made multiple functions that I could control how fast the motors moved, and for how many beats in the song, as the there was a delay function that waits for a certain amount of time.

Another issue I encountered in the start of the project was using decimals for the number of beats the robot moved. Prior we had only learned how to use the integer Function, so all numbers we put in were rounded to integers. Mr. Lin helped me solve this by showing me the Float function, which uses the value of the number I enter instead of rounding it to the nearest integer.

A third problem I had was very minor. In the code, I created a turn function and a swing turn function that turned the robot in place. However, throughout the program at times instead of turning the robot just stops. I solved this by increasing the speed of the motors, as the robot needed more power to turn, while before i just gave a high pitched noise signaling something happening with the motors.

Can someone follow your blog and try to recreate the dance? (e.g. share the code, music and tricks you used to complete this project).

Yes it is fairly easy. They could also alter the code to match any song with a few modifications. However, I would suggest that instead of creating functions for each movement of the robot, have one function that you can do everything with. In the function, enter how fast you want each motor to move, individually, and how many beats in the song.

I have uploaded my code to show what I have done, and another file to show what would have been an easier way to program my robot.

New Setup Code

Pink Panther Dance Code

I have completed having our squarebot “Harambee 2.1” dance to the Pink Panther main theme. I have the two wheels in the robot match the melody while the arm plays the harmony bass. I found my approach to this task, following a music score rather than just a sound file, worked better since I finished quicker and had less issues timing the robot with the music together.

In addition to the standard squarebot, I have added a piNk pAnThEr module that shows the pink panther moving it’s left arm back and forth. I added this because I finished matching the robot with the song and had two extra classes.

1. I chose the Pink Panther as I wanted to choose a non-lyrical song. This is so that in the programming process it is easy to match the robot to the beat of the song.

2. I have completed the first section of the song and started working on having the arm do the harmony simultaneously.

3. In my program I am not using any sensors. However, I did approach this in a more mathematical/musical sense. I found a score of the Pink Panther online and downloaded it. I have a program I use to play back composed pieces in specific formats so that I can follow the score while it plays. I set the tempo custom to 120 beats per minute. I decided to do this as 120 is a multiple of 60 and the program will be much simpler to write due to this. I created multiple functions, such as moving forward, turning in place, performing a swing turn, and moving the arm. In all of these I can input the speed and for how many beats in a measure. This gives me ease in matching the robot with the song as I don’t actually have to time it through trial and error.

Another important function I made was a rest function, to reflect a rest in musical pieces. My approach to match the robot to the song note by note takes slightly more time, however, it is much simpler in timing the robot with the song.

4. In my program, I have set a variable that affects every function I create. It is a speed control, and is multiplied to every wait function. If I find that the robot moves slightly slower than the song, I change it from 1 to 0.95, to make the robot wait less. Similarly, if it moves to fast compared to the song, I change the constant from 1 to 1.005, so that the robot takes more time before performing a task.

5. The only challenge I believe I have had was when I was unaware of the “float” function. Prior I used the integer function, which rounds numbers to the closest integer. I found a problem when I need to the robot to move for 0.25 of a beat, as I would just not move. Mr.Lin helped me with this by showing me the “float” function which just stores the number including decimals.

Today we got time to work on a simple program to remote control our Vex Squarebot. I learned how to remote control it through the example programs in the Vex programmer. We also had to create a special function to activate when I press a button, which I set the robot to turn in circles for 4 seconds in each direction. Then I got some time to work on our final project, which was the robot dance.

1. What is a remote control? A remote control is a device used to tell another device what to do through live communication. As opposed to having the robot work autonomously, we give it directions of what to do as it is performing a task.

2. Why use remote controls? We use remote controls to control robots and other devices. This has some advantages over autonomous actions because if some mistakes happen, as we work in a physical work, we can quickly account for it. If a robot is working autonomously, it may encounter some problems, such as bumping into walls. A human can account for this with a remote control by controlling the robot, telling it when to move forward and when to turn. A remote control has many advantages over autonomous control, but there are also some disadvantages. For example, if a human makes a mistake, the robot could possibly have a worse outcome than if it performed the mistake itself.

3. Different types of Remote Controls Remote controls are used to control devices, but different types of controls are made to control specific devices. A computer mouse is optimized to move the cursor and interact with the computer, a TV remote has many buttons so you can choose channels to watch. A video game controller is made for the best video game experience, and a keyboard is made to input letters and language onto a device.

4. Spaceship remote control challenge Wireless remote controls use waves to communicate, and these waves can travel as fast as the speed of light. On Earth, there are no issues with this speed as the communication is almost instantaneous. However, in space, distance is drastically increased. Since the waves can at most move at the speed of light a spaceship that is at the edge of the solar system would take a longer amount of time to send and receive from. An example of a spaceship like this is Voyager 1, launched by NASA, who now takes at least 3 days to communicate with because it is so far away from us, even leaving the solar system. This large span of time for communication means that real-time control is no longer an advantage and it is more difficult to know what action the robot should do next.

5. Improving a remote control Many remotes are already pretty well made, but, if I had the option to improve a remote, I would improve the basic Television Remote. A TV remote has many buttons and is pretty complicated if you have never used it before. You should be given the option to simplify or complicate it as much as you want, and what system to use. Some remotes have buttons assigned to certain channels, and others have a channel selection control, so you can scroll through them. Something such as a touchscreen has the easy ability to be customized, and thus this concept you could use to create an easy customizable TV remote.

Today we continued with the dance unit. We first learned VEX had the ability to perform multiple tasks simultaneously, which gave us many new options, such as having the arm moving to one part while the rest of the robot moves to the other. I made use of this concept in my chosen song, which is the pink panther, which repeats the same bass for 9 measures before switching to an improvisation B section in the piece. I managed to have the main part of the song finished and begin the B section.

What is the challenge about?

The challenge we were presented with was to complete a course laid on on the floor of the Robotics classroom. It is composed of several lines of tape and we were given the task to have our robot follow the line as closely as possible and return back to the starting position which we were allowed to choose.

What did you know before the working on the challenge? Prior to this challenge, I had the knowledge that we could control the motors to make the robot move and turn at different speeds. However I previously I only had the capability of using

Prior to this challenge, I had the knowledge that we could control the motors to make the robot move and turn at different speeds. However I previously I only had the capability of using time to judge when to change a robot’s action. After learning about shaft encoders, the result is that the traveled distance is more consistent. This is due to the fact that usage of the robot drains the battery power, and a lower battery power results in the motors traveling slower when given a set speed.

What are the technical difficulties for completing the challenge? List them out and explain why they are difficult. Firstly, when we received our robot, the cables were placed somewhat randomly and in the first

Firstly, when we received our robot, the cables were placed somewhat randomly and in the first unit this was fine. However in the 2nd unit when we were given the option to use more parts of the robot (shaft encoders) we had to rewire the entire robot to match the premade names in the Vex Cortex code. Another issue was that due to manufacturing faults and numerous other factors, the left and right wheel motors did not move

Another issue was that due to manufacturing faults and numerous other factors, the left and right wheel motors did not move in the exact same speed when coded to, thus our robot was always driving towards the left when we program it to go straight. We compensated for this by programming the left motor to be quicker and the right motor to be slower. The only problem was when the battery power decreased the motors would again move in a different ratio from each other and thus we would need to keep adjusting the values. A third issue was that due to the robot being in a physical world, there would definitely exist a range of where a robot will deviate from the “ideal” attempt. Andrew and I had created a function for turning a set number of degrees and a function for driving straight a set number of centimeters. This gave us a lot more accuracy in our program as we only had to enter the function and the degree/distance instead of typing out the entire code every time. From

A third issue was that due to the robot being in a physical world, there would definitely exist a range of where a robot will deviate from the “ideal” attempt. Andrew and I had created a function for turning a set number of degrees and a function for driving straight a set number of centimeters. This gave us a lot more accuracy in our program as we only had to enter the function and the degree/distance instead of typing out the entire code every time. From this we found that in multiple tests the robot would usually turn slightly more or slightly less than what we programmed. For example, if an angle was measured at 91 degrees the value we put into the code could range from 80 to 100. There was no real way to adjust for this and we only had to pray we had the perfect run once in a while.

Describe the approach(es) (e.g. time vs shaft encoder) you used throughout/during the process. The only approach I used for the whole process for measuring was using the shaft encoders. This is because while time measures how long the robot moves the encoders measure how much each wheel rotates to the exact degree.

The only approach I used for the whole process for measuring was using the shaft encoders. This is because while time measures how long the robot moves the encoders measure how much each wheel rotates to the exact degree. As the robot was run from a battery and not a direct connection to a constant power source, the battery power would have an effect on how the robot ran. A lower battery power would have meant that the robot moved slower. If I had used this solution the robot would still move the same time even if it travels slower or quicker, making it nearly impossible to have a constant result, while the shaft encoders would measure the same value even if the motor was moving slower.

Did you use the virtual world to test your program? Was it useful?

Initially, when we created the function for turning, we tested in the virtual world to see if the function worked. We did this by first making the robot turn only 30 degrees, then in the next test programmed it to turn 300 degrees. Though the robot may have not turned the desired degrees, the test was to find out if the program responded to different values inputted, which it did. Then the only value we had to alter was the constant that our entered variable would multiply by to have the robot turn the correct number of degrees. The virutal world was useful in making sure our program worked before having to use time to download the program into the physical robot and have time to test it in the real world, saving some time.

What have you learned in the process? Any new insight?

I learned from this process that robots are not perfect and have imperfections. A code we intend to work every time may only work a fraction of the time without any human input or artifical intelligence to process results. I have learned better how to code vex squarebot, how the vex system works and specifically the shaft encoders on the robot to measure the rotations of the wheels. This unit helped me in learning the movement of robots and the current limitations of machines.

Today we were introduced to Carnegie Mellon Robotic Academy, a website that gives tutorial on how to use and program robots, such as the Vex Squarebots we are using in class. We were given the task to watch the videos on the shaft encoders and learn how to use them. From the videos I learned that they measure rotations in degrees akin to the traditional 360 degree measurements. However, an important factor to remember is that intertia and momentum area factor, and thus if we program to have the robot stop after the wheels move 720 degrees, it ends up around 780 degrees due to the momentum and inertia the robot have when moving forward. Andrew and I taped the wheels on the robot to observe this occur, and use the sensor debugger to find the exact degrees the wheels rotate.

Then, as we had extra time in class, Andrew and I began to program a function that turns a robot depending on how many degrees we want it to turn. We do this by setting the variable we enter in the function as the degrees we would like it to turn, and then multiply it by a constant, which we had to do multiple trials for, to determine the number of degrees one of the wheels should turn for the robot to turn the correct degree. Then we would have the motors rotate, one forward one backward, until one of the encoders reaches the designated degrees. We only managed to make it to turn right currently. However, we could use “if” and “else” statements next class to make the robot turn left or right depending if we set the degree as negative or positive.