Robotics Academy Blog  

Part 2 of 4: The Range of Strategies

Part 1 of this series set the stage for an investigation into student mathematics usage at a local LEGO robotics competition. In Part 2, we'll take a look at the types of strategies that teams came up with for solving the challenge, and how those different approaches fared in the competition.

Interviews with the Teams

22 teams from the greater Pittsburgh area participated in the 2010 May Madness robotics competition. Investigators from the University of Pittsburgh's Learning Research and Development Center (LRDC) and Carnegie Mellon University's Robotics Academy (RA) were able to interview 16 of them about their team sizes, grade levels, and experience levels for both students and mentors. They also asked teams to describe their solutions to the challenge and how they came up with those solutions.

The Different Strategies

As expected, different teams came up with very different solutions. In fact, they were so different that apples-to-apples comparisons became nearly impossible at the whole-strategy level. Fortunately, every strategy did include one common component: moving the robot to the center of the board to begin scoring points.

Table 1 breaks down the different strategies that teams used, and the number of teams that used each approach.

Strategy	Teams Using this Strategy	Strategy Description
Guess-Test-Adjust	6	Students guess an initial value for the motor rotations, then try it out on the robot and adjust the value to be bigger or smaller based on whether the robot went too far or not far enough. It is often not clear how students arrived at their initial guess. Teams who used this strategy also differed in how they made the adjustments: some used a systematic strategy in which they went up by whole numbers first, then smaller numbers, while others adjusted in much more arbitrary increments.
Calculate-Test-Adjust	4	The only strategy that was explicitly math-based. Students measure the distance the robot has to move. They then make a mathematical prediction about the correct rotation value for the movement based on the size of the robot's wheel or a known distance the robot moves in one rotation. All of the teams who made their initial calculation this way had to fine-tune that value afterwards using adjustments that resemble the Guess-Test-Adjust strategy or the View-Mode strategy.
View-Mode	3	Students use the view mode on the NXT brick and then “walk” their robot (push it by hand as the wheels roll along the ground) to the desired destination. They read the value displayed and use that value in their program. (A good explanation of this strategy is in the NXT User Guide pp. 31-32 and in this screencast.)
Sensor-Based	3	The only strategy in which the robot does not travel a set number of wheel rotations (or duration of time). Students program the robot to move until a physical sensor stimulus provides a cue to stop. For example, running forward until the robot bumps into a nest and a Touch Sensor is triggered.[1]
Total # of Teams	16

Table 1: Strategies observed for the robot's first movement[2]

That only 3 teams used a (non-rotation) Sensor-Based strategy is likely a direct consequence of the nature of the Botball Hybrid II challenge. In particular, the toilet paper tubes were not steady enough for a robot’s touch sensor to contact them without tipping the tubes over. As a result, teams seeking to score using the tubes had to choose non-contact means of controlling their robot's movement. The 3 teams that did use a Sensor-Based strategy on their first move were all going for the nests, which are much heavier than the toilet paper tubes. However, for various reasons, even these teams abandoned use of their sensors in their moves later in the challenge. In addition, the board surface featured few marked lines, making line-following and line-tracking less attractive.

A Math-Based Strategy for Calculating Motor Rotations

The remaining 13 teams programmed their initial move using the rotation sensor, effectively moving a set distance forward. However, those 13 teams used decidedly different methods to choose their motor rotation values, especially the initial value. Some teams guessed; others used the view mode; but four teams chose to start with a math-based prediction.

These groups all ended up using variants of a three-phase strategy called Calculate-Test-Adjust:

1. Measure the how far the robot has to move and use mathematical means to calculate a (theoretically correct) rotation value for the movement
2. Run the robot with the predicted value
3. Compensate for any observed overshoot or shortfall by making small "tweaks" to the rotation value

Students used several different mathematical relationships to arrive at their predictions. For example, one group measured how far the robot moved forward with each motor rotation, then calculated how many of those 1-motor-rotation distances the robot needed to move the total distance to the target. The students then entered this value into their program, tested it, and fine-tuned the value to get the robot to exactly the right spot.

One notable quality of this strategy is that it is not purely mathematical – all 4 teams that used Calculate-Test-Adjust for their initial motor rotations value ended up having to refine their value with guessing or with the view mode afterward. A math-based calculation does not appear to be sufficient on its own for this type of problem.

The Relative Success of the Different Strategies

So how well did these math-using teams fare compared to their sensor-using, guess-and-testing, and view mode-ing peers? The 22 teams were ranked based on their best point score after 3 rounds of the competition. Figure 1 below shows the average rank of the teams who used each strategy. Bigger bars indicate a higher average ranking for the teams using that strategy — meaning teams who used that strategy had better scores in the competition.

Looking at the data in this way, the View-Mode strategy was the most effective and the Sensor-Based strategy was the least effective. The Guess-Test-Adjust and the Calculate-Test-Adjust strategies seem to be in the middle and similar to each other. Given that this particular challenge was somewhat biased against the use of sensors, it probably makes sense that teams who used the Sensor-Based strategy did not fare well. But what of the others?

The View-Mode strategy did seem to do particularly well. The investigators theorize that this strategy leads to success for two reasons. First, teams that use this strategy can program their movements quickly. Figuring out the correct motor rotations value is straightforward and fast, so that frees the team up to spend their limited time improving other parts of their solution (e.g., making their robot base solid and their attachments functional). Second, the View-Mode strategy is very reliable, so once teams get a motor rotation value by using this strategy, they then have a lot of confidence that that value is the right one and will work well. In essence, the View-Mode strategy is easy to implement quickly and gives very reliable results, which explains why teams who chose that strategy tended to do well in the competition.

The Success of the Math-Based Strategy

Compared to rolling the robot on the ground and reading a number, both Guess-Test-Adjust and Calculate-Test-Adjust are slow to implement and potentially less reliable as well. And in the results, teams who used these strategies did okay in the competition, but not as well as teams who used the View-Mode strategy… case closed. Right?

Averages, it turns out, don't tell the whole story. Calculating the standard deviation of the ranks gives us a sense of how tightly clustered these different success levels are for each strategy. If everything were cut-and-dry, we'd see all the View Mode teams clustered at the top, followed by the test-and-adjust teams, and sensor-based teams at the bottom.

Instead, when we add the standard deviation as error bars on the previous bar plot of the average ranks (see Figure 2), some things fall into place, and others fly loose. The View-Mode strategy was the least variable – teams using it were tightly clumped in the rankings – further supporting the idea that that strategy is straightforward and reliable. But the Calculate-Test-Adjust strategy has a huge variability (the error bars span almost the entire range of possible ranks)! Something important remains untold.

In fact, a closer look at the 4 teams that used the Calculate-Test-Adjust strategy shows that 2 of them were the top ranked teams in the entire competition (ranked #1 and #2 out of 22 teams). This suggests that using a math-based calculation strategy can be very powerful. At the same time, the other two Calculate-Test-Adjust teams were #17 and #21 out of 22 in the rankings – the complete opposite end of the scoring spectrum.

This dramatic separation in performance suggests something powerful (see Figure 3). Perhaps it is not enough to simply use a strategy; the result may hinge dramatically upon the strategy being used right. Perhaps when the Calculate-Test-Adjust strategy is implemented well, it is just as quick and just as reliable as the View-Mode strategy, if not even better. Done without a full understanding, however, the calculations could turn into distractors.

The research team theorizes that teams who are fluent with mathematics can use math-based calculations to their advantage by determining the correct motor rotation values for different moves relatively quickly. As with the View-Mode strategy, this time savings frees resources for use on building tasks and fine-tuning overall strategy. Teams that are less fluent in mathematics, however, would take longer to perform the math-based calculations, and make more errors, thus taking time away from working on other important parts of the task.

Conclusions

Conclusion #1 – Not many, but some teams do use math. And of the teams that do use math, there is widely varying success, from some of the most successful to some of the least successful.

Overall, teams found a range of ways to approach the challenge. Different challenges may favor different types of strategies, but the May Madness event saw a variety of approaches employed. Some strategies did seem to lead to better success in the competition. In particular, the View-Mode strategy seemed to be very successful for teams, presumably because it is quick and reliable. Not many teams chose to use the math-based Calculate-Test-Adjust strategy, but those who did ended up with both the highest scores in the competition, and some of the lowest scores. This suggests that for the math-based strategy more than any other, it matters not just that a team used that strategy, but how they used it.

Fortunately, in addition to the day-of-competition interviews, the research team also met with a few of the teams outside of the competition to understand their solution strategies in more depth. The winning team in the competition was one of these. Did using math really help this team be successful? And if it did, then how? Continue on to Part 3 to find out about the winning team's strategy and their use of math.

Part 3: A Winning Strategy » (coming soon)

Notes

1. One could argue that the rotation sensor is a sensor like all the others. In particular, the programming logic is the same, so a strategy that used the rotation sensor could also be labeled Sensor-Based. But here we think the distinction between the rotation sensor and the other sensors (e.g., touch, ultrasonic, and light sensors) is meaningful as the rotation sensor is the only one that will make the robot move with little regard to what is out in the world. Strategies using the other sensors will move varying distances depending on the way the objects in the world are configured, but the rotation sensor strategy (within some error) will always move a consistent amount.

2. There was one other strategy that teams used to determine how many motor rotations to use in their program. We call this strategy the “Overshooting” strategy because it works in situations where it isn't critical that the robot moves a particular amount as long as the robot moves far enough. For example, when approaching the nests it was okay if the robot went too far because it would just push the nest forward a bit, but the nest would still be in a position where it was easy to grab. This strategy didn't work with the toilet paper tubes, because if the robot went too far and bumped into them, they would fall down and would then be much harder to grab. In cases when overshooting was acceptable, teams were able to choose a motor rotations value that was safely big enough without having to worry if it was exactly right. No team used this strategy on their initial robot movement and teams were more likely to use it when programming the manipulators, so we didn't include it in our primary list of strategies.

Part 1 of 4: Introduction and Background

Every September, thousands of FIRST® LEGO® League (FLL) coaches and mentors around the world crack their knuckles, dust off their parts bins, and prepare to dive into an intensive three-month odyssey of technical twists and twenty-first century tutelage as they guide their teams to success in the annual FLL competition. But what exactly is success in a world of gameboards and gracious professionalism? Is the highest scorer really the biggest winner? What do students actually gain through their participation? How does it happen? And so, how should the enlightened coach choose from the multitude of competition strategies that lie open as the new season dawns?

Perhaps we can learn something from the recent past.

Since 1997, the Robotics Academy (RA) has been helping teachers, mentors, coaches, and students have positive educational experiences with robotics. Among other things, the Academy develops curricula, offers teacher professional development, and hosts robotics competitions. Recently, the Robotics Academy — in cooperation with the University of Pittsburgh’s Learning Research and Development Center (LRDC) — has been investigating ways to deepen students' experiences with robotics by incorporating math in their activities.

This blog series describes what RA and LRDC researchers found when they interviewed teams at a local LEGO robotics competition, looking to answer a few key questions:

• Are there opportunities to use math in a typical robotics competition problem?
• Does using math have any impact on a team's score?
• Can using math deliver “success” in any other sense?

In short, the investigators found that the answer to the all three questions was an overwhelming yes — there are opportunites to use math in a LEGO robotics competition setting, and when teams do use math it seems to be helpful in ways not limited to points and trophies. Ultimately, the research team arrived at 3 major conclusions:

1. Not many, but some teams do use math. And of the teams that do use math, there is widely varying success, from some of the most successful to some of the least successful.
2. The most successful teams do use math purposefully and efficiently, and their math use is a prominent factor separating their solutions from the solutions of the rest of the teams.
3. Even when a team's use of math doesn't lead to success on the challenge, just attempting to use math can have other benefits in terms of improving students' understanding and developing more positive attitudes about math and robots.

Each remaining article in this series will examine one of these conclusions in detail and describe how we arrived at each one. But first, let’s set the scene.

An Initial Investigation

Since 2003, the Robotics Academy has hosted the FIRST LEGO League (FLL) Pittsburgh Regional Championship. Last Fall, the Academy decided to see what it could learn by interviewing participating teams on the day of the competition. Robotics Academy researcher Ross Higashi interviewed a sample of the more than 70 teams that competed in the 2009 regional competition and put together two Robotics Academy Blog posts that identified who an FLL team is and the connections to Science, Technology, Engineering, and Mathematics that they make. Although praising the article overall, a comment to one of the posts challenged researchers to go into more depth:

If “a few highly successful teams have shown great adherence to principles of good design”, can Carnegie-Mellon or FIRST make their stories, plans, approaches available more widely to the community? Otherwise, without good examples, it will remain hit-or-miss for the vast majority of the teams.

Richard Ho, comment posted January 30, 2010 on the Robotics Academy Blog

And so a followup plan was devised. Surely another round of interviews could find good examples from which the whole FLL community could benefit! The research team’s first opportunity to conduct interviews was at a local competition called May Madness, on Saturday, May 8, 2010 at the Sarah Heinz House in Pittsburgh's North Side neighborhood. Although not as large as the FLL regional championship, the May Madness event attracts the same types of teams and uses similar challenges.

The Challenge

The 2010 May Madness competition included a number of different events, including separate challenges for different age divisions, different robot platforms such as VEX and TETRIX, and even a non-robotic Alice storytelling competition. To provide the most FLL-relevant information, the interview team focused on the “Botball Hybrid II” LEGO MINDSTORMS NXT challenge, geared toward elementary and middle school age students.

Although not quite as complex as typical FLL challenges in terms of the number of missions or the variety of objects on the board, the Botball Hybrid II challenge includes a number of elements that require sophisticated solutions. Two teams occupy the board at the same time, a black team and a white team. Each team can have one robot on the board at a time and the teams start at opposite ends of the board. The object is to get the most points possible in a 90-second round. Points are obtained by collecting ping pong balls and toilet paper tubes of the team's color and also common nests and foam balls. Knocking the ping pong balls loose gets some points, but the most points are obtained by bringing the objects back to a team's end zone. Even more points are obtained by lifting the objects into the gutters on the side of the table See gallery of images below for pictures of the game board, the items on the board and the specifications, a list of the rules of the challenge, and the points system.

The Findings and the Future

How did teams try to solve this challenge? Did math come into the picture at any point… and if so, did it help? Should coaches bother encouraging students to try using math in a challenge like this?

Each remaining article in this series will focus on answering one of these questions. Part 2 of the series describes the range of strategies that teams employed, Part 3 details the winning strategy, and the Part 4 discusses some alternative versions of success that were observed (Parts 3 & 4 will be released soon).

As you read through the research team’s findings and interpretations, please let us know what you think by leaving a comment on the blog! And if you are planning to attend this year's Pittsburgh Regional FLL Competition, the Academy would love to have your team be a part of the next round of investigation (send an email to Eli Silk if you are interested). We hope you find these articles helpful and wish you the best of luck in the upcoming competition season!

Part 2: The Range of Strategies »

The Robotics Academy is happy to announce the release of ROBOTC for Cortex 2.25.

We’ve made lots of changes in ROBOTC from 2.20 to 2.25. We’re continuing to improve ROBOTC with the Cortex system. This new version is fully compatible with the VEX Cortex and the VEX PIC systems, along with the VEXnet upgrade system for the VEX PIC.

Click here to download the latest version

Firmware Downloader Built-In: Firmware Download for ROBOTC Firmware, Cortex Master Firmware and VEXnet Joystick Firmware built into ROBOTC now!

Download Method Chooser: Easier to choose how you want to download your program. Always defaults to VEXnet and USB, but you can manually choose to disable VEXnet and download over USB only.

Quick Preferences: This allows you to set key preferences with only the click of a button. Make ROBOTC work the way you want it to!

Other New Features and Bug Fixes:

1. Build is able to program both PIC and Cortex platforms successfully.
2. “Auto save” before compile was broken.
3. “Previous Platform Type” was not being correctly saved into Windows Registry.
4. Add code to handle “Device Removal” and “Device Acquire” without long hangs of application.
5. Added a flag to Preferences -> Internal” to indicate whether firmware downloading should be read verified.
6. Fix “Priority” column in “Task Status” debugger pane. It was not properly displaying.
7. Move “Debug Stream” from Super-User to “Expert” menu.
8. Add a 250 millisecond delay after telling Cortex to enter download mode before attempting the autobaud sequence.
9. VEX Cortex Integrated Master Firmware Loader inside of ROBOTC.
10. Add support for run-time strings in the VEX LCD display routines.
11. Fix conlict between Digital pin 4 and 10. They both share the same external interrupt index and it was possible to hang the Cortex. Fix makes both pins work correctly — previously pin 10 was not working — for external interrupts. But the hardware prevents supporting sensors that require external interrupts on both pins at once.

Good news everyone! 2.25.1 BETA has just been made available.

Download it here

ROBOTC for MINDSTORMS 2.25.1 is a maintenance release for bug fixes and small functionality changes. You do not need to uninstall ROBOTC to upgrade to 2.02, the installer will handle the upgrade process.

New Feature: Quick Preferences – Allows you to change some key ROBOTC settings with only a single click. If you have requests for specific features inside of the “Quick Preferences”, let us know!

New Features and Bug Fixes in ROBOTC for MINDSTORMS 2.25.1 BETA

1. Improved “Step Over” debugging command. Previously you may have had to hit it several times for one statement because some opcodes (e.g. “setup sensor”) did a short delay which would abort “Step Over” partway through. THe short wait is disable if in “Step Over” processing.
2. Bug in “Motors and Sensors Setup” for NXT. It was trying to range check the “encoder ticks per revolution” field which does not apply to NXT.
3. Calculation in firmware of “available flash” broken. Fixed it.
4. “Poll NXT devices” should do an optimized single poll on firmware versions that support this opcode. The check was incorrect — got broken when firmware version changed to 8.xx as ‘7′ was hardcoded as major firmware version.
5. NXT Motors and Sensors Setup. Changing HiTechnic hubs was not properly removing sensors that were already defined on the sensor port.
6. Move “Debug Stream” from Super-User to “Expert” menu.
7. Fix “Priority” column in “Task Status” debugger pane. It was not properly displaying.
8. Fix bug in “#pragma autostarttasks” implementation. It should only impact the tasks defined in the relevant file. Instead it was impacting all tasks.
9. Add available flash memory size to display of “File Management” window.
10. “Auto save” before compile was broken.
11. Deactivate ROBOTC feature now working – Wasn’t working in 2.16.1 BETA.

If you’re experiencing any issues, please send an e-mail to support@robotc.net with details of the issue you are experiencing.

One again, the Robotics Academy will hold training sessions for coaches and mentors of First Lego League teams at the National Robotics Engineering Center at 10 40^th Street in the Lawrenceville section of the city.

The first session, for new coaches and mentors only will be held on Tuesday, September 14 from 6:00 pm until about 7:30 pm.  This session will review the role of the coach and how to build team solidarity.  We will cover areas such as ‘How to prepare for a tournament’ and give you an idea of a time line for your team.  There will be a short tour of the NREC facility so that there will be no surprises for you or your team on the day of the tournament.  Powerpoint slideshows on robot building and use of sensors will be shown.

The second session is designed for all coaches and mentors.  There will be two days of training, both presenting the same program.  These sessions will be held on Tuesday and Wednesday, September 21 and 22, from 6:00 pm until about 7:30 pm, also at the NREC.  During these sessions, we will review the challenges and rules for this year’s competition.  We will have a competition board set up and will answer any questions you may have.

If you are planning on attending any of the sessions, please register with Norm Kerman, Education Coordinator at the Robotics Academy at nkerman@rec.ri.cmu.edu.  If you have any questions, he may be reached by phone at 412/681-8673.

Click here to visit the FIRE Project website

PITTSBURGH—A new four-year, $7 million educational initiative by Carnegie Mellon University will leverage students’ innate interest in robots and other forms of “hard fun” to increase U.S. enrollments in computer science and steer more young people into scientific and technological careers.

The initiative, called Fostering Innovation through Robotics Exploration (FIRE), is sponsored by the Defense Advanced Research Projects Agency (DARPA) and designed to reverse a significant national decline in the number of college students majoring in computer science, science, technology, engineering and mathematics (CS-STEM).

FIRE will develop new tools that enable middle and high school students to expand upon their interest in robots, leading them from one CS-STEM activity to the next. Examples are programming tools that create game-like virtual worlds where robot programs can be tested, as well as computerized tutors that teach mathematics and computer science in the context of robotics.

The initiative will target robotic competitions such as FIRST, VEX and Robofest that already are popular among secondary school students, but also will create new competitions for autonomous, multi-robot teams and for computer animations that will attract a broader array of students and offer new challenges.

“The idea is that these programs must be rigorous, but fun — what we call ‘hard fun,’” said Robin Shoop, director of FIRE and of Carnegie Mellon’s Robotics Academy, an international leader in the development of K-12 robotic education curriculum. “Robots provide a great teaching tool. Kids like robots and are innately curious about how they work and how they make decisions. Finding answers to their questions is fun, but technically challenging, and that makes robotics uniquely suited to teaching students computer science, engineering and mathematics.”

For more information and to register to receive updates for this project visit www.fire.cs.cmu.edu.

The number of U.S. college graduates with CS-STEM degrees is declining, raising concerns about national competitiveness. The trend is particularly pronounced in computer science, where the number of graduates dropped 43 percent from 2004 to 2007 and where women and minorities remain underrepresented.

“We have a significant decline in the number of students signing up for computer science, science, technology, engineering, and mathematics majors at the college level,” said Melanie Dumas, DARPA’s program manager for its CS-STEM Education Program. “The CS-STEM Education Program will help fill the talent pipeline and enable our nation to compete on the international stage.”

Since 2000, the Robotics Academy, part of Carnegie Mellon’s Robotics Institute, has developed techniques and tools to help K-12 teachers use robots to teach science and mathematics and has trained thousands of teachers on how to incorporate robotics into their lessons. The academy will play a central role in FIRE, but the project also will draw on expertise from across Carnegie Mellon’s renowned School of Computer Science.

Ken Koedinger, Albert Corbett and their colleagues in the Human-Computer Interaction Institute (HCII), for instance, will develop automated tutoring systems for teaching Robotics Academy courses. “Cognitive tutors” developed at Carnegie Mellon already are used by hundreds of thousands of students each year to learn algebra and other traditional subjects. The computerized tutors present lessons and problem sets, provide step-by-step guidance with complex problem-solving and adjust the lessons to each student’s comprehension level.         FIRE’s cognitive tutors will assist teachers and mentors who coach in robot competitions but may lack the mathematics and programming background necessary to help students tackle increasingly harder challenges.

Likewise, Wanda Dann and her colleagues in HCII’s Alice Project will work with FIRE to create an Alice Animation Competition designed to increase the number of girls engaged in computer science.  Alice (www.alice.org) is a software environment that enables novices to create 3-D computer animations and, in the process, teaches basic programming principles. Animation contests that use Alice or other types of animation software can appeal to students of both sexes who might not be interested in robots.

The Alice team will collaborate with the Robotics Academy to add virtual worlds to ROBOTC, a programming language developed by the academy that works with many of the educational robotic platforms used in robot competitions. “This new ROBOTC capability will allow students to design and test robots in a virtual environment when it would be impractical to do so with a physical robot. We plan to add other programming languages as the project evolves,” Shoop said.

Manuela Veloso, professor of computer science and president-elect of the Association for the Advancement of Artificial Intelligence, and Howie Choset, associate professor of robotics, will develop new teaching tools and a new competition for teams of robots working cooperatively. “In the future, robots will work in teams, not as single robots,” Veloso said. “If we want to drive future innovation, then we need to begin to challenge students to solve multi-robot problems today.”

To further expand the potential pool of CS-STEM students, Lori Levin, associate research professor in the Language Technologies Institute, will work with FIRE to increase participation in the North American Computational Linguistics Olympiad (NACLO), www.naclo.cs.cmu.edu/. The International Linguistics Olympiad is very popular in Europe; FIRE’s goal is to make it accessible to thousands of students across the U.S.

In addition to creating new competitions, FIRE will reach out to national organizations such as the Girl and Boy Scouts, 4H, and the Boys and Girls Clubs of America to engage more students in activities that prepare them to be future innovators.

“Tens of thousands of students nationwide participate in robotic activities every year, but these activities do not always translate into increases in academic preparation or sustained engagement with CS-STEM,” Shoop said. “FIRE will provide the infrastructure, the tools, and the resources to significantly engage students for the long term.”

Christopher Schunn and his colleagues at the University of Pittsburgh’s Learning Research and Development Center will provide a key component for the project, evaluating the educational effectiveness of FIRE’s tools and methods and monitor outreach efforts to communities across the country.

###

About Carnegie Mellon: Carnegie Mellon (www.cmu.edu) is a private, internationally ranked research university with programs in areas ranging from science, technology and business, to public policy, the humanities and the fine arts. More than 11,000 students in the university’s seven schools and colleges benefit from a small student-to-faculty ratio and an education characterized by its focus on creating and implementing solutions for real problems, interdisciplinary collaboration and innovation. A global university, Carnegie Mellon’s main campus in the United States is in Pittsburgh, Pa. It has campuses in California’s Silicon Valley and Qatar, and programs in Asia, Australia, Europe and Mexico. The university is in the midst of a $1 billion fundraising campaign, titled “Inspire Innovation: The Campaign for Carnegie Mellon University,” which aims to build its endowment, support faculty, students and innovative research, and enhance the physical campus with equipment and facility improvements.

[All credit goes to jxh of eGFI. Source: http://students.egfi-k12.org/robot-soaks-up-the-sun-and-saves-lives-too/]

If you’re swimming in the surf this summer, don’t expect to see a lifeguard from Baywatch racing to save you from a riptide.

Instead, your rescuer may be EMILY: the 4 foot long robot lifeguard.

EMILY (EMergency Integrated Lifesaving lanYard) is a buoy that uses a sonar device to scan for underwater movements associated with swimmers in distress.

To reach drowning victims, the robot has an electric high-speed propeller that allows it to swim up to 28 mph, six times faster than a human lifeguard, and can overcome even the roughest water.

Not only that, but EMILY is outfitted with a camera and speakers so that the onshore lifeguard can calm the distraught swimmer and instruct him or her to hold onto the robotic buoy or wait for human help.  The robot can travel up to 80 miles on a single battery charge.

EMILY is currently patrolling Malibu’s dangerous Zuma Beach and by December will be guarding about 25 more.  The current version is operated by remote control, but the next model will be completely autonomous and save drowning victims without the aid of onshore lifeguards.

An increase in beach safety is certainly necessary: over 77,000 people were rescued by lifeguards at U.S. beaches in 2009.

Important update!

We have just released another update to ROBOTC for Cortex & PIC. This release is required to use Cortex motors 1 or 10. In earlier versions,  you may encounter a firmware bug that can cause the motor control circuits to overheat and burn out.

Click here to go to the download page – ROBOTC for Cortex & PIC

Enhancements in this release include:

1. Support for direct wired USB cable between PC and  VEX Cortex for downloading user programs and debugging added.
2. Support for Debugger “Debug Stream” window added. User programs can easily write (“print”) to a text window on the PC.
3. Faster firmware downloading. It now takes just 10 to 15 seconds. User programs download in just one or two seconds.
4. Fix control of H-bridges for motors 1 and 10 to prevent “shoot through” and the potential for internal short circuits.
5. A few minor bugs fixed in the compiler.

Greetings Educators!

The Robotics Academy has set some Online Teacher Training Dates for the Fall. The classes include the NXT-G Professional Development, ROBOTC for LEGO/TETRIX, and our brand new class: The ROBOTC for Cortex online class.

Here are the schedules for the Fall Online Teacher Training:

1. NXT-G Professional Development
   • Begins October 7th, 2010 – Every Thursday for 6 weeks
   • Click here for more details about NXT-G Professional Development
2. ROBOTC for LEGO/TETRIX
   • Begins October 6th, 2010 – Every Wednesday for 6 weeks
   • Click here for more details about ROBOTC for LEGO/TETRIX
3. ROBOTC for Cortex – NEW!
   • Begins October 5th, 2010 – Every Tuesday for 6 weeks
   • Click here for more details about ROBOTC for Cortex

Click here to take a look at all of the classes we have to offer!

[Source:  http://news.cnet.com/8301-17938_105-20007692-1.html]

I hate playing chess. I don’t hate the game; in fact it’s pure strategy, something I love. But despite years of practice, I still almost never win. And now, it would seem, I have further cause to be pessimistic about my chances of a victory, as even robots made out of Legos are here to beat me.

Observe the video below. That’s a huge, 156-square-foot chess board and pieces made entirely out of Lego Mindstorm parts–more than 100,000 of them. It’s called Monster Chess, and it’s awesome.

The battery-operated, Bluetooth-controlled pieces use downward-facing sensors to read grids built into the individual squares on the board. They then communicate with the controlling computer to keep track of their location in relation to other pieces. The computer tells each piece which direction to go, and how far, on its turn.

And the knights are animated. Watch the video and tell me that’s not cool.

It took a year for four people on Team Hassenplug, led by Steve Hassenplug, to put Monster Chess together at a cost of around $30,000. It can be played as human vs. computer, computer vs. computer, or human vs. human via the controlling computer. It uses international standardized rules from an enhanced version of the ChessBot software package. And no, sadly, you can’t buy one.

Also sadly, the pieces are a bit pokey, so watching a full match isn’t the most thrilling thing in the world, but still, this proves something I’ve held true for a while: Legos are for grown-ups as much as they are for kids.

embedded by Embedded Video

YouTube Direct 

embedded by Embedded Video

YouTube Direct