Programming our Navigation Bot

We built it, now we need to make it go, right?

The driver's station, a laptop with Blocks, and the navigation robot.
The navbot, and how we programmed it.

Our Navigation platform (how about “navbot” for now, at least until we name it properly – eh, Team?) consists of the goBilda mecanum “strafer chassis” with two REV distance sensors. We will add another two distance sensors before we are done, and a USB camera on a swivel mount, but that’s an upcoming project yet.

So we have a chassis and a couple of sensors to work with. No big deal! We pull up Blocks for this, and get it moving… why isn’t it moving?

So despite the fact that we are programming in blocks, guess what? We actually still need to know what we are doing. The motors still need to be properly initialized before they will run. Turns out that blocks can actually teach you real programming- who knew? We set the motors’ run mode and direction, making an initialization routine.

You have to tell the motors what to do before they will do anything!

We put the chassis up on a book before trying to actually run it on a surface. Lifting the wheels off the ground allows them to run without spinning the navbot in circles – because the way the chassis is hooked up, the right-hand motors spin backwards from the left-hand motors. With that fixed in our code, we made a routine to run forwards, a routine to run backwards, and a routine to stop. Something like this (only in blocks, which are prettier):

private void run_forward() {

There are two ways in which we could have fixed the wheel direction. One way was to set the direction on the left hand motors to REVERSE; the other way is to set the power to negative values. We chose the latter method.

The next step was to involve the distance sensors. We decided to have it run until it came close to an object, then stop. So, in pseudocode:

until (sensor.distance <= 30cm)

We had fun almost running into the dog (and he got very nervous) a few times, then added in the other direction. Since the front sensor is in the middle of the robot and the rear sensor is at the rear edge, the distance was adjusted to suit:

until (sensor.distance <= 10cm)

You’ll notice that we actually wait to make sure that we’re not already less than 10cm from something before we run backwards. We do the same check before running forwards. So the full loop is:

wait until front.distance > 30cm;
wait until front.distance <= 30cm;
wait until back.distance > 10cm;
wait until back.distance <= 10cm;

So it’s not very smart yet, but now it goes back and forth like a pendulum-on-wheels.

Just don’t run into the dog…!

Up next: the camera! Stay tuned.

Congratulations to our Graduates!

It’s been a great year, and we’ve been truly lucky to have such a great team. So it’s with an equal measure of dismay and pride that we send off our three Seniors into their next adventures: Charlotte, founding member, hardware specialist, public relations lead, and project manager (and by night, more of the same!); Jacob, engineer and driver extraordinaire, and Amos, all-around assembly designer/builder/musician/etc. We wish you all great success and we will miss you!

While we will have a hard time filling all those shoes, we will have our returning members with yet another season’s worth of experience under their belts. And of course, we’ll have plenty of room for more budding roboticists! David and Patty are returning as coaches with at least some of Meg’s help (what would we do without Meg?); and we are partnering with EPS, and with BBA, to make robotics engineering more available to the youth in our community.

This summer’s project is to construct both a stationary programming board and a mobile programming board as a development platform for our navigational systems, funded by a grant from the Vermont Academy of Science and Engineering this past winter. We don’t know what the next game will be, but it’s a fair guess that we’ll have to navigate! We will use a goBilda strafer chassis as a base, with the REV Robotics Control Hub, a camera, and four distance sensors. Stay tuned for updates.

We’re looking forward to the start of next season’s game, “Power Play”, and we hope you’ll join us!

(Also, we have the contact info for Charlotte, Jacob, and Amos in our back pockets. Just sayin’.)

a photobombing rubber ducky

Freya’s Screen Debut, and a New Home

We’ve been taking an actual Spring Break, believe it or not. Members slept in, went places, and did things completely unrelated to robots. No, really!

Oh, ok, so we did start working on a new project. Over a weekend we got together to storyboard and film Freya for her screen debut: Freya and Ducks à l’Orange! No duckies were harmed in the making of this film. We promise.

We brought Freya to meet her adoring public at the Bennington Area Makerspace on May 7th, joining the Cookie Clickers at their Open House. She worked beautifully!

We also started May in our new home in the Smith Center at Burr and Burton Academy. We are incredibly excited to be invited to share the Robotics Lab with Mr. Morrison’s students! We had visitors there last Monday, and all had a great time driving around the lab and delivering balls, cubes, and ducks to each other.

Delivering Freight in the Smith Center!

It’s been a great year in our workshop provided by TPW Real Estate, and we will miss our awesome garage space. It allowed us to meet safely this year even during the Delta and Omicron waves, so that we could bring Freya to the VT State Championship.

Having community support is how we keep the program going, bringing STEAM enrichment to area students. While the majority of our current members are attending BBA, we welcome 7th-12th graders from any school (or homeschool) in the area. There are no membership dues or costs beyond transportation; expenses come entirely from grants and donations. Thus we are truly grateful for the support of TPW and BBA in providing the team a home.

2021-2022 Post-Competition Update

Early morning arrival at the Vermont State FTC Championship, March 19, 2022.  Left to right: Zach, Jacob, Isaac, Charlotte, Takoda.  Photo credit: Coach Meg.
Early morning arrival at the Vermont State FTC Championship, March 19, 2022. Left to right: Zach, Jacob, Isaac, Charlotte, Takoda. Photo credit: Coach Meg.

On Saturday, March 19, 2022, we took our robot, Freya, to the Vermont State FIRST Tech Challenge Championship competition hosted by the CVU RoboHawks in Hinesburg, VT. The competition involves several rounds of Qualification Matches, followed by the Semi-Final Matches, followed by the Final Match based on the rankings earned during the previous matches.

The team started out the day with an interview with two judges. We presented the season’s work, represented in our Engineering Portfolio and our larger Engineering Notebook. These had been polished up over the course of the previous week.

Freya was called up for the first match of the day, bright and early, partnered with the Ringers on the Blue Alliance. After a serious fumble in the Autonomous period, she was able to recover well enough to deliver ducks in the Endgame and score points for the Alliance. However, her delivery system was broken beyond on-site repair, and the remainder of the matches were played without it.

Our next Alliance was with the Cookie Clickers, our friends from the Bennington Area Makers. Both robots gave a creditable performance. We went on to play in a total of 6 matches, with each match improving as the drivers became adept at running Freya without her delivery slides and chute. They were able to use her intake to push freight all the way through, delivering to the bottom level of each hub.

The team was interviewed in the pit by the judges, who stopped by with each team to discuss their robots and their approach to the problems posed by the game challenges.

While Freya did not advance past the qualifying matches, she impressed the judges with her design and her modularity. She was able to compete without all her assemblies, and she was able to swap out her alliance markers between red and blue with a little Velcro™. The judges were also impressed by the team’s resilience and their engineering process through the season.

Congratulations to our Team on a Season and Game that was well thought, well designed, and well-played!

Judged Awards

The team came home with three awards – Second Place for the Think Award, Second Place for the Control Award, and First Place for the Design Award.

The Think Award: Removing engineering obstacles through creative thinking.

This judged award is given to the Team that best reflects the journey the team took as they experienced the engineering design process during the build season. The engineering content within the portfolio is the key reference for judges to help identify the most deserving Team. The Team’s engineering content must focus on the design and build stage of the Team’s Robot.

The Team must be able to share or provide additional detailed information that is helpful for the judges. This would include descriptions of the underlying science and mathematics of the Robot design and game strategies, the designs, redesigns, successes, and opportunities for improvement. A Team is not a candidate for this award if their portfolio does not include engineering content.

The Manchester Machine Makers earned Second Place at the Vermont Championships for the Think Award. The team created an Engineering Notebook with detailed and elaborate descriptions of all the systems of the robot, including the design and engineering process of both hardware and software, and the support systems provided by fundraising and community partnerships. This is the third year running in which the Team has been recognized in the Think Award category.

Control Award sponsored by Arm, Inc.: Mastering robot intelligence.

The Control Award celebrates a Team that uses sensors and software to increase the Robot’s functionality in the field. This award is given to the Team that demonstrates innovative thinking to solve game challenges such as autonomous operation, improving mechanical systems with intelligent control, or using sensors to achieve better results. The control component should work consistently in the field. The Team’s engineering portfolio must contain a summary of the software, sensors, and mechanical control, but would not include copies of the code itself.

The Manchester Machine Makers earned Second Place at the Vermont Championships for the Control Award. The team was able to show its consideration for improving the driver controls, and effective use of sensors and algorithms in its software.

Design Award: Industrial design at its best.

This judged award recognizes design elements of the Robot that are both functional and aesthetic. The Design Award is presented to Teams that incorporate industrial design elements into their solution. These design elements could simplify the Robot’s appearance by giving it a clean look, be decorative in nature, or otherwise express the creativity of the Team. The Robot should be durable, efficiently designed, and effectively address the game challenge.

The Manchester Machine Makers earned First Place at the Vermont Championships for the Design Award! The team put a lot of thought into the design of Freya, considering all aspects of how she would need to be both used and maintained. The judges appreciated the swappable Alliance markers as well as how well the robot performed on the field after having removed one component. The modularity of the design and flexibility of the robot’s performance were a key factor in the team’s success.

Dean’s List

Our very own Isaac Vernon was recognized as a Finalist for the Dean’s List Award as well.


Isaac Vernon Honored as a Dean’s List Award Finalist

Isaac Vernon, a sophomore at Burr and Burton Academy in Manchester Vermont and a member of the Manchester Machine Makers 4-H Club and FIRST Tech Challenge Team #16221, was recognized at the Vermont State Championships held on Saturday March 19 at Champlain Valley Union High School in Hinesburg Vermont as one of two FIRST Tech Challenge Dean’s List Finalists representing Vermont.

Isaac Vernon, a sophomore at Burr and Burton Academy in Manchester Vermont and a member of the Manchester Machine Makers 4-H Club and FIRST Tech Challenge Team #16221, was recognized at the Vermont State Championships held on Saturday March 19 at Champlain Valley Union High School in Hinesburg Vermont as one of two FIRST Tech Challenge Dean’s List Finalists representing Vermont.

States the FIRST website: In an effort to recognize the leadership and dedication of FIRST’s most outstanding secondary school students, the Kamen family sponsors an award for selected 10th and 11th grade students known as the FIRST Robotics Competition and FIRST Tech Challenge Dean’s List.

FIRST stands for “For Inspiration and Recognition of Science and Technology”. Similar to National Merit Scholarship Award Winners, there are three categories of FIRST Dean’s List Award students: FIRST Dean’s List Semi-finalists, Finalists, and Winners. The Semi-finalists are compromised of the two students in their 10th or 11th grade school year nominated by each team. FIRST Dean’s List Finalists are comprised of the the students selected at each state/regional championship (Vermont has two Finalists).

FIRST Dean’s List Winners are comprised of the 10 FIRST Robotics Competition and 10 FIRST Tech Challenge students selected from the applicable FIRST Dean’s List Finalists at the FIRST Championship being held April 20-23, in Houston Texas.

All of those Team members who are Semi-finalists, Finalists, and Winners are examples of student leaders who have not only achieved personal technical accomplishment, but also have led their Teams and communities to increased awareness of STEM and of the FIRST organization. It is important to recognize the contributions they have made and will make as they pursue further education, going on to become great leaders, student alumni, and advocates of FIRST.

This is the second year that the Team has been home to a Dean’s List Finalist for Vermont. We are proud of our Team members and grateful for their inspiration and dedication!

Isaac is a founding member of the Manchester Machine Makers and this is his third year on the team.

Java Reflection Tutorial, Part 2: Annotations

Welcome to Part 2 of the Java reflection tutorial. This part will focus on annotations, which allow arbitrary data to be attached to a class, method, field, or any other symbol.

If you have not yet read Part 1, please go read it. It explains some basic concepts.

Now, without further ado…

Getting Started

This tutorial assumes that you have from part 1. If not (I don’t), here it is:

import java.lang.reflect.*;
import java.lang.annotation.*;

public class Basic {
    public static void main(String[] args) {
        // SETUP //
        System.out.println("Hello Java Reflection");

        Class<?> cls = Basic.class;
        System.out.println("The class's name is " + cls.getName());
        Basic basic = new Basic();
        try {
            Method doSomething = cls.getMethod("doSomething", String.class);
            System.out.println("The method's name is " + doSomething.getName());
        } catch(NoSuchMethodException e) {
            System.out.println("A whatsit happened: " + e.toString());
    public void doSomething(String whatever) {
        System.out.println("Doing something very interesting...");
        System.out.println("Whatever is " + whatever);

Now, let’s take a look at annotations.

Built-In Annotations

Java has several built-in annotations, including @Override, @Deprecated, and others. Let’s take a look at @Override first.

@Override allows you to override previously defined methods. For instance, if you had a class called Class1 (very creative name, isn’t it?):

public class Class1 {
    public void doSomething() {
        System.out.println("Hello world, Class1 style!");

Then, say that you had a class called Class2, which extended Class1, and you wanted to define anew the doSomething method. You might take a gander at it like this:

public class Class2 extends Class1 {
    public void doSomething() {
        System.out.println("Hello world, Class2 style!");

However, you would be gandering at hot air, and the compiler would scream loudly at you for it. Don’t do that. In Java, you need to annotate any overridden method with @Override, like so:

public class Class2 extends Class1 {
    public void doSomething() {
        System.out.println("Hello world, Class2 style!");

As you can see, using an annotation is very easy: Just smack it down in front of the thing you want to annotate, and you’re off to the races.

And now, you can go and enjoy your polymorphic “Hello, World” in peace. But don’t go away just yet, because there’s more coming. Unless, of course, you’re bored out of your mind, in which case you would probably prefer some of the other content on this site.

An important note: @Override is not needed when overriding methods defined in interfaces or abstract classes. Those are meant to be overridden, and so the all-knowing Oracle realized that it was redundant to mandate that people specifically denote that they’re overriding something which cannot be used in any way except being overridden.

Anyhoo, now we move on to @Deprecated.

(looks up what @Deprecated actually does)

@Deprecated marks a program element (e.g. package, class, field, method, etc.) as deprecated. If you try to use a deprecated field, the compiler will give you a warning.

To use it, just put it in front of just about anything, like @Override:

public class DontUseMe {
    public void blowUpTheWorld() {}
    public String goodbyeWorld = "Goodbye, World";

Just in case it wasn’t obvious, now people know not to use that class.

This is just a small sample of the built-in annotations that Java provides. To see the full list (as of Java 8), see

Creating Your Own Annotations

To create your own annotations, use an @interface block. Not an interface, an @interface. Each parameter for the annotation is defined as a method in the @interface. For example, to create an annotation like the Author annotation in the official tutorial:

@interface Author {
    String name();
    String date();

And there you have it, a simple annotation. To use it, make sure it’s imported, and:

@Author(name = "Marty", date = "The Future")
// declare something here

If an annotation has only one method named value, you can pass it as an unnamed argument. For example, if @Author didn’t have date, and you renamed name to value, you could use:
@Author("Nobody In Particular")

Of course, you would probably want to make date into a Date, so that you don’t trip over unexpected time-traveling DeLoreans, but this suffices for a demonstration.

Now, this annotation can be used on everything at the moment — even the type of an argument. Since it’s kind of silly to put an @Author annotation on the type String, let’s fix that.

To restrict where your annotation can be used, you can annotate it (yes, you can put annotations on annotations) with a @Target annotation, in java.lang.annotation. @Target takes one argument, an ElementType or an array of ElementTypes. ElementType is an enum with the following options (mostly copy-pasted from

  • ElementType.ANNOTATION_TYPE can be applied to an annotation type.
  • ElementType.CONSTRUCTOR can be applied to a constructor.
  • ElementType.FIELD can be applied to a field or property.
  • ElementType.LOCAL_VARIABLE can be applied to a local variable.
  • ElementType.METHOD can be applied to a method-level annotation.
  • ElementType.PACKAGE can be applied to a package declaration.
  • ElementType.PARAMETER can be applied to the parameters of a method.
  • ElementType.TYPE can be applied to any type declaration.

For example, to restrict @Author to types, annotations, constructors, fields, packages, and methods (the sensible items), you would define it like so:

import java.lang.annotation.*;
// ...
@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.FIELD, ElementType.PACKAGE, ElementType.METHOD})
@interface Author {
    String name();
    String date();

Now, if you try to, say, take undo credit for the creation of java.lang.String, the compiler will yell at you.

Using Annotations for Reflection

Now, we get to the part that justifies this post’s inclusion in a series entitled “Java Reflection Tutorial”. To use annotations for reflection, you need to use the Annotation interface (in the java.lang.annotation package, which should already be imported from To get started, let’s put Author into its own file. Call it, and put it in the same package as

import java.lang.annotation.*;

@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE, ElementType.CONSTRUCTOR, ElementType.FIELD, ElementType.PACKAGE, ElementType.METHOD})
public @interface Author {
    String name();
    String date();

If it’s in a named package, be sure to put a package declaration!

Now, let’s put an @Author annotation on Basic, to let the world know who wrote it. Put this on a line before the class declaration in

@Author(name = "Fozzie Bear", date = "Somewhere around 2021")

Now that the humans know, let’s make sure that the computers know as well. To get the Annotation instance for the annotation, we can use the Class.getDeclaredAnnotationsByType method. Since we know that we can only have one instance of the annotation on any given element (to repeat annotations, annotate the annotation declaration with @Repeatable), we can just take the first element of the returned list and cast it to Author: (put this at the end of main)

Author author = cls.getDeclaredAnnotationsByType(Author.class)[0];

However, if you try to run this (I did), you’ll find that the annotation doesn’t exist! This is because of retention policies.

Somewhat Unplanned Interlude: Retention Policies

Retention policies (defined using the @Retention annotation) tell the compiler how long to keep the annotation around for. A value of RetentionPolicy.CLASS (the default) tells the compiler to keep the annotation around during compilation, but ignore it at runtime. A value of RetentionPolicy.SOURCE tells the compiler to ignore the annotation altogether, and makes the annotation behave, for all intents and purposes, like a comment. A value of RetentionPolicy.RUNTIME, which is what we want, tells the compiler to keep the annotation around during both compile and runtime, for reflection purposes. To make @Author available for reflection, add a retention policy in

// ...
// ...

And Now, We Return To Our Regularly Scheduled Programming

At this point, we’re retrieving the annotation class, but we’re not actually doing with it. To finish up, let’s print out the author and date from the annotation:

System.out.println("This class was written by " +;
System.out.println("Date: " +;

Now, if you run it, along with the output it previously gave, it will also print out the following:

This class was written by Fozzie Bear
Date: Somewhere around 2021

And we’re done! This tutorial just scratches the surface of what’s possible with annotations, though, so be sure to check out the official tutorial at

An Exercise

Try making Author able to be used multiple times, and modify to print out all of the occurrences. For instance:

@Author(name = "Fozzie Bear", date = "2021-09-08")
@Author(name = "Kermit", date = "2021-12-21")

And the output would be:

This class was written by Fozzie Bear
Date: 2021-09-08
This class was written by Kermit
Date: 2021-12-21

2021 End of Year Wrap Up Newsletter

Happy New Year from the Manchester Machine Makers! Below is what the team has been working on:


  • The Manchester Machine Makers also received a matching grant up to $500. Consider making a tax deductible donation to the Manchester Machine Makers 4-H Club. All gifts will be matched up until January 31, 2022! Donate here or scan the QR code. 


  • We have completed our drivebase! With the drivebase fully constructed and operational the team has met its deadline of November 23, 2021.
Above: Our robot’s first test drive on the field. \Right: The drivebase!
Above: Our robot’s first test drive on the field.
Right: The drivebase!

The intake and the delivery system

  • The intake system is critical to picking up pieces of freight. Currently we are in the process of building our intake system. We started the process by drawing a few rough sketches. We then started trying to put the intake together using the rough idea and eye-balling the process. Learning how to disconnect the metal chains only to realize we couldn’t reattach the chain. The plastic chain seems to be working very well and it is much easier to adjust the size. As a team, after getting a SolidWorks representation of the intake, we decided to change the sprockets to all one size. We learned the hard way that the sonic hubs should be fit onto the axle before putting them into the gecko wheel.
Isaac and Takoda present
the finished slide mechanism.
  • The delivery system is how the freight is moved from the robot to the delivery hub. All of the inserts have been successfully 3d printed (thank you Amy Wright at BBA) and issues with length of the inserts revealed that super gluing them together was unnecessary- the screws are sufficient. In addition, there was no system to drive the final stage of extension, so a bearing was added to the back of each of the lower slides. The slide assemblies were built and mounted to the custom angle brackets, and standoffs were mounted to that bracket. There was some horizontal expansion in the slides, so some small spacers may be needed along with the standoffs. Once the final bearing is attached to the back of the slides, they will be able to have four stages of extension, meaning the greatest remaining challenge is wiring the pulley system.


  • This fall, the team has taken part in the beta test of the FTC Machine Learning Tool. Part of this year’s challenge involves training a TensorFlow model to allow the robot to recognize a custom-designed object on the field. The FTC leadership has designed this tool to make machine learning more accessible to teams and make it simpler to construct the large datasets needed to properly train a model. Our team gained access to the tool early in order to provide feedback, improving the experience of other teams as it is opened to the whole FTC community.
  • In January the Manchester Machine Makers will be mentoring the Lego Team, the Fiery Froggies! Isaac Vernon and Charlotte Ruley will meet with the team to support them as they get ready for their competition.
  • The Manchester Machine Makers held a virtual open house on December 22. See the recorded session below to hear about our progress from the team!

Happy New Year!

2021 VASE HOST Grant

This fall we applied for the Vermont Academy of Science and Engineering (VASE) Hands-On Science and Technology (HOST) Grants program. The VASE HOST grants are given yearly and are primarily intended for science, technology, and robotic clubs/teams in Vermont. Typically about 10 grants are awarded ranging from $500-1,000.

This year the Manchester Machine Makers has been awarded a grant of $1,000 to create two Programming Boards. In the past we borrowed school programming boards so it will be helpful to finally have our own. For those who don’t know what a Programming Board is, it’s basically the necessary hardware needed for a programmer to test and develop code (see photo below). Interested? Check out our programming board page to see how to make your own!