Archive for the ‘Cool projects’ Category
We recently asked a group of engineering students from the University of Aalborg in Denmark to write about their experience using ROBOTC on a recent project. Check it out below!
Hi all! We are 6 software engineering students from the University of Aalborg in Denmark. As part of our Bachelor’s degree, we had to design and implement an embedded system, and we chose to design and implement a robot that would solve the Simultaneous Localization And Mapping (SLAM) problem. We called the robot ColumBot.
The hardware we were issued were LEGO NXT bricks and sensors as well as a few from MindSensors. MindSensors provided libraries for use with ROBOTC, which was one of the reasons why we ended up choosing ROBOTC as our IDE.
Work in Aalborg is group-based and many of the other groups spent the first weeks trying to get their NXT bricks set up for the firmwares they were using, but ROBOTC allowed us to have the part of the project kept to a minimum. ROBOTC provided us with a strong and versatile tool in solving our project, and was of great help.
Using ROBOTC, we were able to implement a mapping robot with a drive queue, with enough memory for 100m2, as well as a particle filter to correct the inaccuracies that arose from sensing when mapping. All this functionality was scheduled using a real time scheduling scheme. We do not believe this would have been possible with some of the IDEs used by the other groups.
ROBOTC has its quirks, namely much of the documentation is faulty. [Editor’s Note: ROBOTC recently went through a complete documentation overhaul to address issues like these – take a look at our help docs here.] As the focus of our project was to fit as much functionality as possible into the limited space, this problem mainly arose with the sizes of different types, where the documentation deviated from the reality. But the community is fantastic and many answers to difficult questions were found in the forums during the project period. The most useful features in our project were the Bluetooth Communication and the Debug Stream, which allowed us to monitor the robot remotely and communicate with it.
We would recommend ROBOTC to anyone attempting a build of the same size as ours, but advice you to be wary and test things for yourself, because this was sometimes a problem for us.
Check out one of our test runs here:
Xander over at BotBench (and future colleague!) created an awesome ROBOTC version of Conway’s famous Game of Life. As he states on his blog, “It was first thought of back in 1940, so it’s a real piece of computer science history.” The Game of Life has very simple rules: (taken from WikiPedia)
The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:
- Any live cell with fewer than two live neighbours dies, as if caused by under-population.
- Any live cell with two or three live neighbours lives on to the next generation.
- Any live cell with more than three live neighbours dies, as if by overcrowding.
- Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.
The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called a tick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.
Xander over at BotBench shared a really cool video a couple weeks ago when he attached a GoPro to his VEX IQ that was programmed in ROBOTC. He didn’t get any pictures of the robot with the camera on it, but you can see where it was held by the rubber bands on the end of the boom in the pictures below. The angle of the boom was also remote controllable.
And check out the video here …
Read more about this cool project and other things going on over at BotBench, here!
ROBOTC user, Sigtrygg (forum name), recently shared a project on the ROBOTC forums that they have been working on called the NXT Room Explorer Bot with Mapping Functions. Check out the YouTube video of the robot in action …
Sigtrygg description and breakdown of the bot …
The robot is based upon a standard REM-Bot but in addition equipped with a HiTechnic gyro, HiTechnic compass sensor and an omni-wheel. First the robot moves about 360° to calibrate the compass using the gyro (thank you to Xander Soldaat for code!). Then the robot moves its sonar-head to the right, to the left and in front position to get the distances according to its position. After doing this it turns around to the wall with the minimum distance and drives in front of it until sonar sensor detected a minimum sensor distance, e.g. 20cm. Then the robot turns parallel to the wall, moves his sonar-head to the right detecting the distance to the wall and drives counter clockwise parallel to the wall balancing distance. A mapping-task records the compass and odometry data every second and calculate the polar coordinates to cartesian coordinates (x,y). The coordinates are written as “map.txt”-file. So you can use Excel or an other program to draw the path which the robot had moved. In addition to that you can follow the path at the NXT-LCD-screen. I had to choose a scale for it, so you have to suit the scale to your room size. If the robots touch sensor has detected an obstacle the robot moves back and turn left for 90 degrees and continuous his explorer-duty always running counter clockwise with wall to the right. How to expect the end of path doesn’t suit exactly to the beginning because of inaccuracies of compass and odometry measures.
To read more about this project, check out the ROBOTC Forum post here!
Each module was created independently with common inlet/outlet bays so that they could be reconfigured in any order. They even include some of the new multicolored VEX IQ parts, coming summer 2014!
Do you have a cool project? If so, email us at firstname.lastname@example.org.
In my last post about the VEX IQ building system I had a small video featuring my VEX Quadruped. I’ve done a bit of work on it since then and the gait has been greatly improved. I also added some small rubber feet on the legs. These are the traction links from the Tank Tread & Intake Kit.
Due to the heavy load that these motors are under, you may find that the batteries will run down a bit faster than you’re used to. Good thing the kits come with a charger!
Up next on the agenda is to add some sensors and have it interact a bit more. The little wheels on the bottom are not used when it is walking; the robot is fully lifted off the ground.
I’ve taken some picture, so you can see how it’s put together. These should be enough to copy the design, should you wish to. You can download the program to run this here: [LINK]. Note that part of the code is based on the excellent guide on creating an Arduino based quadruped: [LINK].
Alexis and Noah are back again with another Student POV! This time, sharing how they programmed a robovacuum in ROBOTC Graphical Language for the VEX IQ platform.
In this challenge, we programmed the Vex IQ robot to perform a task that was based off of the robotic vacuums that vacuum autonomously while avoiding obstacles. Our challenge was to program a robot that would perform like a robotic vacuum. Therefore it would be able to move autonomously while avoiding obstacles.
We started our program by putting in a repeat forever loop. This means that our program will continuously run until we stop it with the exit button on the Vex IQ brain.
We then made a plan on what we needed our robot to do. Within the repeat loop, we had to put an “if else” statement. An if else statement is a command that makes a decision based on a condition. With our program, our condition is the bumper sensor. The robot checks the condition of whether or not the bumper sensor is depressed. If the bumper sensor is not depressed, it will run the command inside the curly braces of the if statement. If the bumper sensor is depressed, it will run the commands inside the brackets of the else statement. We had to put this statement inside a repeat forever loop because without it, it would only make this decision once.
We then had to decide what task the robot was to perform when the sensor was depressed. So we set up commands within the curly braces of the else statement shown here.
Below is an image of the final program.
Now our robot is able to move around autonomously while avoiding different obstacles!
– Alexis and Noah
Hi, we’re Alexis and Noah, two eighth grade students at Hopewell Memorial Junior High School. Earlier this week, we did the Robo 500 challenge. To write the programs, we used the recently released ROBOTC Graphical software for the VEX IQ. The goal of the challenge was to complete two laps around a Vex IQ storage bin.
We completed the challenge by using timing and degree measurements. The first step was to get the robot to move forward. For this, we would use a basic motor command.
In ROBOTC Graphical, it gives you the option to choose the values in which you want your motor to run by, such as time and rotations. In this challenge, we chose time.
From there, we experimented with different time values until we found the timing that was needed to finish the side of the challenge before the turn. Through testing, I found that 3.7 seconds covered the distance needed.
Now, what was left was the largest challenge of the program, the turn. Timing a turn can be challenging on seconds alone. So, I used degree turns. I started with a 180 degree, which brought me around about 45°. Due to the drift of the robot when it moves forward, I had to make the turn slightly less than double the 180° turn. I settled on a value of 300°.
Once the values were established, the rest was just repeating the commands so the robot would go around the whole box. Here is an example of my final program.
We were then thinking about how the turns were a hassle with trial and error, and contemplated a better way to turn. So, we decided to use a gyro sensor to have the most accurate turns possible.
To start out the program we had to reset the gyro sensor so the sensor could record the degrees from zero.
From here we moved forward to the end of the course for time, and we moved forward for about four seconds. Then we used a while loop. A while loop is set to check a condition and while the condition is true, it performs what is inside of the curly braces of the while loop. In this case the condition is while the gyro sensor value is less than 90 degrees.
We would then repeat these actions until the robot has made two full laps around the course. Here is the program for one lap. To do two laps I would just repeat this program again.
We were able to finish our programs efficiently in a short amount of time due to the design of the new graphical programming. This new design enables you to drag over commands from the function library; such as, moving forwards and backwards, turning, and sensor commands while avoiding the hassle of painstakingly typing each command. This reduces the time spent on each program and allows us to speed up the pace at which we program, and we are able to complete challenges in a shorter amount of time.
To the left, we have an image of the function library and a depiction of what would happen if you dragged a command into your program. The command would line up with the next available open line and would give you options as to what values you wanted to program your robot with.
If you’re a student who would like to contribute to the blog, let us know at email@example.com.
Ray McNamara is relatively new to ROBOTC, having only really started to seriously use it within the past year, but already he’s come up with some interesting projects that caught our eye. The “Monster Ball Sorting Factory”, which he shared with us on the forum, is definitely a cool project we had to share.
The Factory is a cooperation between two robots Ray’s designed. One is an NXT Forklift truck, which uses a special non-standard part: a pair of Omni Wheels in the back to replace the standard single rotating wheel, which makes the Forklift’s turns a lot more reliable.
The other is a long, conveyor belt and claw arm robot that sorts balls piled onto a conveyor belt based on their color. It then puts them into containers, which the Forklift periodically takes and places in a slot so that the robot can dump it into a bigger bin. This robot is a combination of an earlier project, the “Bin Emptying Machine,” that takes the balls out of their container with a rail mounted crane that does the sorting.
We asked Ray about the project and his motivation for doing it and he replied:
“My Monster Sorter is still a work in progress, much to my wife’s annoyance due to the amount of real-estate it has been taking up in the lounge room since early December 2012. I hope to have it all running on a single NXT (excluding the Forklift), by means of 2x Mindsensors Motor Multiplexers and 1x Mindsensors Sensor Multiplexer. If my calculations are right, the single NXT Brick will control 8x Motors and 10x Sensors.
My motivation was the challenge to learn how far I take the standard Colour Sorter model. It really started back in 2010, when I convinced Rotacaster Australia‘s GM to turn his industrial rollers into Omni-wheels for my LEGO Models and robots. After almost exhausting the possibilities of Holonomic Platforms, I looked into other uses for the Rotacaster Wheels, resulting in my Forklift Truck.
Once I had my Forklift Truck, I needed to put it to work. The Ball Sorting Factory was what evolved over a few days. Since then I have been fine tuning the hardware and the ROBOTC code used to control it. In the process, I have also been Beta Testing some Mindsensors Sensors and Multiplexers with it.
I always try to include a detailed description, photos, video, code and CAD files for my robots when they are published to my blog. Although it takes a lot of time to put my blog posts together, I feel it is worth it. I get a lot questions and praise from many people who use my resources. I especially enjoy helping out students with their queries.”
To download the code to this project, click here – ROBOTC Code for Factory and ROBOTC Code for Forklift.
Thanks to Ray for taking the time to respond to our questions! Visit Ray’s website at www.rjmcnamara.com to see more projects, pictures, codes, videos, and much more.
Do you have a cool project or video you want to share with us? If so, send us an email at firstname.lastname@example.org.
We ran into Paul Utley from Pitsco at the 2013 FIRST Championship who designed a model of the Curiosity Rover with TETRIX parts, NXT brick, and programmed in ROBOTC! We were lucky enough to get a short interview with him about it. Check it out here …
If you are at the 2013 FIRST Championship in St. Louis, MO., make sure to stop by and check it out in person. For more information on Tetrix go to http://www.tetrixrobotics.com