Advice and information for ARBC-sponsored teams

Robot Programming

Robot Mission Custom Coding Sheet

Planning robot missions involves a concept for the mission, a path diagram for the robot’s motion, and pseudo-code for the programming statements.  This custom coding sheet captures these planning elements:

• Custom Mission Coding Sheet – Coming 8/6

SPIKE Prime app (LEGO Education application)

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

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 

Programming Hints

Good to know/remember

• The LEGO EV3 brick doesn’t know which motors are plugged into which motor ports (the lettered ports) or which sensors are plugged into which sensor ports (the numbered 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)
• The tournament game tables are generally set up according to the Robot Game Rulebook, but are very 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
• EV3 “Movement” blocks control the two large motors simultaneously for directional movement of a robot with two driving motors
  • The EV3 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 from 1 to 50 reduce the inside wheel speed by 2% for each unit of input (20% for 10, 40% for 20) with an input of 50 reducing the inside wheel speed by 100% (i.e., the inside wheel should be stationary while the outside wheel turns the robot using the inside wheel as the pivot point.)
  • Steering inputs from 51 to 100 turn the inside wheel in the direction opposite the outside wheel at increasing rates of 2% for each unit of input (-20% for 10, -40% for 20, etc.) with an input of 100 causing the inside wheel to rotate opposite the outside wheel at 100% of its speed.  A steering input of 100 causes the robot to rotate around the midpoint of the axis between the two drive wheels.
  • Some EV3 bricks have been observed to behave inconsistently at steering inputs close to 50.  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” (steering input 50) 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.

Avoiding assumptions

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

• 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 timing-based movement measurements (seconds) in most 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.)