Archive for April, 2011
After many, many months of stalling, I’ve finally got my act together and finished up 2.0 beta 1 of the Driver Suite. I’ve made a LOT of changes, mostly internal but I hope you like them. Keep in mind that this is a first beta release, so I need all the feedback I can get. My email address is in the header files, I am sure you’ll find it.
The biggest change is the way I am now handling the HiTechnic Sensor MUX. Rather than having to scan the SMUX for attached sensors, the individual sensor driver configures the SMUX for its specific port. This makes it much easier to use. In order to not have to compile the Sensor MUX code into your program if you don’t own one, I have made it mandatory to include a SMUX specific include file when you want to use it. This in turn “unlocks” the SMUX specific functions in each driver that is supported by the SMUX.
I’ve also spent a LOT of time and effort to make the drivers leaner in terms of memory and numbers of functions. Some drivers were easier to trim than others. One of the ways I have done this is by removing all single value functions from drivers where it made sense. An example of this is the HiTechnic and Mindsensors accelerometers. You can no longer just fetch one axis, you have to get all three at once.
I cannot guarantee backwards compatibility with programs made to work with the 1.x driver suite, too many changes have been made.
I’ve decided to forego the individual changelogs in each driver and example file, it’s becoming too much work, so I am not going for just the one changelog for all the files.
- Removed unnecessary common.h includes from examples
- Changed arrays from structs to just typedefs, all drivers have been adjusted
- Motor mux stuff split off from common.h
- All SMUX supported drivers now use new SMUX mechanism
- Modified common.h to separate SMUX functions from rest using defines
- Removed ubyteToInt from all drivers and common.h
- Test programs have had their sensor types reconfigured, you will need ROBOTC 2.26
- HTSMUX-driver.h newly added, has all the new SMUX functions split from common.h
- MMUX-common.h newly added, contains all the MMUX functions split from common.h
- Added min/max functions for floats
- light-common.h: newly added, adds RGBtoHSV conversion (thanks Mike Henning, Max Bareiss)
- HTCS-driver.h/HTCS2-driver.h: added functions for HSV values
- HTMC-driver.h: Improved relative heading algorithm
- Added DGPSreadTravHeading() to DGPS-driver.h and fixed commands
- Removed single axis functions from HTAC-driver.h
- Removed functions for single signal strength in HTIRS and HTIRS2.
- Removed No Wait functions from EOPD driver
- Removed HTIRL-NG, is now named HTIRL
- Changed arguments from byte to ubyte in MSLL-driver.h
- All applicable Mindsensors sensors now have an optional "address" argument that can be ommitted if using the default (thanks for the suggestion hedgepigdaniel)
The version of ROBOTC these drivers have been tested with the most is 2.26 beta. Other versions may work, but I haven’t checked. If you are having trouble with another version of ROBOTC and these drivers, let me know and I’ll see what I can do.
You can download the beta 1 right here: [LINK].
Thanks to some really cool work by Xander, I2C sensors for the NXT can now be used on the Cortex as well (with a little bit of effort). As we’ve covered in some of our previous posts, ROBOTC and the VEX Cortex unlock a ton of cool robotic applications – controlling pneumatics, controlling high torque and high speed motors through relays, outputting to the LCD screen, ect. Being able to use the repository of I2C sensors available for the NXT on the Cortex unlocks many, many more.
To demonstrate this, we’ve chosen the Mindsensors NXTCam. With the NXTCam, you’re able to connect it to a computer over USB and “teach” it to track up to 8 different colors. Once it’s hooked up to your robot, it returns data related to the colors it’s tracking – size, x and y positions, ect. This make it ideal for tracking a colored object, distinguishing between multiple different colors, and even advanced line tracking (more on that in a future post).
In this video, we’ve trained the NXTCam to track the color red. ROBOTC code uses the data from the camera to center the robot on the red ball and drive up to it until it’s within a certain distance.
This year at the St Louis FTC finals, Team 4466 (R.A.B.B.I.) will holding nightly FTC practice field sessions as part of their after pit activities.
On Wednesday they will also be organising workshops and lectures and a Q&A session with your truly (Xander Soldaat). I’m going to have to get up at the ungodly local time of 4AM to be able to be there via Skype but I am sure it’ll be fun.
So if you’re looking to learn more about advanced ROBOTC programming techniques, how to debug your Samantha module or what’s coming in the upcoming major release of my driver suite, make sure you’re at the downtown Hilton “Independence” conference room, starting at 20:00 on Wednesday.
You won’t want to miss this!
Congratulations to all the VEX Robotics teams that participated in the World Championship! After seeing all of the creative, well-engineered solutions, it’s clear how much hard work you all put in this season. Job well done!
The ROBOTC team is thrilled to have been part of the event, and even more thrilled to be part of your actual solutions this year. It was great to meet so many of you, hear what you had to say about ROBOTC, and troubleshoot with you in person. We listen to your feedback – please continue to give it to us in the off season.
What is the VEX Robotics World Championship?
The VEX Robotics World Championship is a gathering of top robotics teams from around the world to celebrate their accomplishments and compete with/against the best of the best. The 2011 VEX Robotics World Championship will include top teams from over 200 VEX Robotics Competition tournaments happening in cities around the world from May 2010 to March 2011.
The Game – VEX Round Up
VEX Round Up is played on a 12’x12’ square field. Two alliances – one “red” and one “blue” – composed of two teams each, compete in matches consisting of a twenty-second autonomous period followed by two minutes of driver-controlled play.
The object of the game is to attain a higher score than your opponent alliance by scoring tubes upon goalposts, owning goalposts and by low hanging or high hanging from the ladder. A bonus is awarded to the alliance that has the most total points at the end of the Autonomous Period.
You can view more information on the VEX Robotics World Championship, along with the competition winners at the Robot Events Championship page.
[Many thanks to Shep for contributing this amazing project! Description and Source is all from Shep’s blog]
Years of development, months of building and programming. Here it is.
About the Lego Quad Delta Robot System.
This system uses four Lego parallel robots which are fed by two conveyor belts. As items flow down the conveyor belt toward the robots, each item passes by a light/color sensor mounted on each conveyor. When the item is detected, a signal is sent to the robots telling them information such as the color of the object, which belt the object is on and the position of the object on the belt. The robot reaches out and grabs the item from the moving conveyor belt when each item gets close enough and moves it to a location based on the color of the item.
The cell is capable of picking and placing objects at a rate of 48 items per minute. Each robot can move 12 items per minute, or it can move an item in 5 seconds!
Delta Robots, also known as Parallel robots are commercially available from several manufacturers. They go by names such as ABB Flexpicker, Bosch Paloma D2, Fanuc M-1iA, Kawasaki YF03N, and Adept Quattro s650H. They are known for moving small objects very quickly, usually at two hundred or more moves per minute. Parallel robots are often used in many industries such as the food industry where the payload is small and light and the production rates are very high. Many times a series of parallel robots are used to do things like assemble cookies, package small items, stack pancakes and much, much more.
Each robot operates independently. The robots receive a signal from the master, which in this case is the NXT that controls the light sensors. The signal contains information about the color, lane, and position of each object. When the signal is received, the data is stored in a chronological array. When the object gets close enough, the robot goes through a preprogrammed series of movements based on the information in the array.
At the beginning of each run, all three arms move slowly upward until they each hit a touch sensor. After all three arms have reached the top they all move down together to a predetermined zero position and the encoders are reset. At that point all the robots wait for the first signal which will be the master sending the belt speed signal. The robots can automatically adjust movements such as where they pick up the objects based on the belt speed.
Immediately after the belt speed information has been received, each NXT brick will sound off in a timed sequence with their respective brick number. This is an error checking technique. If the operator doesn’t hear the full “ONE, TWO, THREE, FOUR, FIVE, SIX” there is a problem and the run should be terminated and restarted.
The signal is an eight bit binary light signal that takes about 170 milliseconds to transmit. The master NXT blinks the LEDs that are attached to each robot on and off at an interval about 20 milliseconds each flash. Each robot is equipped with a Lego light sensor that easily sees the short flashes. The same signal is sent to all the NXT bricks, but data encoded in the signal determines which robot will move the item. The robot’s NXT brick decode the message and sends that information to a procedure that does the appropriate movements.
The binary signal is converted to a three digit number such as 132 or 243. The first digit is the lane. Possible values are 1 and 2 corresponding to conveyor 1 and conveyor 2 respectively. The second digit is the robot number and the possible values are 1 through 4 corresponding to each of the four robots. The third digit is the color of the object. The possible values are 1 through 6, i.e. BLACK=1, BLUE=2, GREEN=3. YELLOW=4. RED=5, WHITE=6. The position of the brick is noted by the time that the light signal is received. The robots calculate the position of each object by using the time when the signal was received relative to the current, dynamic time. The belt moves precisely at 100 inches per minute so based on this, the position of the item on the belt can be precisely calculated.
A few signals other than brick information and belt speed are programmed to be sent. The master can send an emergency shut down message in which all robots immediately stop what they are doing, drop their bricks and go to their home position as well as stop the conveyors. Signals can also be sent to make the robots dance, play sound files and music files concurrently.
The precise kinematics for the movements of the robots are dynamically calculated using detailed formulas that convert the Cartesian coordinates (x,y,z) of the location of the brick into the angles of the servo motors (theta1, theta2 and theta3) and vice versa. This is the heart and soul of the robot. Without precise calculations, this project would be nearly impossible.
As the gripper or “end effector” is moved around, it becomes necessary to calculate the best route for it to move. The best route is usually a straight line. This is done by locating the start point (x1, y1, z1) and the end point (x2, y2, z2) and then calculating a discrete number of points that lie on the line between the two points. For each and every movement, the robot first creates an array for all the points in between and then moves nonstop from point to point to point through the array until it reaches the end point.
As the robot moves around, each motor speed is adjusted relative to the other motors speed in a manner that all three motors arrive at their target position at the same time. This makes all the movements very smooth and the robot doesn’t shake too much. The motor speeds are adjusted so that the robot moves as fast as possible.
Since the objects on the conveyors are moving at all times, the robot actually moves to a position where the object will be rather than where the object is actually at. Also, when the robot grasps an object, it doesn’t lift it straight up, but up and forward slightly so that any objects behind the object on the conveyor belt won’t hit the object that is being moved.
It is possible for the robot to be overwhelmed by having too many objects to pick up. Once an object goes past a limit point where it is too far to reach, it is removed from the queue and will not be picked up by any robot.
As the robots place items in the bins, the release point is shifted slightly so that the items won’t pile up.
The grippers are each driven using a single pneumatic cylinder. The cylinder is cycled by a valve equipped with a medium PF motor connected to an IR receiver. Each NXT is equipped with a HiTechnic IRLink sensor. The NXT controls the gripper by sending a signal to the motor through the IRLink sensor. The motor then rotates clockwise or counterclockwise for one quarter of a second to switch the pneumatic valve. This is a very effective way of controlling Lego pneumatics with a NXT.
THE AIR SYSTEM
The air system must be robust because the pneumatic cylinders on the grippers move about 96 times a minute. This requires a great deal of air. The air compressor consists of six pumps (with the springs removed) turned by three XL PF motors. The pressure is measured using a MindSensors Pressure sensor. The pressure is kept between 10 and 13 psi to maintain good operational speed and gripping capacity. The whole system will not start until air pressure is up to a minimum of 8 psi, and an audible alarm sounds if the pressure drops below 8 psi. At this point, the operator can help the compressor by manually pumping up the system to the required pressure.
The three XL-PF motors are powered using a 9v train controller. This is done so that consistent power is transmitted to the motors. Air compressors tend to use batteries very quickly and using a train controller avoids that cost.
There are also six air tanks for storage, a manual pump, a pressure gage, and a pressure release valve to purge the system of pressure. The manual pump is primarily used to assist the compressor if it can’t keep up.
The compressor motors are turned on and off using a Lego servo motor and a PF switch. As the pressure sensor senses the pressure going above or below the thresholds, the motor moves the switch back and forth to add air or turn off the compressor.
The conveyors are controlled by a dedicated NXT brick. The timing and speed of the conveyors is critical so that the items will be positioned accurately. The speed of the conveyors is governed by a proportional controller. They were originally controlled using a PID controller, but it turns out that a proportional control was adequate. The speed of the conveyor can be vary from zero inches per minute up to two hundred inches per minute, but one hundred inches per minutes is the best for all the robots.
The NXT brick that controls the conveyors reads the same light signal information as all of the robots, but ignores most of the signals.
Each conveyor is ten feet long.
LIGHT CURTAIN/COLOR READER
The light/color sensors mounted on the conveyor do double duty. Their default mode is as an ambient light sensor but they are frequently changed to color sensor. A PF LED light is mounted opposite to the light sensor to give a high value of light detected. When an item passes between the LED and the light sensor, a low light condition is detected and the sensor immediately switches mode to a color sensor. This can be seen when the sensor briefly emits an RGB light as a brick passes in front of the sensor. As soon as the color is correctly read, it immediately switches mode back to an ambient light sensor and waits for the next item. When the color is determined, the brick then sends a signal to all of the slave bricks and an audible color sound is played.
There is a condition when two bricks pass by both light sensors at the same time. It is impossible to send two signals at the same time, so the first item to be detected takes priority and the second brick signal is sent 400 milliseconds later. A special signal is sent to tell the robot to adjust the position timing to account for the 400 ms delay when the brick comes to be picked up.
The frame structure holding the robots is highly engineered. The combination of the weight of all the robots as well as the constant movement is a considerable problem. The main horizontal member is achieved by layering Technic bricks with plates. This configuration is very strong and has very little sag. Movement is also minimized, but not completely eliminated.
The two main posts in the middle carry most of the weight and do a great deal to stop the structure from moving while the robots are operating. The four outside posts help, but are mostly for support. The diagonal braces are quite small relative to the size of the other members, but actually do a great deal to stop movement.
All of the posts are made from standard Lego bricks with Technic beams attached around to lock them together. The structure is completely tied together as one piece, but can be broken down into eight parts for transport.
I have a personal fascination with this type of robot. I find the movements mesmerizing and extremely interesting. The movements of the actual robots are extremely fast and accurate and defy belief. I especially like the fact that the location of the end effector can be precisely calculated from the angular location of the three servo motors positioned at one hundred and twenty degrees from each other.
This is not the first parallel robot that I have built. My first delta robot was built in 2004 using the Mindstorms RCX and was very crude and not very useful. After several more attempts, I finally found a design using the Mindstorms NXT system that worked well. At that time I still hadn’t worked out the kinematics but I found a way to fake the movements by positioning the end effector by hand and reading the encoder values. Then I used those values to create a series of movements that closely resembled an actual robot.
I have researched for about six years and built this project many times. This project took about five months to build and program. It was purely a labor of love for this robot.
I don’t know how to improve on the current design. As you can tell if you have read this description of the robot, I have exhaustively researched and built to every goal I have. Sadly, I believe that I have reached the limit of what can be built using only Lego building elements.
From the Boy Scouts of America press release:
When people think of the Boy Scouts of America (BSA), they envision activities like camping, knot-tying, and canoeing, but soon, they’ll need to add robot-building to that list. Scouts in 2011, through the introduction of the Robotics merit badge, now have the opportunity to design, build, and demonstrate a robot of their own creation.
The Robotics merit badge is part of the BSA’s new curriculum emphasis on STEM: science, technology, engineering, and math. The BSA focus on STEM takes a fun, adventurous approach to helping Scouts develop critical skills that are relevant and needed in today’s competitive world. The new merit badge is one of 31 STEM-related merit badges that Scouts can earn.
To earn the Robotics Merit Badge, Scouts must be able to demonstrate the following:
- Safety when working with Robotics
- Knowledge of Robotics in Industry
- General Robotics Knowledge
- The Ability to Design, Build, Program and Test a Robot
- Share and Explain their Robots
- Attend, Participate or Research Robotics Competitions
- Research and Explain Different Robotics Careers
More information on the Robotics Merit Badge can be found at BoysLife.org.
We have just released an update to ROBOTC for CORTEX & PIC.
Click here to download the latest version
Teams Attending VEX World Championships at Disney World, Florida:
You should update to Version 2.32 of ROBOTC for Cortex and PIC and update your Master Firmware and VEXnet Game Controller Firmware before arriving to the competition. This is not a mandatory update, but is strongly recommended to ensure compatibility with the VEX Game Fields at Disney.
- Master Firmware upgraded from 2.72 to 2.81 / Fixes idle motor issues
- VEXnet Joystick firmware upgraded from 2.32 to 2.41
- Downloading the Joystick Firmware no longer prompts ROBOTC Firmware download as well
- Updated Natural Language Library to version 2.0, adding additional functions
- Updated ROBOTC Sample Program Library
- Updated ROBOTC Help File
- Corrected the icons for the ROBOTC Toolbar Icons
- Robot > Software Inspection feature available
- Minor bug fixes
ROBOTC is proud to be part of Project Lead the Way’s educational initiatives! From the PLTW website:
PLTW prepares students to be the most innovative and productive leaders in Science, Technology, Engineering and Mathematics (STEM) and to make meaningful, pioneering contributions to our world.
PLTW partners with middle schools and high schools to provide a rigorous, relevant STEM education. Through an engaging, hands-on curriculum, PLTW encourages the development of problem-solving skills, critical thinking, creative and innovative reasoning and a love of learning.
The PLTW middle and high school STEM education programs give students a brighter future by providing them with a foundation and proven path to college and career success in STEM-related fields. STEM education is at the heart of today’s high-tech, high-skill global economy.
In February 2011, PLTW announced that they will be integrating VEX Robotics and ROBOTC into four of their most exciting courses: Gateway to Technology, Principles of Engineering, Computer Integrated Manufacturing and Aerospace Engineering. From the original article:
Another critical key to the VEX® Robotics platform transition is the adoption of a more comprehensive programming software. PLTW is pleased to announce its new partnership with Carnegie Mellon’s Robotics Academy, a research based, world leader in educational robotics that prides itself on providing high-quality, education-friendly software and curricular solutions. The Robotics Academy is responsible for the creation of the ROBOTC® programming language and has developed a scaffolded learning continuum that is widely recognized as one of the world’s best solutions to introduce students to programming, an important skill set for students. ROBOTC® software provides students with an industry standard development environment which has been optimized for education. In addition to this high quality programming tool, the Robotics Academy will also provide the PLTW network with an exceptional range of support resources based on educational and industry research and best practice.