This sessions goals:

  • Test of wheels and other physical extensions
  • Choose a balancing medium
  • Test of possible sensor solutions
  • Motor variable calibrations
  • Construct a base for the robot
  • Build wheelbase
  • Build sensor mount
  • Choose and define a software structure

The Plan

In this session we will be building Max’s body and starting to prepare the needed software. The progress can be seen in our project plan Table 1:

Project plan for week 22. Table 1: Project plan for week 22.

Test of wheels and other physical extensions

Plan

The plan for testing the different wheels that we have available is to review them in accordance with experiments and observation from previous lessons and thereby find the most applicable wheels to use on Max.

Experiment

Experiments and observations regarding the available LEGO wheels can be found in our previous lesson notes noticeably lessons: 5, 8 and 9.

Results

Because of the nature of our project there are several important factors that come to light in regards to the wheels we will use and their properties, which are as follows:

  • The friction of the wheels when not turning along their own axis of rotation.
  • The amount of energy transferred to the balancing medium when trying to turn it.
  • The consistency of the above mentioned properties.

Traditional wheels as seen in figure 1, allow for motion along their own axis of rotation without unwanted friction. However, when the movement of Max is perpendicular to the wheels’ axis of rotation they would instead only provide unwanted friction against the ball. Rotacaster wheels, as seen in figure 2, is constructed in such a way that they do not create unwanted friction when the axis of rotation is perpendicular to their own.

Three examples of traditional LEGO wheels. Figure 1: Three examples of traditional LEGO wheels.

An example of a rotacaster wheel. Figure 2: An example of a rotacaster wheel.

The amount of energy that can be transferred from the wheels to the balancing medium is crucial as this impacts the speed of which Max will be able to travel. Furthermore, it will affect how much tilt the wheels are able to overcome, as a lack of transfer will result in Max falling over. In this case, the traditional wheels have an advantage over the rotacaster wheels because they have complete contact with the ball at all times providing maximum transfer. The rotacaster wheels do not provide maximum contact because the small rollers are mounted at an offset to each other, meaning that when driving along their own axis of rotation there is approximately 50% of the wheel that is transferring energy since the rollers are the only part in contact with the surface, which means that the light gray areas seen in figure 2 are not transferring energy.

Lastly, the consistency of the above mentioned properties are generally speaking sufficiently consistent. We have, however, observed that wheels without solid tire tracks show inconsistencies in how much of the motion that would be transferred between the wheel and the surface because of the tracks decreasing and increasing in the amount of surface area that makes contact with the surface as well as the amount of force asserted on it.

A wheel type that is not included in this comparison is Mecanum wheels, as seen in figure 3. This type of wheels are like rotacaster wheels but with the rollers at a 45 degree angle instead of along the axis of rotation. These could have been interesting to investigate further but since we do not have any available to us, and the rotacaster wheels providing a highly probable solution, we did not try to acquire these for further testing.

An example of a mecanum wheel. Figure 3: An example of a mecanum wheel.

With all of this we can conclude that the rotacaster wheels present the most plausible solution for our project at this time.

Choose a balancing medium

Plan

We want to find a balancing medium for Max. In this section, we will describe what medium we chose and why.

Experiment

We went to a nearby toy store, called Fætter BR, to find a ball that could fit Max’ needs. As described in the previous session, it is important to consider the size, shape, weight, viscosity and surface material of the balancing medium. This meant, when we went to Fætter BR, that we would compare the different balls they had available to us in their store (they had a lot of different balls, and they can all be found on Fætter BRs website). We wanted a light, as perfectly-rounded ball as possible, with a smooth surface that is not too slippery (not creating enough friction), nor is too rough (creating too much friction).

Programming

None, as the balancing medium is a plastic ball.

Results

The ball we chose as our balancing medium is a Fætter BR ball, 23 cm in diameter. It is made of plastic and is therefore lightweight. Furthermore, the semi-rough plastic surface provides the needed friction for making the wheels turn the ball, without too much power needed. The viscosity of the ball is acceptable, although it is a bit soft. We hope that this will not be an issue causing Max to slip over the ball so the wheels do not touch the surface. The ball can be seen in figure 4.

A 23 cm Fætter BR ball! Figure 4: The balancing medium – a 23 cm Fætter BR ball!

Test of possible sensor solutions

Plan

We plan to test the sensors we found most useable in our research. This means we will build upon our previous experiences with the gyro from lesson 5 and then test the accelerometer and the gyro’s capabilities for measuring the posture of Max.

Experiment

To make Max balance we will have to know how the sensors behave and what we need to be aware of. We will therefore do a series of small experiments to see how they behave under certain conditions.

First, we will start by logging the values from the accelerometer and the gyro over a period of 1 min with a 25ms interval while the sensors are positioned statically in a predefined position to investigate the consistency of the sensors. The test period (1 minute) and the interval (25ms) are chosen because of the limited storage space of the NXT, and we believe this will provide us with approximately 1500 data samples which we suspect should be sufficient to reach a valid conclusion.

Secondly, we will try measuring the values of the sensors while being subjected to a predefined and consistent motion for a 1 min period. This will show us how the sensors behave while in a more realistic setting.

The accelerometer measures in 3 axis which means that we will only need one for getting the required data for making Max balance. We will log the values from the X, Y and Z axes during the experiments.

The gyro, unlike the accelerometer, only measures in 1 axis, which means we will need at least 2 gyro sensors perpendicular to one another to get us the required data. We could also have investigated the possibility of using three gyro each positioned parallel with one of the wheel mounts. We will log the raw value and the angular Velocity of each of the gyro sensors during the experiments.

Programming

For the experiments we will be using a modified version of the DataLogger class which was made available during the first lesson. The only change made is the addition of a couple of new methods allowing the DataLogger to take a String input instead of an int, as seen in the following code snippet:

public void writeString(int time, String sample) {
  try {
    Integer timeInt = new Integer(time);
    String timeString = timeInt.toString();
    for(int i=0; i<timeString.length(); i++) {
      fos.write((byte) timeString.charAt(i));
    }
  ...
}

The complete DataLogger.java can be found here.

We are also using a total of four data gathering programs; two for gathering data from the accelerometer and gyro in a static setting, and two more for gathering data while moving the sensors by using two servo motors. The gathering of data is simple since it only needs to get the data from the sensor and then write the data to a comma separated file for further data analysis. For the programs using servo motors to simulate motion, the program needs to handle three simultaneous threads; one for the base motor, one for the top motor and the last thread for data collection. As seen in the following code snippet, the only function of the servo threads is to turn the servos from side to side:

Thread baseMotor = new Thread(new Runnable() {
  @Override
  public void run() {
    NXTRegulatedMotor baseRotation = Motor.C;
    baseRotation.setSpeed(motorSpeed);
    baseRotation.resetTachoCount();
    while(true){
      baseRotation.rotateTo(-180);
      baseRotation.rotateTo(0);
    }
  }
});

The threads are not immediately started. They are prepared and started 1 second before the main thread starts collecting data. This is done because of the spike in current which the servos create when they start moving, which affects the gyro sensor when doing its initial calibration. So by starting them beforehand the gyro can correctly calibrate and function afterwards.

The code for the following experiments can be found below: Accelerometer static test can be found here. Accelerometer motion test can be found here. Gyro static test can be found here. Gyro motion test can be found here.

A complete package of all the code can be found here.

Results

As seen in the following figure 5, the accelerometer was mounted and tested in three different positions to see if the data would be similar or if the accelerometer “favours” a side.

Accelerometer positions left to right: Horizontally; Sideways and Vertically. Figure 5: Accelerometer positions left to right: Horizontally; Sideways and Vertically.

As seen in the following three figures, the data from the accelerometer is similar and we would therefore conclude that there is no side better than the other.

Data collected while accelerometer was positioned horizontally in a 1 min period. Figure 6: Data collected while accelerometer was positioned horizontally in a 1 min period.

Data collected while accelerometer was positioned sideways in a 1 min period. Figure 7: Data collected while accelerometer was positioned sideways in a 1 min period.

Data collected while accelerometer was positioned vertically in a 1 min period. Figure 8: Data collected while accelerometer was positioned vertically in a 1 min period.

What is noticeable in figures 6, 7 and 8 is that at the beginning of the experiment, the accelerometer spikes and then after a small period of time settles and becomes more consistent. The accelerometer has some uncertainty but mostly no more than ± 5.

As seen in the video here, the accelerometer is being moved around in a consistent manner to see the effects of actual motion to the sensors.

The results of the accelerometer motion experiment can be seen in figure 9 below.

Data collected while subjecting the accelerometer to motion over a 1 min period. Figure 9: Data collected while subjecting the accelerometer to motion over a 1 min period.

As seen in figure 9, the accelerometer handles the motion consistently with no noticeable change of reliability over time. The results shown above concludes that the accelerometer is sufficiently accurate and consistent to be used for balancing Max. The gyro, unlike the accelerometer, was only tested in one position, as seen in figure 10, as it only measures rotation in one direction. With this, we believe that by placing the two gyro sensors perpendicular to each other we will get the required data from this single experiment.

Setup for data collection from gyro sensors over a 1 min period. Figure 10: Setup for data collection from gyro sensors over a 1 min period.

The results from the experiments can be seen in figure 11.

Data collected from gyro sensors over a 1 min period. Figure 11: Data collected from gyro sensors over a 1 min period.

The data from the gyro sensors experiment, shows that they both are very consistent showing a deviance of ±1 degree. An interesting discovery is that gyro sensor 1 is consistently -1 off the baseline while gyro sensor 2 is going both above and below the baseline, suggesting that each gyro sensor might have its individual preferences.

In the video here, the gyro sensors are being moved around in the same way as the accelerometer to see the effects of motion on the gyro sensors.

The results from the experiment can be seen in the following figure 12:

Data collected while subjecting the gyro sensors to motion over a 1 min period. Figure 12: Data collected while subjecting the gyro sensors to motion over a 1 min period.

As seen in figure 12, the gyro sensors start drifting over time, which is a serious problem when trying to balance Max over a longer period of time. However, when looking at where the curve spikes are, at least for the first part, they are more discernible than when compared to the spikes from the accelerometer data which are clustered more together. After reviewing the data gathered from these experiments we can see that the accelerometer creates a good basis for making Max balance. We have, however, decided to utilize both the accelerometer and the gyro sensor so that we through sensor fusion can get the reaction to sudden changes that the gyro provides and the stability over time that the accelerometer provides – and hopefully combined be able to filter out the disadvantages of both.

Motor variable calibrations

Plan

In this section, we want to make the basis for controlling Max’ motors. We will do this by making methods that handles different situations e.g. driving forward, rotating on the spot etc.

Experiment

Because Max is not yet able to balance by himself means we can not perform any experiments with the methods, except testing that they run as we want them to. We will test the methods in an isolated setting, to confirm that they actually work as intended. We cannot test in our desired context because we have not made Max capable of balancing as of yet.

Programming

private MotorPort leftMotor = MotorPort.A;
private MotorPort rearMotor = MotorPort.B;
private MotorPort rightMotor= MotorPort.C;

public final static int RIGHT = 0, LEFT = 1;
public final static boolean REVERSE = true, NOTREVERSED = false;
private boolean isReversed;

private int leftMotorCorrectionValue = 0;
private int rearMotorCorrectionValue = 0;
private int rightMotorCorrectionValue = 0;

As seen in the code snippet above, the motor control consists of three motors as public variables to help make method calls more readable, and correction values for each motor. All of this means that we are able to set the motors to be reversed e.g. upside down, meaning that forward becomes backwards. To make it easier to read and understand the code along the way, we made it so that we just set the boolean defining whether the motors are reversed or not.

The correction values for each motor are values that can be giving a value that is removed from the motors power, which means that for example if motor two is running faster than the other two motors then we could adjust for this with the correction value by subtracting it. The reason that values will need to be subtracted is that if the power for the motors is set to 100, which is the maximum value that the motors provide, then the correction value would have no effect since values above 100 are just reduced to 100.

We have made the methods forward, backward, rotate, stop and powerMotor, which are mostly self explanatory. There are a few noteworthy elements for the following methods:

Forward & Backwards

public void forward(int steerPower, int forwardPower, int mode){
 ...
 }

The code snippet above is the method that should drive Max forward. It then uses the rear motor for turning by using the steerPower parameter making Max turn while driving. The forwardPower parameter is the power applied to the two other wheels making Max move forward or backwards. Lastly, the mode parameter is the MotorPort mode set for the steeringMotor, which is added so that we for example could give it the parameter MotorPort.STOP which locks the steering wheel and makes Max go straight.

powerMotor This method lets us control the power given to each motor and nothing more. This is mostly for keeping the balance of Max, since we need to make small corrections on each motor to maintain the balance.

The complete motor control class can be found here.

Results

Even though we have not been able to test the methods in the desired context, the methods work as intended and provides all the needed functionalities which we at this point would encounter. This can be seen in the following videos:

Driving forwards can be seen here. Rotating the ball (driving left) can be seen here.

Construct a base for the robot

Plan

In order to make Max able to balance on a ball, we need to construct a base for the robot. This base has to include places to mount the motors, the various sensors and the NXT. In this part of the session, we will look into the construction of such a base.

Experiment

We have chosen to construct a 3-wheeled model of the robot, such as the one described in session 2. As discussed in the previous session, the construction will have a stable balance if the center of mass is below the pivot point. To do this, we will construct a low 3-wheeled robot which consist of several important parts that need to be attached to a solid base. The parts are:

  • Constructing a strong base
  • Attaching the wheels
  • Attaching the sensors
  • Attaching the NXT

All the parts must also be rigidly constructed so as decrease instability of Max. We will now describe how we will construct the base, and then continue afterwards with the wheels and sensors.

Constructing a strong base

To make sure Max will be able to run as smooth as possible, we need to construct a strong, solid base for the body. A major challenge here is the fact that we use three wheels with an equally divided distance and angle, in order to divide the weight into ⅓ parts as much as possible. Creating a lego construction with sharp angles is not immediately obvious how to do, however, we found a solution that could make the robot stay rigid as seen in figure 13.

Founding a base construction for Max’ body. Figure 13: Founding a base construction for Max’ body.

By using using this, we were able to construct a larger, more rigid body. One of the key points for creating a strong, rigid lego construction is by having several places connected. By doing this, we constructed a base which can be seen in figure 14.

A first version of the body. Figure 14: A first version of the body.

Having this body, we made sure to keep open connections for the possibility of adding wheels, sensors and the NXT.

Programming

None, since we are putting together the “hardware” of Max.

Results

The end result can be seen in the three images in figure 15. Note that the NXT is not mounted yet, but merely put on top to have something to show the size of the construction.

The base construction from several angles. Figure 15: The base construction from several angles.

Now that we have a sturdy base construction, we are ready to attach the wheels, sensors and NXT.

Build wheelbase

Plan

We will in this part construct a wheelbase which should uphold a series of criteria which we have deduced from our previous experiments, observations and research:

  • The wheel should be mounted perpendicular to mounting axis.
  • The wheel should be attached to a wheelbase that should stabilize the wheel so the shaft does not bend when running.
  • Should provide a strong and stable mounting to Max’ base construction.

Experiment

In figure 16 we can see the mount that holds the rotacaster wheel. It is built with a strong construction that goes around the wheel to prevent it from bending (A). While constructing this, we discovered that we also need the construction to go up over the wheel to completely prevent it from bending when running (B). Since we are using the EV3 Servo Medium motors, the wheels will automatically be positioned perpendicularly to the motors, making sure we comply with the previous set criteria. Also, we added tubing for aesthetic purposes (C).

Rotacaster wheel mount. Figure 16: Rotacaster wheel mount.

In the following figure 17 we have built the mount for the base of Max, which also attaches the motor to the wheel.

Base and motor mount attached to wheel mount. Figure 17: Base and motor mount attached to wheel mount.

The added attachment for connecting the motor and wheel to the base has two arms that go up and grip the base high (A) while two arms connects to the base bottom (B). There is also attached an additional arm to the side (C) which we later had to remove because it was obstructing the ball, and also turned out to be unnecessary to make the construction stable.

Programming

None, since we are putting together the “hardware” of Max.

Results

The result as seen in figure 18 shows the steps we went through: wheel mount, base connection and a complete wheel base with motor attached to the base unit.

Wheelbase in different stages of development. Figure 18: Wheelbase in different stages of development.

Now that we had a wheel base, we wanted to attach it to the base construction. The first version could be seen on Figure 15, however, we found that the wheels were still not rigidly attached to the base when positioned on the balancing medium. This meant we had to add some supporters between the wheels, as can be seen in Figure 19.

Wheelbase mounted and supported on the base construction. Figure 19: Wheelbase mounted and supported on the base construction.

We found, however, when placing this version on a balancing medium, that Max would be leaning on the supporters and the wheels would never make contact with the balancing medium. This was when we realized that the “interior” support, as seen back in figure 17, C, would also touch the surface of the balancing medium. From these experiences, we redesigned the supporters and came with a final, extremely sturdy construction as depicted in figure 20:

Max with enhanced support beams, making the construction very sturdy. The support between the wheels have been created more straight; not bending inwards as in the earlier version. Figure 20: Max with enhanced support beams, making the construction very sturdy. The support between the wheels have been created more straight; not bending inwards as in the earlier version.

Now that we had the wheelbase mounted to the base construction, we were ready to attach the sensors.

Build sensor mount

Plan

Now that we have a sturdy construction with wheels mounted, we need to mount the sensors if we want a ball balancing robot. In this section, we will describe how and where we attached the required sensors.

Experiment

The two sensor types we will attach to Max are:

  • Accelerometer
  • Gyro sensors

As we investigated earlier, the positioning of the sensors are important to make sure Max can maintain his balancing abilities. Also, we need to make sure that the sensors are very tightly secured to the base construction because small, irregular movements (such as shaking) can give wrong data to our sensors.

Accelerometer

We need to get the best readings possible from the accelerometer, which means it has to be positioned as close to the pivot point as possible. This is because that the accelerometer that we are using is a Hitechnic accelerometer which can only handle ±2G so by placing it closer to the pivot point, we reduce the G force that the accelerometer is exposed to as opposed to placing the accelerometer at the top of Max making it easier to max out the accelerometer with lesser motion.

Gyro sensors

The gyro sensors need to be positioned perpendicular to each other. We will do this by constructing a small frame, much like the one used in our experiments earlier. The exact positioning relative to the pivot point is not important as long as the direction the gyros face are related to each other.

Programming

None, since we are putting together the “hardware” of Max.

Results

We attached the sensors in two different positions. We will now describe each of them individually:

Accelerometer

The accelerometer has been placed in the middle of the base construction, as can be seen in figure 21.

Positioning of the accelerometer (the black in the middle) Figure 21: Positioning of the accelerometer (the black in the middle)

By having the accelerometer placed here, it will be positioned close to the pivot point which reduces G force. One of our concerns by placing it below the base construction is whether the accelerometer will touch the surface of the balancing medium or not. However, as seen in figure 22, we believe this is not a problem since the combined weight of Max will not push the the accelerometer to touch the surface of the balancing medium.

The accelerometer will not touch the balancing medium. Figure 22: The accelerometer will not touch the balancing medium.

Gyro sensors The gyro sensors have been attached on the side of the construction. At first, we thought the simplest way to attach the gyro sensors was on the side of the NXT. However, the NXT also had to be attached to the base construction, which could cause irregular movements of the gyro sensors – which made us change the location of the attachment to the rigid base construction, as seen in figure 23.

Attachment of sensors. Figure 23: Attachment of sensors.

We now have the sensors mounted and we are ready to start programming Max.

Choose and define a software architecture

Plan

In this exercise we will use previous research on related software solutions to choose a desired software architecture. We will then describe how the chosen architecture can be refined to comply with the main criteria for making Max balance and move.

Experiment

None needed, since this exercise is a discussion

Programming

The initial structure of the software for Max is sketched on figure 24 in a UML diagram.

UML Diagram of Max’ program. Figure 24: UML Diagram of Max’ program.

This UML diagram shows the relation between the arbitrator, the behavior and the behavior action. To the right is the four different behaviors (AlignToLine, Waypoint, ControlledMovement and MaintainBalance), and to the left is the motor controller class (MotorController).

Results

Choice

In our first session we set criteria for the actions Max shall be able to do. These action can also be defined as behaviors, which we deemed the most favored software architecture in session 2.

Back in lesson 10, we modified an architecture that were given from the lessons notes and this modified architecture is favorable for this project because of its more compositional approach. However, since we are still in an early stage in the development of Max’ balancing abilities on a ball, we might need greater changes in the final architecture later in the process.

Defining the architecture

This behavior architecture will consist of an arbitrator class, a movement class, four behavior classes (maintain balance, controlled movement, align to line, and go through waypoint and then stop), and three sensors (two gyro sensors and on accelerometer) for the balancing part.

Arbitrator

The arbitrator class, as shown in figure 25, will handle all the behaviors, securing which behavior that will be performed and which behaviors that will be suppressed according to their priority level.

Behaviour priority model. Figure 25: Behaviour priority model.

Motor

This class will handle all of Max’s motors and coordinate their individual movement. This class will also define different groups of movement of Max (e.g. three individual motor movements grouped as Max moving forward). This class will be the main class for output and is accessible by the behavior classes.

The following classes are represented in order of their priority to the arbitrator class; i.e. first represented behavior has highest priority, second represented has second highest, etc..

Maintaining Balance

The maintaining balance class will handle Max’ balancing ability on a ball. This class will get data from the balancing sensors and determine if it needs to make the motor class adjust Max’s balance, thereby securing that he will not fall off the ball. In the arbitrator class, the maintain balance class will have the highest priority, since the main purpose is to keep Max balanced and all the other functions are depending on Max staying balanced.

Controlled Movement

This class handles incoming commands from a control interface/device, such as keyboard commands from a laptop. The handling of these commands will be through bluetooth communication and the given command will be sent to the motor class.

Align To Line

This class will fulfill the purpose of ensuring that Max is aligned to a line, if he is balanced and has not been given any external commands. This class will collect data from a relevant sensor to distinguish if Max is aligned or not and will send commands to the motor class, if realignment is needed.

Go Through Waypoint And Then Stop

This behavior class has the lowest priority and will therefore only perform when not suppressed by the previous mentioned behaviors. This behavior will be performing predefined commands and will not use data from sensors to navigate.

Sensor classes

There will be a class for each sensor that we used for Max. Each sensor class will have a public method for getting their data so each behavior can call these methods. This should help the control of data and secure consistency.

General

Problems

We have not faced many critical issues so far. We had a few problems with making the base construction and attached wheels sufficiently rigid and at the same time fit onto the ball. We do, however, fear that the combined weight of Max’ body might be too much, consequently resulting in Max resting with the accelerometer, in the middle of the construction, on the ball. If this happens, we consider using the EV3 ball caster attached below the accelerometer. By doing this, the ball should still be able to rotate with minimum friction from only our three wheels and the ball caster.

Conclusion

We have constructed Max N00b as a 3-wheeled ball balancing robot, fully attached with sensors; i.e. two gyro sensors and an accelerometer, for balancing on a plastic Fætter BR ball. We have decided upon a behaviour based software architecture which we will start programming in the next session. So far, so good. Now the real challenges can begin.