Chinese recording here

中西饮食文化的异同

中方和西方因为文化的原因有许多不同饮食文化的差别和相同。其中几个最主要的异同有饮食的风俗，食物做法和品种，还有他们用的餐具。

中西方的饮食文化有许多异同，其中一个是做客的风俗。第一，中国人吃饭时通常都会是团团圆圆，坐在一个圆桌上，互相分享在转盘的几盘菜。西方却不太一样，大家通常会坐在一个长桌上，各叫各的菜，偶尔会互相分享。还有，通常，一个中国人做客时会有很多不同的规矩，例如客人不可以随便坐，吃晚饭时不可以临时走开，吃饭时不应该把主人做的饭给吃光，出去吃饭时应该狠狠的枪弹。虽然在西方也有很多人做以上的东西，但这不算是他们的一个正了八景的饮食风俗，儿知算是他们的礼貌。

还有一点是中西方食物做法和品种。因为中国人习惯团团圆圆，他们上的饭就回有各种各样，丰富多彩。通常会先上一些小凉菜，然后再上一大碗汤，然后才上热菜。虽然西方上菜的顺序有些相同，但因他们习惯个人有自己的菜，上的菜比较简单一点。例如，通常吃西餐时会先上一个萨拉或汤，然后就上热菜。这些热菜通常也都是大肉或鱼。

再有一个中西饮食文化异同的一点是餐具。首先，中国人吃饭时往往是大家互相分享几盘儿菜。所以为了保持干净，中国人通常都会用公筷公勺。西方却大多会各吃各的，所以没有用公勺公筷的原因。其次，因为中国人的饮食习惯（吃素菜，米饭等）和传统习惯，中国人主要使用筷子。因为西方喜欢吃大肉和菜，他们用刀叉比小方便。中西方在餐具里唯一一个相同的一点是两方都会用勺子来喝汤。

总的来说，中西方饮食文化在饮食的风俗，食物的做法和品种，和用的餐具有很多差异，但也有挺多的相同。希望以上的作文儿让你更加了解中西方饮食文化的一些异同。

The challenge presented to us was to write a code for a robot which would allow it to follow an irregularly shaped track. This challenge was a group effort. Before starting to do this challenge, I already knew the basics such as how to make the robot move forward, and turn for a given amount of time. Turns out, that was all that I really needed to complete the task.

There were many technical difficulties when working on this project, some involving the robot itself, and some involving the code. The first one was obviously getting the correct ratio of time to distance in order to make a precisely timed movement. This sounds very simple in theory, but much more difficult in practice. We started with the easy measurements, which were the straight lines. My partner and I calculated the exact amount of time needed for the robot to travel 10 centimeters, and used that as a reference. The harder part was the angles. My partner and I spent quite some time trying to come up with a ratio which would work for all the angles. In the end, we gave up and decided to just do trial and error for each of the angles. Another major problem was that the motors and battery performance was different nearly every time. What worked one day might not work the other. There was no easy solution, and we just decided to just make the code easier to change.

There are many different approaches to solve this challenge, all of which were used by my fellow peers. My partner and I decided to use a timescale instead of the more popularly used shaft encoders. The reasoning behind this was that it would keep our code simpler. Using a shaft encoder might work better in theory, but many of my peers still experienced complications with it. We thought that using time would just be a lot simpler.

My partner and I did the majority of our testing on the virtual world. This was because it was extremely difficult to run the entirety of the track without having some other group desperately trying to run their program. The only solutions were either come when there isn’t class (often times there would still be people testing their robot at that time), or test on virtual world. The virtual world did not have the layout of the track, but it did have a grid which the robot drove on. This grid could act as a reference to roughly tell us how the robot would run in the real world.

I have learnt a lot from the project. i learnt that I am capable to do things with relative ease and speed if I put at least 90% of my attention on it. I also found out that despite enjoying to work alone, it can still be nice having somebody working with you. I thoroughly enjoyed this project and would certainly do something similar in the future if given the chance.

The objective of the choreography project was to use different coding functions to make a robot do a series of movements to accompany a song. I chose to use the song “Hokey Pokey” because other than it’s comedic value, it also has a simple, medium-paced beat, but very specific timings which would be fun and challenging to synchronise with the robot. As my song was very different from the pop songs used by many of my peers, I was not able to share or take too many aspects of other people’s dances.

I have encountered many problems during both the coding and testing phases. The general backbone of the code was quite easy and was done within a week. However, because I was coding pretty rapidly, and there were hundreds of lines that I had to write, there were more than a few errors. Most of the errors were easy to find and fix such as a missing semi-colon, or an extra space. This troubleshooting process took around two classes. The hardest part of the project was being able to take my code out of the virtual world, and make it work on the physical robot. Naturally, the first thing that went wrong was the robot itself. The wires on the motors were starting to get loose and fall off, the robot would always turn more on one side, and the robot wouldn’t always start at the same time, making it de-sync from the music. I fixed these problems by replacing the wires, and compensating for the lopsided power in the code.

I have made my my code easy to follow by including comments and clear breaks at different parts of the dance. The most that anybody will need to do to get the dance running is to upload the code, open the song, and press start.

-#pragma config(StandardModel, “RVW SQUAREBOT”)

//+++++++++++++++++++++++++++++++++++++++++++++| MAIN |+++++++++++++++++++++++++++++++++++++++++++++++

task main()

{

wait1Msec(2500);

motor[rightMotor] = 127; //BOTTOM BL CK IS LEG IN LEG OUT

motor[leftMotor]  = 127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(100);

motor[rightMotor] = -127;

motor[leftMotor]  = -127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(100);

motor[rightMotor] = 127;

motor[leftMotor]  = 127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

 wait1Msec(500);

motor[rightMotor] = 127; //shake it all about

motor[leftMotor]  = -127;

wait1Msec(666);

motor[rightMotor] = -127;

motor[leftMotor]  = 127;

wait1Msec(667);

motor[rightMotor] =127;

motor[leftMotor]  = -127;

wait1Msec(667);

motor[rightMotor] = 0; //pause btw shake in and turn

motor[leftMotor] = 0;

wait1Msec(2100);

motor[rightMotor] = 127;

motor[leftMotor] = -127;

wait1Msec(2000);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(1000);

motor[rightMotor] = -127; //reset

motor[leftMotor] = -127;

wait1Msec(3000);

motor[rightMotor] = 0; //Break between leg switchdtgvnm ,

motor[leftMotor] = 0;

wait1Msec(2000);

wait1Msec(2500);

motor[rightMotor] = 127; //BOTTOM BL CK IS LEG IN LEG OUT

motor[leftMotor]  = 127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(100);

motor[rightMotor] = -127;

motor[leftMotor]  = -127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(100);

motor[rightMotor] = 127;

motor[leftMotor]  = 127;

wait1Msec(2010);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

 wait1Msec(500);

motor[rightMotor] = 127; //shake it all about

motor[leftMotor]  = -127;

wait1Msec(666);

motor[rightMotor] = -127;

motor[leftMotor]  = 127;

wait1Msec(667);

motor[rightMotor] =127;

motor[leftMotor]  = -127;

wait1Msec(667);

motor[rightMotor] = 0; //pause btw shake in and turn

motor[leftMotor] = 0;

wait1Msec(2100);

motor[rightMotor] = 127;

motor[leftMotor] = -127;

wait1Msec(2000);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(1000);

motor[rightMotor] = -127; //reset

motor[leftMotor] = -127;

wait1Msec(3000);

motor[rightMotor] = 0; //pause between arm leg

motor[leftMotor] = 0;

wait1Msec(2000);

motor[armMotor] = 50;

wait1Msec(1000);

motor[armMotor] = -50;

wait1Msec(1000);

motor[armMotor] = 50;

wait1Msec(1000);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(500);

motor[rightMotor] = 127; //shake it all about

motor[leftMotor]  = -127;

wait1Msec(666);

motor[rightMotor] = -127;

motor[leftMotor]  = 127;

wait1Msec(667);

motor[rightMotor] =127;

motor[leftMotor]  = -127;

wait1Msec(667);

motor[rightMotor] = 0; //pause btw shake in and turn

motor[leftMotor] = 0;

wait1Msec(2100);

motor[rightMotor] = 127;

motor[leftMotor] = -127;

wait1Msec(2000);

motor[rightMotor] = 0; //pause

motor[leftMotor] = 0;

wait1Msec(1000);

motor[rightMotor] = -127; //reset

motor[leftMotor] = -127;

wait1Msec(3000);

}

//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

An ultrasonic sensor works by sending out a high frequency sound pulse and times how long it takes for the sound to echo back, much like a dolphin. The two openings in the front each serve a different purpose, one to transmit, and one to receive signals. The VEX ultrasonic sensor in particular sends a 40Hz sound wave (inaudible) and has a range of 3cm – 300cm

You can use the sensor by writing a code. This code requires a threshold (40 in my code). You will also need a while loop in order for the robot to properly continuously run it’s program. With these, you can set the robot up to do an action if the sensor senses something exceeding the threshold.

In my code, my robot will first go forward at a slow speed. When an object is detected closer than the threshold, the robot will stop moving forward and go backwards at the same speed that it went forward for one second. After this, the robot will charge forward for 5 seconds at the object that it sensed.

Definition: Control of a machine or apparatus from a distance by means of radio or infrared signals transmitted from a device.

Uses: The general use of a remote control is to be able to manually control something from a distance. The use of R.C. over conventional programming would vary depending on the scenario. Remote controls can also be used for gaming.

Different types of R.C.: Standard/dedicated remotes, third party remotes, programmable remotes (creating macros), proprietary system (ability to integrate control of all systems with one controller)

Spaceship R.C. challenge: The distance from earth to Pluto is roughly around 4 light hours. This means that for a signal to get from Earth to the robot itself would take 4 hours. Moreover, the robot would most likely have cameras to allow the controller to see. Therefor, the robot would take 4 hours to send the camera signal to earth, then 4 hours for the control signal from earth to pluto…

RC improvement: If you put two objects in a quantum entangled state, they will interact in ways such that the quantum state of each particle cannot be described independently of the others over any distance. If this can be harnessed, it could be used to make a remote control that could control an interstellar spaceship

How does VEX RC work: The controller sends out a signal and the robot receives the signal and reacts based on what signal is projected.

What was the question about when we started the unit?

During the beginning of the unit, we were presented with the question of what is a robot. We were each given a sticky note and told to define a robot before we did anything more. Everyone seemed to have a similar idea of what a robot is. Afterwards, we were told to find the definition of a robot, and revise our definitions. I defined a robot as a man-made  machine or software which follows a program but can adapt to different scenarios. What have you done this unit? Over the corse of the unit, we covered most of the basics to robotics. We started off by learning the definition of a robot (as stated above). We then made presentations on what a robot is and basics of a robot. My presentation covered the definition of a robot, differences between a robot and machine, currently used robots, and possible future robots. We also did a small convention called Hebocon where we would build non technically advanced robots which will fight other robots. It was a good experience for me because my robot made it to the finals multiple times (can’t beat the brick). After that activity, we we all given pre-built robots and to to try to figure out how to program and trouble. The first unit was great fun.

List out few questions you had during the exploration process of this unit.

this type of robotics is relatively new to me. Even though I have past experience with sensors, motors and most of the building part, I have very little experience in the hardware. My first question is how to code and what coding language is used. I also found to that there were two programs on the computer for programming the robot. One is raw coding and the other is much like the lego mindinstorms programming software.

Do you feel confident to discuss with other people about the knowledge and topics covered in this unit?

I feel that I’d be somewhat confident in talking to someone about the topics covered in this unit. I feel that I have a good idea of what a robot is and some currently used robots. I also would be happy to talk about my Hebocon robot (which is basically just a toy car taped into a taco box). The programming is a bit different. I’d be  okay to discuss the programming with someone else, but if I am told to educate someone, it would be very difficult.

How can we learn better as a group? What can you and the class do to learn better?

Obviously there are some issues with our class. I feel that maturity is a amain factor (as the class was majority freshman). This is somewhat difficult to change unless we implement preschool discipline tactics. One tactic that might work is to just kick out the person who is being annoying, and let them back in after a certain amount of time. This would probably get better as the year goes on. Other than that, I fee that the “figure it out yourself” teaching strategy, although frustrating and time consuming, does force us to actually learn. This learning strategy forces us to listen, and there is no option to ignore the teacher (mainly because they aren’t saying anything). The class can learn better if we were given more self learning opportunities while still having guidance from the teacher.

Other questions related to this unit.

My main question is obviously about the coding. We would probably learn more about coding in future units, but currently, my main question is just how to code and what language is being used.