Hi guys. Today I added some more comments in all of my bits of code. Here is what they look like.
Can finder code.Speed builder code.Main code.
The Robocup JR competition is in a weeks time now so I tested the robot on all of the lines that could possibly be in my competition. Here are the tiles that I tested the robot on.
The tiles that I might need to complete in Robocup JR.
They all worked really well so I experimented with my turn speed.
I had my turn speed set at 75 but my dad suggested to change it down to 30 or 70 to see if it would still work.
It worked on 30 and 70 so I wrote down on a piece of paper.
This is the end of this weeks blog so I’ll leave you with the word and phrase of the day.
Algorithm: Rules for solving a problem in a finite number of steps
If you are afraid to fail, then your probably going to fail – Kobe Bryant
Hi guys. Today I did a lot of coding today. I finally worked out why the code was saying “Hello”. I was running the wrong project! I also forgot about the ramp and did some coding on the can finder and deleted all my code I don’t need for the competition. When I got back to the ramp, I managed to get it to work.
I’ve only kept four pieces of code for the competition. The picture of the code is below.
My main code.My variables. My can finder code.My speed builder code.
I tried the older code on the black line. But it did not work. Dad suggested I might be running the wrong code because I made a new project called 19/08/08 James.ev3 but I was running James.ev3, the project I made at the start of my journey!
With the can finder, I had to add a bit so it locks onto the can first and then locates it. It does not show you this in my code, above, because these photos where taken on Thursday but we had an extra lesson on Tuesday so we were prepared for the competition which is happening in 1 weeks time. The can finder works really well and gets the can out safely.
When we get up to the ramp, it runs my can finder code. So I added bits in before my can finder code to make the robot go over the ramp. I added a block to drive straight for 2.1 rotations of the wheel. It worked before saving the can and it also worked while the ramp was quite far off the liquid spillage area.
The line follower is still in good shape so I feel good about the competition.
My next step: To add comments in my code so I understand it.
This is the end of this weeks blog. Now here is the word and phrase of the day.
Perseverance: Not giving up despite the tasks difficulty.
I want to be remembered as a great competitor and a great teammate – Steve Nash
Today I only had to make one last change to my line-following code to get it working. The code could run the robot around hints, through the sharp turns and over the ramp.
But there was only one challenge that had not been tackled – stopping at the silver indicating the start of the chemical spill and finding the can. I achieved one of those problems today in the code below:
This slightly blurry program is what I have been working on for the last year.
Today I added the major switch block in the fourth instance. I found out how to make a triple switch block to split the code into 3 parts. The part of the project I was working on was hints, the ramp and stopping on silver. To achieve this, I inserted a text variable called TurnDirection with 3 possible outcomes: F, L and R. The variable is changed every time the program runs through any of the top parts of the program: Left, Right and Forward turns. All I did was insert a variable write block to set the variables.
When the robot drops down into the fourth part of the code, it turns on a red status light indicating that the code is currently running in the hint part. It then reads the variable and directs the program into one of the three branches. Each branch then contains another switch block that deduces if the difference between the colour sensor outputs is equal to or less than 5. If so, then the robot assumes it is on grey. However, I noticed the robot also stopped at the beginning of the ramp.
To fix this issue, I made a variable to track whether the robot has gone over the ramp or not. The first time the code runs through the less than or equal to 5 part, it assumes it is on the ramp and goes forwards at a speed of 50 for 2.3 full wheel rotations. It then switches the ramp found variable to true, so the next time it finds the sensors having a difference of less than or equal to 5 it would cut out of the main loop and start searching for the can.
On Thursday this week, I have to bring in my can finder program on a USB stick from my laptop at home and improve on the old files. I also have to run a few tests to make sure the code runs consistently.
Useless fact of the Day: 14% of all facts and statistics are made up and 27% of people know that fact. Okayyyy..?
This week one of our main focuses was to add the Ultrasonic sensor to the robot. In case you don’t remember what the Ultrasonic sensor does, it can measure the distance from the robot to an object. It does that by firing high-frequency sound waves (hence the name ultrasonic) out of a T (transmitter) module that bounce off solid objects such as walls, or in our case, the can. The sound waves emitted from the T module then bounce back to the R (receiver) module. The time delay between firing and receiving is then calculated by the computer by an algorithm that converts the time delay into the distance. We use the Ultrasonic sensor for rescuing the can at the end of the line following course in the RoboCup Junior.
*picture of updated robot with ultrasonic sensor plz, Richard?*
Next week I am going to copy my old Can-finder program off this blog and put it back into my file.
The updated line follower with a loop cutout and a partially-working hint finder.
This week I managed to make a loop cutout for when the robot finds silver. This is mainly successful, but on one of the tries the robot found both sensors with equal values when it came across a hint instead of on silver. This would result in the loop cutting out early and causing an embarrassment in the competition. To stop this happening, I could insert a [wait] block into the hintFinder myBlock and make sure the robot actually is on silver before the loop cuts out.
I could insert the breakout checker in the [silver] section of the nested if/else split block.
Next week Richard plans to have a full-day session so we can make a program out of our best codes and try to fix the existing errors and any new bugs that pop up.
Useless fact of the day: “Stewardesses” is the longest word typed with only the left hand on a conventional QWERTY keyboard.
This week at coding we didn’t really do anything to make many changes. But we still did some. Now my code stops on green and grey .It now goes over the ramp without a little push over the little bump. Which there is a little bump when you first go onto the ramp.
This week there won’t be a picture because we didn’t really change our code and so we didn’t need to upload a picture and that means that the Blog will be a bit short today so I’m trying to make it as long as I can.
So this week the robot did everything I basically need it to. So, next week I will be working on making the stop on Green a little sharper and the robot to stop on the grey quicker and make the robot go faster and still work around the sharp corners.
This week Coding was a lot harder to do 11 students so I’m trying to make the best of next week trying to get ready for the competition because I am going to be away in America so I have to do my blog really early next week so I’m going to try and get really good as well.
Hi there. Today I did some more programming on how to get over the ramp. I’ve also changed bits in my competition code by taking bits out. The overall verdict for me is, “My code has just gone from working to not working”.
My code was looking very messy. Like this
My old code. Looks pretty messy.
But my new code looks like this.
My new line following code. Looks way tidier than before.
I did this so I could possibly just drive over the ramp. However, it didn’t work. When it went on the ramp it just said “Hello” and went off the ramp.
I managed to make the robot not say “Hello” just before we packed up. Since I duplicated my old code, I might have accidentally uploaded my old code instead of my new code.
That’s it for today’s blog. I’ll now give you the word and phrase of the day.
Bravado: A bold manner or a show of boldness intended to impress or intimidate.
If you do the work, you get rewarded – Michael Jordan
As I said last week none of our codes were working, so this week we were mainly trying to get everything going again.
I managed to get my line follower and hint finder working again, but I still have the problem on the robot not stopping after the ramp. What I started trying to do was to get the robot to know whether it is on green or silver. What I know so far : over 30 is white, between 20 to 30 black, 10 to 15 is green and 0 to 10 is silver. Now all I got to do is make sure the robot knows that too.
RoboCup jr is in about 2 weeks that means we all got to get our codes working soon. After getting the robot to stop on silver we still need to do the can finder code, so I think that’s what we’ll be working on next time.
I will keep you updated on how the codes going, but for now, bye…
This week our task was to make the robot achieve the whole course up to the can-finder. We aimed to complete the hints, the ramp and the silver – with the line follower still functioning perfectly.
My updated code…
Last week, I made a part of code that made one wheel turn backwards for every forwards turn of the other wheel. I discovered that by adding this code, I affected the turning speed of the robot. My turnSpeed variable was set to 50, which I chose because it was not too aggressive but could cope with the sharp corners of the line. However, with the sensors moved closer to the chassis of the robot, the robot made too aggressive turns to move over the hints, and the wheel turning backwards at 0.5x the speed of the other wheel didn’t help. With no hint detector in my code, the robot did 3 turns over the hint and ended up turning the wrong way.
To fix that error, I adjusted turnSpeed to 25, and decreased the back wheel turning ratio to 0.25. With this change, the robot could follow the hints.
To go over the ramp, I made a piece of code to detect when the sensors were off the mat and therefore receiving very little reflected light. I explained in my last post, as the robot goes up the ramp, the amount of reflected light drops as the sensors above the ground.
My solution to the problem was to add the reflected light values together, and deduce from that whether the robot was on a ramp, on a hint, on silver or on the line. I altered my old hint-finder in a completely new project to add the ramp.
My test code for the ramp-finder.
This is my ramp-finder test code. It found reflected light values and added them together to find the total. If the total was greater than 80, the robot outputted ‘RAMP’ and set the output variable to 0. If the value was less than 80, it would cut into my old silver/green hint-finder code, which used the Absolute Value to find the difference between numbers and deduce what colour the sensors were on and which way to turn. When I tested the program on the robot, it worked most of the time, but when I tried to incorporate it into my main line-follower, it stopped on silver and green and worked on the ramp only once out of 5 times.
Next week I need to add another part of my program to detect the difference between white and a ramp. The problem is that the code only has four switch block possibilities, as explained on this table below:
Sensor 1
Sensor 2
<50
<50
<50
>50
>50
<50
>50
>50
To add in my ramp-finder code, I need to add a fifth instance to distinguish the parts of the RoboCup Jr. map that are not possible with the regular line following code. I may have to achieve this by even adding a sixth instance for hints instead of the ramp.
Useless Fact of the Day: No piece of square dry paper can be folded in half more than 7 times. If you folded a piece of paper 103 times, it would be thicker than the Universe!
