Archive for the ‘Computer Science’ tag
We had the chance to interview the lead programmer for FTC Team 5037, Kristen McKellar. She is an impressive programmer with a bright future ahead. Check out her story on how her knowledge of ROBOTC helped her win the National 4-H Engineering Challenge …
Are you a ROBOTC student who wants to share your story with us? If so, send us an email at email@example.com!
We are happy to announce a new course on CS2N, Create Your Own Level with RVW Level Builder. In this new course, you will go through the steps of making your own custom level inRobot Virtual Worlds‘ Level Builder!
The class is structured on a 5-phase version of the engineering process (Concept, Design, Production, Testing, Release). In each phase, you will take a further step towards completing your level, either through planning, creating, or testing your level.
Level Builder enables users to easily create levels and challenges for others to solve. Teachers can create custom challenges for their classrooms or generate unique challenges for each student. Multiple real and fantasy themed robots and objects are available for use. You can also import your own objects with the 3D Model Importer. Your level plays like any other virtual world. You can access all of the motors and sensors on the virtual robot to solve the challenge using ROBOTC code.
Sign up for CS2N and this FREE course today - Create Your Own Level with RVW Level Builder. And don’t forget we have a Level Builder competition going on until August 31, 2013, Beacons and Barriers, with a chance to win some great prizes!!
We are happy to announce that the leaderboards for the Robotics Summer of Learning competitions are live! Each leaderboard shows the overall scores as well as the leaders in each division. The results are real-time, so check back often to see where you stand. The competitions run until August 31, 2013.
VEX Toss Up
- Middle School Division - 6th to 8th Grade (for the 2013-2014 School Year)
- High School Division - 9th to 12th Grade (for the 2013-2014 School Year)
- Open Division - Teachers, Mentors, Coaches, Educators, Hobbyists, Everyone!
The official rules are listed on the official Robotics Summer of Learning page.
We’ve featured a couple of robotics students the last few weeks, but this week we showcase a robotics teacher who uses ROBOTC and Robot Virtual Worlds in the classroom. Check out Jeff Maxwell’s interview on why and how he uses Robot Virtual Worlds with his students …
We designed the RVW Model Importer so students and teachers can expand upon the learning already going on in their classrooms. We released the first version with support for importing Stereolithography format (.STL) files because these allowed models to be made using the engineering industry-standard Autodesk Inventor and Solidworks solid modeling software packages already used in many classrooms. Unfortunately, there's no such thing as a universally-supported format for 3D models, so, while we hope to release support for more formats in the future, we knew we were excluding some powerful and easy to use tools.
One of these was SketchUp, an easy-to-learn 3D modeling program originally created by Google and now developed by Trimble. (We like it enough that we even made a set of introductory tutorials.) Thus, we were happy to discover there's now a plugin for SketchUp that allows models to be exported as STL files. Here's a set of instructions to get you started. These were developed using SketchUp 8, but should work as well using newer versions.
1. Make sure you are logged in on your computer as a user account with Administrator privileges.
2. If you don't already have it installed, download and install SketchUp. You can get started learning how to model either using our tutorials on CS2N or the Getting Started guide developed by Trimble.
3. Download the plugin file from https://github.com/SketchUp/sketchup-stl/raw/master/sketchup-stl-1.0.0.rbz.
4. Open SketchUp, then open the Window menu and choose Preferences, then select the Extensions page.
5. Click the Install Extension button and select the plugin file you downloaded in step 2.
6. A popup window will appear asking you to confirm that you want to install the extension. Click Yes.
7. If you are using Windows Vista or Windows 7, you may need to allow SketchUp to make changes to your system when prompted.
8. Click OK in the popup telling you the plugin has been installed. Confirm that the checkbox next to the STL Import/Export plugin is checked, then click OK to close the preferences window.
If you're looking for models to experiment, look no further than SketchUp's 3D Warehouse: open the File menu, then 3D Warehouse, and select Get Models. To export a model as an STL file in SketchUp:
1. Activate the Select tool by clicking the pointer icon on the toolbar or by opening the Tools menu and clicking Select.
2. Click on the model in the scene you want to export. A blue box will appear around it.
3. Open the File menu and choose Export STL.
4. Name the exported file and click Save.
5. A popup will appear telling you how many faces and lines have been exported. This lets you know that the export process has finished.
You now have an STL file you can use with the RVW Model Importer. Check out the Model Importer overview video for directions:
At this time, there is a limit to the complexity of models that RVW can use. If when importing you get a message that says "Mesh could not be reduced enough to be compatible with RVW," you'll have to make a simpler version.
- Ryan Cahoon
I’d like to welcome a new section to our blog called Teacher’s POV (Point of View) that will allow guest bloggers who are teachers, mentors, and coaches to share some of the lessons they have learned while teaching robotics. Our first guest blogger is a good friend to the ROBOTC family, Jason McKenna, a K-8 Gifted Support Teacher in the Hopewell Area School District outside of Pittsburgh, PA. He has been kind enough to put together some blogs about his experiences teaching robotics.
As teachers, we are constantly looking for ways to make the subjects that we are teaching relevant. Students are always asking when they will ever use a particular concept, or how what they are learning applies to a real life scenario. Admittedly, teachers sometimes have a hard time answering those questions.
Thankfully, teaching Robotics and computer programming puts those questions to rest. Because technology is so ubiquitous in students’ lives, students will immediately see the benefits of learning how to program. Moreover, Robotics is the perfect platform to show the application of math and science concepts to everyday scenarios.
In addition to all of that stuff that we educators like to talk about, students just have fun programming a robot to do something. Add in the allure of some competition, and you have yourself a pretty engaged classroom.
With that in mind, I decided to have my 8th grade students participate in a line following car race. Students were to program their robots to follow a line as fast as possible. Of course, the trick is the robot has to stay on the line. While following a black line, the robot has to decide (using a light sensor) if it is on the black line or on the white part of the mat. For the competition, the students added some PID concepts to their line following. As many of you already know, PID is used in many control systems, from your car, to your homes, to large scale factories. The students and I discussed how PID is basically a control system that tries to calculate an error and make adjustments to a control system based upon that error. The robot calculates an error (how far it is off the black line) and then makes adjustments to the motor speed based upon the error. That is what makes it proportional: the movement is based upon the error. Large error equals a large correction whereas a smaller error creates a smaller correction.
The students were able to apply some of the concepts they are currently learning in Algebra to their program. For example, they are utilizing the slope intercept formula (y=mx+b) to find their turn. Y is the turn distance, x is the light sensor reading (the error), and m is the change in y (maximum and minimum turning power) divided by the change in x (maximum and minimum light sensor reading). Students get to apply an important math concept to a fun and engaging scenario that has real-world applications.
The students then decided that they wanted to see what would happen with two light sensors. The students adjusted their code, conducted some iterative testing, and surveyed their results.
In conclusion, one really sees how Robotics and ROBOTC meld perfectly with the goals of a STEM classroom. Really, the only limitation is a teacher’s (and students’) imagination.
- Jason McKenna
Thank you Jason! If you are a teacher who would like to share your experiences on our blog, send us an email to firstname.lastname@example.org.
In preparation for the 2013 Robotics Summer of Learning, we’ve released updates for the Palm Island (v2.1.0), Operation Reset (v3.1.0),Curriculum Companion (v2.4.0), and Level Builder (v2.0.11) Virtual Worlds!
In Palm Island, Operation Reset, and the Curriculum Companion, we’ve added two highly-requested features: Graphics Quality Control andUpdate Notifications.
Graphics Quality Control
In the Options section of each virtual world, we’ve added a new Graphics Quality setting. Choosing LOW (FASTER) will reduce the visual quality of the virtual environment, but will allow the virtual worlds to run more smoothly on older computers. MEDIUM is the default setting and is a balanced choice between quality and speed on most computers. Choosing HIGH (SLOWER) will improve the visual quality and is the most resource intensive; it is only recommended if you have a newer computer with a dedicated graphics card.
If your computer is connected to the Internet and you log in using your CS2N account in the virtual world, it will now check if there is a newer version of the virtual world available. If an update is available, a notification about the new version appears with a DOWNLOAD NOW button. Simply press it to download the latest version available!
RVW Level Builder
We also updated the RVW Level Builder! We have improved the performance of the menus and fixed an issue where line tracking tiles were getting “stuck” once they were placed. Thank you to everyone who has sent in feedback! We’ve also released a series of videos to help get started with the Level Builder:
The updates can be downloaded from the RVW Level Packs Download area at ROBOTC.net or RobotVirtualWorlds.com.
We understand the challenges robotics classrooms face every day in terms of cost, number of robots, batteries, and homework. That is why we created Robot Virtual Worlds (RVW). With RVW, every student can experience the same benefits of learning robots, right on their computer. RVW currently simulates popular real-world VEX, LEGO, and TETRIX robots in a 3D environment; while using the same language, ROBOTC, to program both your virtual robot and your physical robot.
To help you get started and get a better understanding of what RVW can do, we are offering five FREE webinars through Google Hangout with project manager, Jesse Flot, and some members of his team! We will show you a brief tutorial on the specific topic of the day then take a few questions from the Google Hangout chat or on twitter using hashtag #RVWHangout.
Listed below are the specific dates and topics we will be covering …
Free Robot Virtual Worlds Webinars on Google Hangouts
- What is Robot Virtual Worlds?
- Overview of RVW.
- Why RVW?
- Step-by-step tutorial on getting started.
- Additional RVW Resources.
- Using the RVW Curriculum Companion.
- Free ROBOTC Curriculum, including programming challenges.
- Programming challenges, along with the curriculum robots.
- Solve one of the challenges.
- Benefits of using RVW in addition to or in place of real robots.
- Badges with RVW and on CS2N.
- Using the RVW Level Builder with Model Importer
- What is Level Builder and why we made it?
- Sample level.
- Program levels using ROBOTC.
- Share levels with another person.
- Import an object using the Model Importer and include it in the newly created level.
- Gaming Environments with the Robot Virtual Worlds
- Palm Island and Operation Reset.
- Benefits of using the game environments.
- Measurement Toolkit to find distances the robot needs to move.
- Badges with RVW and on CS2N.
- Competition Environments with the Robot Virtual Worlds
- Why do so many teams wait until the last minute to program their robots?
- Autonomous and remote control scoring in the environment.
- Multiplayer features in development.
- CS2N Programming Competition development.
We are very excited to announce that today is the first day of Spring and …. the first day of ROBOTC 3.60! ROBOTC is the premiere robotics programming language for educational robotics and competitions. ROBOTC is a C-Based Programming Language with an Easy-to-Use Development Environment. We are really proud of this release and can’t wait to hear what you think! Remember, we could not do this without your support and feedback. We hope you’ll continue to share your comments with us, either in the forums or on our Facebook or Twitter page.
Some of the key enhancements are:
- Added support for proxy server when activating ROBOTC (Proxy Support guide can be found here).
- Add watchdog timer support to VEX Cortex to alleviate processor crashes that can occur with static (more information on this issue can be found on the VEX IME Product Page).
- Fixed a bug in the NXT color sensor that now allows you to read individual RGB values.
- Updated with the latest version of the 3rd party sensor drivers for NXT. (Thanks Xander!)
- Updated Curriculum Tables included for Robot Virtual Worlds.
See below for the more detailed changelog and download ROBOTC 3.60 here!
To celebrate the official release, we will be having our first Google Hangout! Tim Friez, John Watson, and Xander Soldaat will be there to discuss the new features and answer some of your questions. To tune in live, visit ROBOTC.net/hangouts at 2pm EST tomorrow (Thursday, March 21.)
3.59 to 3.60 BETA Changelog
- New Standard Models Added for PLTW.
- Update VEX Cortex I2C interrupt handler to handle case where interrupt for last received character is not processed until STOP signal has already been sent.
- Add parameter to I2C Device Driver (VEX Cortex) to indicate whether being called for a “timer tick” or for a “message is now complete”. Add a few more statistics to the error collection.
- Increase VEX Cortex I2C message timeout to 6 milliseconds from 3.
- Start sending VEX Cortex I2C polling messages immediately after last poll has finished. Improves I2C responsiveness for VEX Cortex.
- Xander’s 3rd Party Driver Suite updated to version 3.3.1
- New firmware conditional compiles to eliminate the get/set property opcodes for ‘long’ and ‘float’.
- Arduino only. “Copy opcode from flash to RAM” performance improved.
- On Arduino, sensor initialization incorrectly assumed as sensor types had the extra “sensor buffer” structure. But the extra buffer is only linked for complicated sensor types so RAM was being overwritten. Fixed.
- Updated application and desktop icon quality.
- Fix “Multiple overloads match” error introduced with change that did proper validation of pointer expression with point procedure parameter variable.
- Improved validation of procedure parameter matching for function overloads. Previously when parameter was a pointer, only checked to confirm that calling expression was also a pointer. Check was extended to also (correctly) match on the type of pointer as well.
- Could not change “check array bounds” in Compiler Code
Optimization tab. The issue was that after changing the check mark the “code optimization type” would be recalculated and then the “optimization type” radio buttons updated. Array bounds checking is not used in determining the optimization type; but in setting the type it is modified. So the changed check mark was being accepted and then software was overwriting. Fixed.
- Split “auto save” into two individually settable flags: (1) to auto save source files before compile and (2) auto save files when application exits.
- Incorrect code optimization involving ‘struct’ variable offsets and perhaps other cases. For the assignment instruction “<variable2> is assigned address of <variable1>” compiler was replacing references to “<variable2> with “<variable1>. This optimization should only occur for “simple assignments” of “<variable2> = <variable1>”. Fixed.
- Change ‘nSysTime’ and ‘nPgmTime’ intrinsic variables to “unsigned”. ‘unsigned’ intrinsic variables were being converted to ‘signed’ when used in comparison expressions generating a warning regarding mixed ‘signed’ / ‘unsigned’ comparison. Fixed.
- Upper range check for “array bounds check” opcode used “>” instead of “>=” in comparison allowing ‘one past’ array size as valid.
3.54 to 3.59 BETA Changelog
- Add watchdog timer support to VEX Cortex. This will allow the VEX Cortex User Processor to “restart” automatically once the processor crashes/is halted. Useful for any potential static issue that may cause the User Processor to “crash”.
- Change watchdog implementation from “windowed” watchdog to standard watchdog (no window, reset any time). Increase watchdog timeout to 0.75 seconds.
- In Debugger Motors display the last motor was not always properly updated. Fixed.
- Enable emulator for VEX PIC. Fix subsequent bug with “Motors” debugger display for VEX PIC locking up IDE when emulator is enabled; this bug should be limited to VEX PIC Emulator only.
- VEX PIC downloading was failing when master firmware was out of date. Getting stuck in a repetitive loop that wasn’t exiting. Fixed.
- VEX PIC was not executing user programs. Bug was that “start of flash file system VTOC” needed to be aligned on 4-byte boundary. Previous change had added a 1-byte field to the header preamble and there was not a corresponding 3-byte file added for VEX PIC. ARM platforms worked OK. This may also have broken Arduino (i.e. any 8-bit) platform).
- Added a Conditional Compile flag for tUARTs to avoid confusion between uartOne and UART1
- There are two separate flags for “allow any serial port for communications” — one for VEX Cortex and one for all other platforms. This was not obvious. Preferences “Environment” tab was only updating flag for non-Cortex; this has been changed to update the appropriate flag based on platform setting. The VEX Cortex flag can also be updated in the “VEX Cortex” tab.
- User configurable UART setup was screwed up for the platforms whose “uart 0″ is fixed as non-configurable and usable only for system communications port to PC — i.e. VEX Cortex, VEX PIC. The ROBOTC IDE was storing the data in the persistent data table (at start of flash file system) offset by one entry. I.E. data for “uart 1″ on VEX Cortex was stored in “uart 2″, etc.
- NXT color sensor read RGB individual values broken with pointer implementation. Change “getMemoryParmXXX” function calls to “getCommonParamaterValueXXX” function calls. Check rest of firmware for same mistake.
- New feature for 3rd Party Sensor Driver Suite to set the two digital I/O lines on NXT sensors. Added two new sensor types (sensorCustom, sensorCustom9V) for this along with two new property intrinsic variables to set I/O line direction and values; these intrinsic variables are bit masks (2-bits) for the two lines.
- “setPixel” intrinsic (and corresponding “clearPixel” and “invertPixel”) take “unsigned” parameters. But implementation was using “signed” parameters and not properly range checking if parameters were negative. If negative, then should do nothing. Instead they were incorrectly wring to invalid buffer address which eventually caused a firmware crash.
- Fix issue for “Motors” tab for Arduino in “Motors and Sensors Setup” property sheet. Was incorrectly trying to setup “encoder information for motor”, but Arduino platform does not “associate encoder sensor with motor” — which is currently only a feature for VEX Cortex.
- Added Support for Proxy Server when activating ROBOTC – Users can set Proxy preferences under “Detailed Preferences – General – Environment”.
- Incorrect generation of compiler error message when double pointer (i.e. “**”) is used.
- “Print” a range of pages was not working when the starting page was not ’1′. Fixed.
- Remove incorrect error message from error “Assignment between two different pointer types” when one side of ‘=’ is a ‘void *’.
- Compiler was incorrectly generating error message for “Expected a pointer expression in a pointer expression with ‘++’ or ‘-+’ operand. Compiler was incorrectly checking to verify the right operand was an integer value.
- Compiler was incorrectly generating error message for “Invalid pointer expression” in a pointer expression with ‘+’ or ‘-’ operand. One operand of the expression must be a pointer and the other operand must be an integer (without implied conversion of a pointer to an integer). Compiler was incorrectly checking for the integer — the expression incorrectly had a “!” in it!
- Change code generation of ‘var arg’ for pointers to be consistent with standard C — i.e. the value of the pointer is placed in the argument. This may result in an additional instruction generated when argument is a ‘string’; previously RobotC got too cute trying to save this extra instruction which only worked for “%s” format codes but was broken for “%d” on a pointer.
- In ‘sprintf” implementation for “%s” and “%p” format codes– change from “get Address of parameter” to”get value of parameter” to match corresponding change in compiler code. Also minor cleanup of “%s” and “%p” format codes.
- Assignment expressions of “<char * variable> = <char constant> were generating compiler error because the “<char constant>” was evaluated as a “string” type. Added code in “get expression type” to check for this and not generate error as the compiler auto converts “string” to “char *” during code generation.
- Fixes an issue with the Live Start Page and “check for updates” that may have caused crashes.
- Improved validation of pointer expressions. Fix bug in calculating expression type of pointer expressions like “<ptr sub-expression> + <numeric constant>”; the result was (always?) incorrectly set as “long *”? Also added check that “=” of pointer is from a pointer of the same type – otherwise generate error message.
- Fixed consistency in implementation of “random” intrinsic property.
- Eliminate compiler error message in constant expression evaluation of sub-expressions using “*” operator. If either of the two operands is ‘zero’ then result is zero regardless of whether the other operand is a compile time constant.
- Do not generate additional errors — “too many parameters” specified — when procedure is “compiler generated undefined symbol”.
- When switch between “real robots” and “emulator”, the function that calculates “size of RAM pointer variable” was not being called. It adjusts between 2-byte (VEX PIC, Arduino) and 4-byte (Emulator, VEX Cortex, NXT) pointer sizes. No issue with VEX Cortex and NXT as they only use 4-byte pointers. But a problem with VEX PIC and Arduino where real robots use 2-byte RAM pointers! Added the appropriate call to function setup.
- Small code optimization for “postfix –”/postfix ++” operators to avoid temporary. In some cases they can be simplified to prefix operands.
- Incorrect initialization of static variables in “inner scope” for local procedure. They were initialized every time inner scope block was accessed rather than once on program startup.
- Debugger Panes for “Locals” and “Globals” (especially Globals) was not properly handling updates to ‘long’ and ‘float’ variables. Globals was completely broke — only lower two bytes of 4-byte variables was being updated which broke ‘long’ and ‘float’ variables. In both, ‘char’ variables were updating a short value — i.e. overwriting following characters.
- Fix problem with incorrect user code using a “short” variable and “sprintf” format code of “%f”. This can crash ROBOTC VM firmware if the short variable is not aligned on a 32-bit boundary.
- Add additional entries for StringFind for Character Constants and added test program.
- Redefine datalog opcodes and intrinsics. Legacy datalog incompatible with 3.5x VM operands which split memory variables and intrinsic properties into separate items.
- Firmware for all platforms now call “datalogHandlerInit()”. Conditional compile will define as NULL macro if a platform does not support Datalog. Datalog support is now conditionally compiled via “bHasDatalog” define rather than hard-coded as NXT only.
- Fix incorrect compiler type checking error when string constant is assigned to a char pointer.
- Fix bug in check for “is this a preprocessor string comparison expression”.
- Eliminate preprocessor string comparisons in Natural Language and replace with “defined(_Target_XXX_) where “_Target_XXX_” are three new system defined preprocessor variables — “_target_Robot_”, “_Target_Emulator_” and “Target_VirtWorld_”. Sample programs modified appropriately. Legacy user programs using legacy definitions will still work but will generate a compiler warning about non-standard extension.
- Add registry flag to enable compiler extension to allow preprocessor expressions support for string comparisons. Generate compiler error message if encountered without the flag being set.
- “cast” code generation fix. Previously when cast changed sign of result the ‘cast’ was applied before expression was converted to ‘int’ size used during a calculation. So casting a “ubyte” to “int” incorrectly converted it to a “signed char”. What should happen is “ubyte” expression gets evaluated into an “int” as part of expression evaluation (all expressions are evaluated at ‘int’ (or higher) level in “C”) and then the cast to “int” has no additional effect.
- Function to extract numeric “COMxxx”. Expanded syntax to support successful parsing of “(COM99)” previously would not accept extraneous characters.
- Add improved Dialog for selecting Communications Port. It uses a list box to display information about the port. Add check box to select any communications port.
- Compiler crash when parsing invalid syntax of ‘?’ expression. Compiler was not handling the case when “NULL” pointer returned from parsing sub-expression. The “NULL” was incorrect.
We are proud to announce that Landon Woollard from Shasta High School in Redding, CA is the first student to finish the CS2N ROBOTC student certification!
Mr. Brian Grigsby teaches the 2-hour per day, 5 days per week Career Technical Education Space, Science, and Engineering class at Shasta High School. Mr. Grigsby states, “[In this class,] we combine engineering principles with the VEX system with science exploration through NASA data programs (like the Mars Exploration Student Data Teams and the Student Planetary Investigator program) to emphasize how STEM related disciplines work together in our world.” As part of the curriculum he has incorporated CS2N.org and the ROBOTC certification, along with the physical part of building and programming. Students taking the class get lab science and elective credit for the University of California A-G requirements. The class also satisfies their computer proficiency for graduation.
Mr. Grigsby and Landon were nice enough to answer some questions for us…
What ways has the ROBOTC certification program and CS2N helped you reach your teaching goals?
Mr. Grigsby: It has allowed me to have another measure of student understanding and assessment to my course. By including ROBOTC certification, I am able to know how much the students truly understand about programming and where they need extra help.
Can you explain how students have responded to CS2N and the curriculum?
Mr. Grigsby: The students had been trained in the area of building and testing physical robots, so adding CS2N into the mix gives students another outlet to experience programming. They can also design programs and test them on the virtual robots before they test it on their physical robot. If there are any problems with motors, encoders, or other parts to the robot that are causing problems with their programming, they can go to CS2N and the Robot Virtual Worlds to make sure their programming is solid. Then they can troubleshoot their physical robot, and learn how to better engineer what they have built.
What is your favorite part of ROBOTC?
Landon: My favorite part of the ROBOTC course was the creativity required. The creative freedom allowing the accomplishment of various tasks is something that isn’t found in very many classrooms today, and really made it fun and challenging.
What did you find to be the most challenging part of learning ROBOTC?
Landon: What I found to be the most difficult part in learning this language was my previous coding knowledge in Java. I frequently found myself trying to implement many Java keywords into my ROBOTC code and trying to use methods from the
Java API, which the compiler didn’t like.
What does it mean to have a ROBOTC Certification?
Landon: To me, the ROBOTC Certification means better opportunities. As a student who wishes to study computer science and software design in college, this class and certification course was an excellent opportunity to further expose myself to the coding aspects of computers. Also, having a physical documentation to show to college admissions will set me apart from every other student, hopefully increasing my chances of acceptance.
Landon’s classmate, Marisa Kuntz, was the first female to finish the certification a few weeks later. We want to congratulate Landon and Marisa, as well as Mr. Grigsby!
To find out more about the ROBOTC student certification, visit:
Note: This is one of the first schools to work through our ROBOTC certification. We are slowly rolling this out to all teachers and students, through CS2N, in the very near future. Check back for more details in the next few months!