How a high school robotics team achieved success thanks to
Perpetuum Software.

by Joshua Lynn

Engineering Mentor
FIRST Team 423 - SEC Robotics
Springfield Township High School, Oreland, Pennsylvania
Easter Center for Arts and Technology, Willow Grove, Pennsylvania
Cheltenham High School, Wyncote, Pennsylvania

BS Mechanical Engineering Carnegie Mellon University, Pittsburgh, Pennsylvania

Database & Application Architect MS SQL Server & .NET platform

An engineering mentor for a high school robotics competition must inspire success and set high goals while sharing bits of knowledge. A balance must be made between performing the work and letting students figure things out themselves. The goal is to give students a chance to experience and participate in real world projects by working alongside mentors. This is the story of one mentor and a small group of students working together to achieve success and an award.

The Competition:

The FIRST Robotics Competition, FRC, is an international robotics competition for high-school-aged students involving over 1,300 teams, 35,000 students, 40 regional competitions with a championship event held inside the Georgia Supper Dome. FIRST, For Inspiration and Recognition of Science and Technology, is an organization, founded by Dean Kamen, inventor of the Segway Personal Transport among many other things, dedicated to inspiring young people to become science and technology heroes.

According to FIRST:

“The FIRST Robotics Competition challenges teams of young people and their mentors to solve a common problem in a six-week timeframe using a standard "kit of parts" and a common set of rules. Teams build robots from the parts and enter them in competitions designed by Dean Kamen, Dr. Woodie Flowers, and a committee of engineers and other professionals.

FIRST redefines winning for these students because they are rewarded for excellence in design, demonstrated team spirit, gracious professionalism and maturity, and the ability to overcome obstacles. Scoring the most points is a secondary goal. Winning means building partnerships that last.”

In addition to competitive game play for awards and glory, there are several other competitions judged during the event that are targeted at other aspects of engineering from business practices, team work, sportsmanship as well as engineering design and innovation.

This year’s Game:

This year’s competition, FIRST Over Drive, had six robots racing around a 27’x 54’ race track while trying to coral and hurdle 40” balls, which weigh about 10 pounds, over a 6’ high bar. The machines are fairly substantial weighing in around 130 pounds and nearly 5’ high. Some machines designed to expand and reach nearly 10’ high during game play. The competition is tough and every aspect of the project from design and manufacturing to strategy and controls are critical to success.

Our Team:

Our team consists of 20 students from three high schools and 8 mentors in the north Philadelphia suburban area. The overall team structure breaks the work down into several sub teams: Chassis & Transmission, Manipulators, Pit Crew, Business Administration, Fundraising and Marketing, and Programming and Controls. This is the story of the Programming and Controls sub team, which consisted of four high school students and one Engineering Mentor.

The Programming and Controls team has a few unique challenges. The first of which is that we have to design, develop, build, and complete the software and controls to a moving target of a specifications that only has a real physical manifestation just days prior to shipping the robot for competition. To meet this challenge we developed a mission statement, a motto, and a project methodology to act as a guide and compass to enable us to complete the project.

Figure 1: Most of the programming and controls team. From left to right Kirk, Joshua, Ian, Jen and Derick. (Ian was part of the graphics team and was painting the control panel)

The Goal of the Programming and Controls Team:

Our Mission statement was “To be the 5th player on the field.” The significance of the 5th player is that only 4 human players are permitted to participate in the actual game play. The Programming and Controls team structured our solutions and designs to enable our small group to be as significant as a 5th player on the field. The challenge to us was that we were done playing before the match even started. Our software and controls had to be smart, interactive and enable the other four plays and even the pit crew to enhance and tweak the robot to meet the evolving strategy and challenges of game play.

The challenge:

One of the very cool aspects of the Kit of Parts, which all teams have to use, is the Operator Interface (OI) and the Robot Controller (RC), which are connected via two-way wireless modems. The RC sends a data 26 byte packet 40 times a second back to the OI. The OI has a serial port that streams the data to a connected device. We choose to connect a laptop computer and build a custom dash board for our robot. This is where Perpetuum Software comes into the picture.

We had a grand Vision of what we wanted to accomplish with the Custom Dashboard. However, the visualization of data for real time systems is a challenging field for software development. Add a six week timeframe and it gets even harder. Looking around the internet we found several companies that offered various gauges and controls for display. However, none of them meet our needs out of the box and none of them appeared to have the ability to adapt to our envisioned design or our moving target of a design, except for Perpetuum Software’s Instrumentation ModelKit.

The Perpetuum Software Instrumentation ModelKit was the perfect solution to our needs due to the innovative designer that allows for the building of custom widgets through linking key instrumentation and display parts together to make an instrument that cleanly indicates the state and nature of your system. We had a very specific need and no ability to code the graphics to accomplish what was required to make one aspect of our control system interactive. Thanks to the Instrumentation ModelKit we were able to build, tweak, refine and implement the graphical representation of our system we need to make interactive without writing a single line of code! This was key to our success because we had other code that was essential to write or the machine would not function.

Here is a description of one of our projects and how we were able to use the Perpetuum Software Instrumentation ModelKit:

The Specific Problem:

When driving a robot using a Joystick where the input is directly mapped to the output of the motors produces a robot that is jerky, overly reactive and hard to control. The reason for this is two fold. First there is no damping or filtering from the input to the out put to smooth signal. Even with a 40Hz refresh rate this overly sensitive nature has the capability to throw chains of off sprockets if the direction of the motor is switched to quickly. Secondly, the linear nature of the input signal does not correlate well to the non-linear power curve of the electric motors, especially under load. This was evident when trying to turn the robot. The joystick seemed to have only the slightest range of movement to perform slow or careful operations. Any further on the Joystick and the machine would be moving too fast requiring the drive to compensate and react quickly. This produced even more jerky behavior.

Figure 2: The control panel. In the lower left of the panel there is a big black wheel and a red button. These are the physical controls used as inputs to the custom display indicator.

The solution:

The solution has several components. The easiest to implement was a state-full digital filter function in software. The filter responded both proportionally to the difference in the current output of the motor to the desired output as well as differentially to the rate of change in the motor from the previous iteration. Both the proportional and differential components’ sensitivity, or gain, could be adjusted through modification of constants. For those that care this implementation is just the PD of PID control theory.

The more challenging part was to develop a transform function that would allow us to remap the input to output of the Joystick. This would enable customization of the response cure from the joystick from linear to whatever was needed. Additionally, the Robot Controller, RC, had a fairly simple PIC chip that was not conducive to floating point math. Therefore we had the additional requirement of using integer based math with basic mathematical operations. Finally, it needed to be simple to configure and easy to understand. This would enable the drivers to be able to use their experience to adjust the performance to their needs and preferences.

The Joystick filter function was based on a very simple linear geometry y = mX + b to describe a line in two dimensions. Our function used X as the input from the joystick and Y as the output of the function to be used as the input to the digital filter of desired motor speed. The normal default for most teams is a 1:1 correlation of the input to the output. Our design was to alter the slope at different segments of the range to get a different output.

The motor speed in one direction can be set by a number from 0 to 127 where 0 is stop. If we used a slope of ? at a value of 64 we would have an output of 32. The problem with that is at an input of 127 we would have only an output of 63 and could never reach full power. The solution was to use three lines of various slopes where the last line always mapped to 127 as an output.

In the simplest terms we defined three lines with different slopes that intersected at different points along the X axis. We added an additional segment from 0 that we forced to have an output of 0 so that we could create a dead band region around the stop position. This was needed so the drivers didn’t have to hold the joystick in the exact precise spot to stop the robot. The final segment was a bad at the other end that created a maximum input value above which the output was guaranteed to be 127 or full power. This allowed for compensation or an adjustment of the limitation of the joystick to be physically limited from producing a full range of values. The result was that we had both a software trim and a physical trim dial on the joystick.

The Implementation:

The solution was based on a predefined set of mathematical equations that solved for the set of all possible solutions of the design. To implement the design we solved the equations by substituting parts for variables we exposed as inputs for configuration: Here is a summary of the parameters needed con configure the function:

q: The value on the X axis between 0 and which the output is set to 0. This is the dead band setting.

m1 & m2: The slope of the line for line segments 1 and 2 respectively.

I1 & I2: The intercept values along the X axis where two line segments meet. I1 is the intersection of lines 1 and 2 while I2 is the intersection between line segments 2 and 3.

Xmax: Is the value above which the output is 127. Logically this is the equivalent of I3 since it is the intersection of line segment 3 and the final line, which is a horizontal line with a constant value of 127.

The question as to why there is no I3 is relevant at this point. The answer has two parts. The first is that it isn’t needed since we define the output function to be continuous for the full range of the X axis. Therefore once I2 is known the other end of that line is fix at the point of (Xmax,127). This means that I3 is derived rather then specified. The second reason is much more practical. In the software when trying to do integer based math fractions can be a bit tricky. Additionally, the data packets sent back to the OI are limited to bytes. Additional coding would be required to pass a single value that was greater then 255. Therefore to simplify the problem we just stated that the variables that stored the slope would be bytes that were expected to be divided by 255 to get their fractional representation. This implies that a variable value of 255 is equal to 1 and a value of 127 is equal to ?. Line segments 1 and 2 could not have a slope grater then 1. Line segment three always had to have a slope grater then 1 to complete the function. However, that slope could be calculated when needed and stored in a variable much larger then a byte. The final benefit was hat we could make efficient use of bit shifting to do much of the multiplication and division. Bit shifting is a very fast operation on the PIC chips used in the RC.

The transform function was finally written and coded, tested and integrated. The storey of the development of this function is a good leaning experience and goes through a variety of software engineering techniques including test driven development, modeling, and C coding techniques. However, it will be omitted from this story so focus can be applied to the user interface for controlling the parameters of this function.

We needed to store several sets of parameters to accommodate various drive modes including high gear and low gear drive as well as turning in both high and low gear. Each set of parameters needed to be adjusted for each driver. To enable the adjustment we developed several bits of code on both the RC and on the laptop connected to the OI.

The fist bit of code needed was a function to allow for a continuously rotating knob to represent any value with a dynamic range of values permitted. The second bit needed was a menu-ing or mode system so that we could identify to both the robot and the driver what value if any was being modified. This system was hooked up to the virtual dial from the previous bit of code and an enter button.

The final bit of code was the part that used the Perpetuum Software Instrumentation ModelKit. After a bit of trial and error while exploring through the code samples and controls provided with the kit we came to a decision on what we wanted and how we were to implement it. The following is a description of what we did:

Development of a real-time Dashboard indicator:

Using C# we developed a class library to represent the function and a custom user control. This control contained several widgets. One widget for each of the configuration parameters to display its value designed to look like a digital volt meter and a very special custom widget that displayed the 2D graphical representation of the transform function with a real time display of the joystick input to output. (Now would be a good time to find the picture of the control since the description that follows will be much clearer.)

Figure 4: Control in action.

The standard Cartesian grid shows the representation of the X and Y axis with values from 0 to 127. The vertical and horizontal cross hairs show the real time position of the joystick and the effect of the transform function. Remember X represents the input and Y the output. The red dashed line represents that nominal slope of 1 that we are trying to modify for our needs. The reaming black lines show the line segments that are defined by the parameters of the functions. When the function is applied the real time cross hairs follow the black line segments.

The implementation of the transform function grid turned out to be very straight forward. Of course there was a lot of testing, trial and error until we decided on what we wanted, how we wanted to look, and how to get the designer and the controls to behave the way we needed. That being said here’s what it all boiled down to.

We started with a widget whose design we copied from one of the samples. This gave us the basic outline of what we needed and contained all the elements needed except for the custom drawn lines. We chose to use a widget over an Indicator Widget since we found it easiest to access the elements of the widget through the instrument objects GetObject method. Then for each of the elements of the widget we wanted to control programmatically we created a variable of the appropriate type and grabbed a reference to the constituent object through the GetObject method.

Figure 3: The designer laying out all the elements of the main display.

In the designer we added the lines we needed and gave them names that were meaningful. The lines were just drawn as representations; their actual positions were controlled by the user control logic and the properties of the custom class that handled all of the math for the function. We just needed to create them in the designer so we could use them in code later. We could not find a way to pragmatically add lines to the widget in runtime after it was created by the designer at design time. This last bit took a while since we were still considering if we should be using a charting component to do what we needed where we just kept changing the dataset that created all the lines.

The class had already been written completely independently of the custom widget and tested to prove that it generated the correct results. This allowed different developers to work on the project. One set focused on the class and its logic. This team also ported the logic from C# to C that could be complied and used by the robot. The other team just worked in C# with widgets to build the custom user control to display what was going on in the robot as adjustments were being made.

The custom user control exposed properties for the Current X and Y values from the joystick as well as the current value of the variables representing the parameters as know and by the robot’s processor. The rest of the logic was wiring up the class that did all the math to the widgets displaying the data. The user control part while being the most complex in terms of the graphic display tuned out to be one of the simpler parts to write. This is where the Perpetuum Software Instrumentation ModelKit shows off its value. Once the parts and pieces were understood it was fairly easy to implement.

Lessons Learned:

For those looking to implement this kind of display control here is what you need to know.

• Most of the documentation is geared towards interactive controls where you use the computer and the mouse to interact with the dials, gauges and switches.
• If you want to change the values of sliders, digits, lines or any of the components that make up an instrument create a widget and use the designer to name the parts you need to something you can identify then in code create variables of the appropriate type to use as reference to the actual object. The following hunk of code would have made the learning curve much faster and easier if we had known it earlier in the process.

using PerpetuumSoft.Instrumentation.Model;
Slider XLine;
Slider YLine;

XLine = widget1.Instrument.GetObject("SliderX") as PerpetuumSoft.Instrumentation.Model.Slider;
YLine = widget1.Instrument.GetObject("SliderY") as PerpetuumSoft.Instrumentation.Model.Slider;

XLine.Value = _X;
YLine.Value = _Y;

• Make a user control so that you can abstract the functionality from the implementation. The users of your control only need to set the properties or call methods to get the behavior. They don’t need to know how the instrumentation kit works at all.

Figure 5: That's our team in the red Tee shirts. Our robot is the one in the middle with the black and yellow stripes.

Figure 6: There we are taking the lead autonomously. Notice no hands on the controls. Go Programming Team!

Figure 7: Out in front and winning!

It was a prestigious honor and was delighted to have achieved our goal to a point where we were recognized for our efforts.

Figure 8: This was an off season competition. Left to right Joshua, Charlie, Tina, Anna, Charlie and John.