Advice and information for ARBC-sponsored teams

Robot Programming

Robot Mission Custom Coding Sheet

Planning individual robot missions involves developing a concept for the mission, creating a path diagram for the robot’s motion, and writing pseudo-code for the programming statements before actually coding the mission.  A custom coding sheet in the Robot Game Rulebook captures these planning elements.   Make copies of it for your student team members to use to document their development process, and bring the completed planning sheets to the competition to show the judges.

SPIKE Prime app (LEGO Education application)

• LEGO Education SPIKE App download page
• LEGO Education SPIKE App web browser link

Programming Hints

Good to know/remember

• The LEGO brick doesn’t know which motors/sensors for a particular  use are plugged into which ports, so it is important that:
  • Programmers and hardware technicians (builders) communicate with each other the physical interfaces (which ports for which motors/sensors) and the logical interfaces (which ports are programmatically identified for which motors/sensors)
  • Student team members document what motors/sensors are in which ports and use this configuration consistently for all missions they are taking to competition.  If the brick needs to be swapped out or some motors/sensors are accidentally unplugged, having this documentation could be the difference between a quick “fix” and a tearful failure during the robot game.
• The tournament game tables are generally set up according to the Robot Game Rulebook, but are likely to vary somewhat from however a team’s regular practice field is set up
  • The mat may be in a slightly different position within the walls
  • The mission models may be in slightly different positions on the mat
  • Robot programming that allows for minor variances is generally more successful in competition than rigid code carefully tuned to just one field
  • Attending a scrimmage or other practice venue where a robot can be tested on “foreign” fields is a great way to see where weaknesses exist in robot programming
• “Movement” blocks control two motors simultaneously for directional movement of a robot with two driving motors
  • The brick has built-in control logic so that both motors rotate at the same speed when going forwards or backwards
  • The “steering” input value causes the control logic to run the motor for the inside wheel of a turn more slowly (or even in reverse) so that the robot makes a steady turn while moving forwards or backwards
  • Steering inputs reduce the inside wheel speed by some percentage for each unit of input until a crossover point when the inside wheel will be stationary while the outside wheel turns the robot using the inside wheel as the pivot point.  Some call this a “pivot turn” and consider it to be a more accurate/repeatable approach to turning.
  • Steering inputs in excess of the crossover point cause the inside wheel to move in the direction opposite the outside wheel at increasing rates   A maximum steering input causes the robot to rotate around the midpoint of the axis between the two drive wheels.  Some people call this a “spin turn”, and it is perhaps second in accuracy to only the “pivot turn.”
  • Some bricks (EV3 vintage?) have been observed to behave inconsistently at steering inputs close to the crossover point.  The inside wheel may move more than it should during the turn, but jump back to the position it should have just reached by the end of the turn.  If making Movement block “pivot turns” isn’t working on your team’s robot, an alternative “MyBlock” can be defined to use Motor block statements that hold the inside (pivot) wheel in place while commanding the outside wheel to move by itself to make the robot pivot.  Don’t jump to a “MyBlock” solution until/unless the student team members test and prove to themselves that it is more accurate.

Avoiding assumptions

Good programs don’t assume their environment when they don’t have to.  Here are anti-assumption suggestions:

• Every code block should start by initializing variables, zeroing out counters, defining movement motors, and establishing other program elements that might vary between different code blocks.
  • Zero out the “degrees counted” on motors at the start of routines that depend on odometer to measure distances
  • Explicitly define the “movement motors” when using Movement (dual-motor control) blocks
  • Set a default movement speed; override it only when necessary
  • Understand and deliberately control whether motors “hold position” or coast when stopped; holding position uses power but is more precise when multiple move segments are chained together

Generally good practices:

• Programmers should write their programs out in pseudocode (simple English language statements about what the robot should do) before selecting the explicit code statements that are the actual program
  • Pseudocode can often better capture what the programmer intends to do before they translate their intentions into program code that will only do what it is capable of doing
• Use speed controls rather than power level controls in almost all cases; power levels lead to variable performance as battery state of charge changes
• Use reasonable speeds; too fast leads to wheel slippage or precision driving problems, too slow may make a mission take too long
• Use distance-based movement measurements (rotations or degrees) rather than time-based movement measurements (seconds) in virtually all cases; timing-based movement distance varies according to factors including motor speed, battery charge level, and friction conditions
• Odometry (measuring wheel movement) is simple to implement and can lead to adequate results in less complex situations, but sensor-based movement control adapts better to minor variations in field conditions
• Use “wait” blocks judiciously to allow the physical world where mass&momentum exist to catch up with the computational world  where statements jump from one to the next in less than a microsecond (1/1,000,000 sec.)

EV3 Classroom (LEGO Education application)

LEGO Education has all-but- retired the older LABview-based EV3 programming tool (now renamed to EV3 Lab).  The newer multi-platform EV3 programming tool is called EV3 Classroom and is available for Windows, Mac, Chromebook, Android, and iPad.  The app has a built-in “Start” section that includes instructions on building a “Driving Base” (basic robot chassis), introductory programming (Getting Started), Unit Plans for building knowledge and skills, and building plans for a variety of robotic models:

• LEGO Education EV3 Classroom app download page

Use EV3 Classroom unless you are knowledgeable and skilled enough to know about and use other applications like the now-deprecated EV3 Lab, LEGO Educations EV3 MicroPython programming, or Microsoft’s MakeCode. 

FIRST‘s EV3 Classroom Alternative Robot Lessons (for EV3 instead of Spike)

FIRST’s guidance for learning robot programming has shifted to the relatively new Spike platform and away from the venerable and still-capable EV3.  At the same time, LEGO Education has shifted from the original EV3 Labview software (only provided for Windows and Mac) to the new EV3 Classroom app.  Unfortunately, the older-but-still-available FIRST tutorials that used the EV3 Labview tool aren’t directly consistent with LEGO Education’s newer EV3 Classroom app.  Fortunately, an Alternative Robot Lesson series was developed for a previous season and can still be used as an entry-level tutorial:

• FLL Challenge Alternative Robot Lessons (one-page overview)
• LEGO Education Robot Trainer Unit Plans (referenced in the FLL Challenge Alternative Robot Lessons)
  • These are the same lessons that are built into the EV3 Classroom app Unit Plans -> Robot Trainer
  • Lessons include Moves and Turns, Objects and Obstacles, Grab and Release, Colors and Lines, Angles and Patterns, The Factory Robot, and The Guided Mission 2021-22 (not the current season)
  • Students that understand/master the robot behaviors in these lessons are well-positioned to take on the FLL Challenge Robot Game missions
  • Coaches and team members can use this web-based view of the lesson plans to review the lessons

EV3 Lessons (3rd-party educational materials)

Robot programming is about controlling motors (moving the robot and robot manipulators), reading sensors, and performing calculations.  Teams interested in building EV3 robot programming skills through guided sessions can benefit from the resources at this URL:

• Droid Robotics EV3 Lessons