This sessions goals:

  • Build tightrope platform
  • Make camera tightrope rider
  • Implementation of bluetooth communication
  • Implementation of calibration program
  • Calibrate PID control
  • Research on the inverted pendulum theory
  • Define and implement complementary filter for PID controller

The Plan

The plan for this session is to build our tightrope platform, make a small robot for driving there (an emergency substitute for Max), and further improve on the balancing control. This can also be seen in table 1.

Project plan for session 5. Table 1: Project plan for session 5.

Build tightrope platform


For the tightrope platform we plan to make two raised wooden platforms that are connected with a piece of wood that has a narrow width but sufficiently long so as to resemble that of a circus tightrope as seen in figure 1.

A circus tightrope with two raised platforms to stand and turn and a tightrope in between. Figure 1: A circus tightrope with two raised platforms to stand and turn and a tightrope in between.

This is to be used to demonstrate the precision of our PID-controller for the line follower robot using the NXT camera at the same height as it would be if mounted on Max. The narrow part of our tightrope is ~15cm which is 1cm extra on either side of the robot’s wheels.


We will not be doing any experiments for this part.


No programming is needed for this.


As seen in figure 2 we have made the base of our tightrope platform, which has been assembled and had its holes from screws filled for a smooth finish.

Filling the last holes in the assembled track. Figure 2: Filling the last holes in the assembled track.

We then sanded it down and painted it white as shown in figure 3. We now wait for it to dry so we can paint a sharp, black line for our robot to follow.

Freshly-painted tightrope. Figure 3: Freshly-painted tightrope.

Make camera tightrope rider


We still want to demonstrate the fact that it is possible to create a tightrope-moving, line-following robot that can use a camera mounted ~25cm in the air. For this, we will create a small robot for following the tightrope. This, however, requires a small center of rotation in order for the robot to turn on the spot when reaching the end of the tightrope, which we will look into in this part of the report.

Note that this is being done concurrently with the balancing improvement on our main robot, Max N00b.


For this particular experiment, we will still use the Vision Subsystem v4 for NXT or EV3 camera and code that it was used in the previous session, but we want to create a robot with a smaller circle of rotation so it will not take too much space when turning around once it has reached the end of the tightrope.

In the previous session we used a PD-controller to make the robot follow the line, but this time we will implement an actual PID-controller instead in order to get a higher precision. We need this higher precision to ensure that the robot will not fall off the tightrope, as a larger precision can decrease oscillation of the robot.


In this experiment we have created a PID-controller for improving the precision of the robot’s driving. The following code snippet is the PID-controller for the tightrope driving robot.

while (true){
  lineCenterX = (float) cam.getCenterX();
  error = lineCenterX - desiredPos;
  intError += error;
  derivativeError = error - lastError;

  power = (kP * error + kI * intError + kD * derivativeError) / scale;
  lastError = error;

  car.forward((int) (baseSpeed-power), (int) (baseSpeed+power), false);

As can be seen, where we earlier used the PD control and the values from the camera, we basically do the same again this time except the fact that we have added kI * intError. The use of kI has been discussed thoroughly in lesson 4.

The calibration to the PID-controller was done using the line follower PID-calibration program that we will discuss later in this session to fine tune the variables and make it possible to repeatedly travel a straight line with high precision and then turn 180 degrees at the end of the line.

Even though this is being done on a different track from our final track, getting the basis will allow us to quickly adapt it to the slight changes that the new track will require. The code for the line follower implementation can be downloaded here. The GUI discussed later is necessary for the program to run because it requires a bluetooth connection to run, and for the PID controller to på calibrated.


We have created a robot with a smaller circle of rotation than the one constructed in session 4, as seen in figure 4. Furthermore, we have also made a slight angle to the camera’s vision in order to make sure that the camera does not register its own body but only the line that we draw on the surface.

Tightrope-driving robot. Figure 4: Tightrope-driving robot.

One of the main improvements to make sure that the robot can turn in a small circle of rotation, is using the EV3 Ball Caster, as shown in Figure 5. By using this, the robot can easily turn around itself with minimum friction.

Tightrope walking robot with the EV3 Ball Caster attached to the bottom. Figure 5: Tightrope walking robot with the EV3 Ball Caster attached to the bottom.

It was also possible to make the robot follow a line by using the camera alone, as seen in this video. Now we just need to finish our tightrope platform so we can test demonstrate how amazing the camera is when used as a line following “sensor”.

Implementation of bluetooth communication


In lab lesson four and five we worked with bluetooth communication for live calibrating our PD and PID Controllers which we will use again although we plan to implement a more advanced modified version of this code. We plan to modify the code to handle the fine tuning of two PID control variables; one for balancing and one for camera line following. We also plan to use the bluetooth communication in a later session to control the movement of Max.


This is mainly a programming exercise but we will make some experiments to determine the range of the bluetooth hardware. We will focus our experiments to the environment of the Zuse building, because this is where we will be doing our presentation.

We will set up an experiment where we measure the distance at which Max and the computer connected lose connection and disconnect. We will do this in different directions to see if there is some difference or if other objects interfere with the bluetooth signal.


The main part of implementing bluetooth is using the NXT libraries for communications. We have made a class which we can utilize every time we want to communicate via bluetooth. This class offer methods for sending types of string, int, float, and boolean. This makes it easy for us to use it in different programs. The implementation used in the test program is shown below

public void startConnectThread(){
  Thread connecting = new Thread(new Runnable() {
    public void run() {
      while(state == RUNNING){
        }catch (Exception ex) {}

This code will constantly send a boolean true to the NXT. The code receiving this on the NXT is showed below.

Thread calibration = new Thread(new Runnable() {
  public void run() {
    while (running){
      try {
        currentTime = System.currentTimeMillis();
        if(dis.available() > 0){
          communicating = dis.readBoolean();
          lastMessage = currentTime;
        }else if(currentTime > lastMessage+messageDelay){
          communicating = false;
      }catch (Exception e){}

When it stops receiving, the code will make it begin to play a sound because the connection is lost. The sending and receiving is done in its own thread to ensure that there is not another method blocking it. We use the same approach in our communication with Max but we send strings containing JSON data instead of booleans.

Two screenshots of the interface is shown below in figure 6, to the left the interface unconnected and to the right the program connected and sending.

GUI for bluetooth connection testing. Figure 6: GUI for bluetooth connection testing.

The Lejos NXT program used can be found here. The source for the Java program can be found here.


We have run some tests in the Zuse building to see how the range of the bluetooth connection proforms. We started by putting the laptop in the middle of the room and then walk around with the Beast (an NXT named Beast). We were able to cover almost all of the Zuse building and it was only the last 1-2 meters from the corners we were unable to maintain the connection. We also tried putting the laptop in the “lego storage room” to see the maximum connection we could achieve. With this setup we were able to make a connection in the full length of the Zuse building.

This was a surprising result as the Lego NXT is only rated at 10 meters at best, and we were at some point getting more than twice of that. This is because the bluetooth in the laptop is class 1 rated which offers up to 100 meters of range. This combination of an NXT and a laptop offers a boost to the NXT’s range. Another test with other bluetooth devices can be found here.

The conclusion of this small experiment is that the range of bluetooth is sufficient for our purpose.

Implementation of calibration program


To perform live calibration of our two PID Controllers we will use a more advanced modified version of the calibration program used in lesson 5. We plan to modify the code to handle the fine tuning of two PID control variables; one for balancing and one for camera line following. We also plan to use this GUI controller in a later session to control the movements of Max.


Since this is purely programming, we will not be doing any experiments other than confirming that the calibrations are executed correctly.


Our new GUI is conceptually the same as the one in lesson 5 but has a series of improvements and enhancements which are as follows:

  • A change log
  • Save user preferences
  • Multiple taps of control
  • Dynamic communication using JSON
  • Clear log and preferences

The change log is a PrintWriter that appends the current values of a PID into a txt document located at the root of the program. This secures that if something should go wrong there will always be a saved version of the last settings. The user preferences contain the variables of the PID controllers, and the settings in the program such as NXT name and address. This makes it possible to close the program and continue the calibration later. Having multiple tabs for the different controls, makes it easy and accessible to change the different PID controllers as well as for assuming direct control of Max. Changing the communication between the computer and the NXT to use JSON means that it now only sends the changes that are needed, minimizing transfer time compared to previous versions but also allows for a multitude of commands to be implemented. Finally, to clean up before or after a calibration, there are implemented “clearing functions” that clears the users preferences and another for clearing the log file.

The GUI itself was created using a GUI Builder plugin for eclipse called WindowBuilder Pro which can be found here. We decided to use this builder since writing it hand would take more time then we have to spare and also as there is nothing to gain from writing it in hand.

The change log is made by creating a PrintWriter and then appending the values of the PID controller followed by a close command to the writer as seen in the following code snippet:

try {
  writer = new PrintWriter(new BufferedWriter(new FileWriter(FILENAME, true)));
  writer.println("----- BalancePID -----");
  writer.println("-Kp:              "+kp);
  writer.println("-Ki:              "+ki);
  writer.println("-Kd:              "+kd);
  writer.println("-BaseMPower:      "+baseMotorPower);
  writer.println("-Scale:           "+scale);
} catch (IOException ex) {}

An example of how the previous code snippet for the logging changes will look is as follows:

----- BalancePID -----
-Kp:              6.0
-Ki:              10.0
-Kd:              4.0
-BaseMPower:      75
-Scale:           1.0

For building JSON elements that we can send between the computer and the NXT we used a JSON library found in a forum which was adapted from Java ME, that can be found here. Since this all came as source code meant that we would have to include all the classes in our projects. This made us compile the JSON library to a jar file which just could be included as an external library instead allowing for cleaner code. The compiled JSON library jar can be found here.

The communication is gained using the same NXT connection as used in lesson 5 but instead of sending all of the variables individually from this connection it now only sends the JSON element as a String to the NXT as seen in the following code snippet.

JSONArray changes = new JSONArray();
float kPValue = new Float(balanceKpField.getText());
float kIValue = new Float(balanceKiField.getText());
float kDValue = new Float(balanceKdField.getText());
int baseMotorPowerValue = new Integer(balanceBaseMotorPowerField.getText());
float scaleValue = new Float(balanceScaleField.getText());

if(kPValue != balanceKp){
  JSONObject change = new JSONObject();
  change.put("name", BALANCE_VALUE_KP);
  change.put("value", kPValue);
if(scaleValue != balanceScale){
  JSONObject change = new JSONObject();
  change.put("name", BALANCE_VALUE_SCALE);
  change.put("value", scaleValue);
if(changes.length() <= 0){

JSONObject settings = new JSONObject();
settings.put("method", "balancePIDChange");
settings.put("changes", changes);
writeBalanceSettingsChange(kPValue, kIValue, kDValue,
  baseMotorPowerValue, scaleValue);

To make it easier to use the calibration program we made an executable jar of our calibration program which can be found here. This allows us to use it without having to use command prompt and java commands and the source code or a Java IDE.

The source code for the program can be found here.

To communicate with Max we need a program to run that receives the commands and informs the correct classes of the change.

Using an observer pattern our BluetoothCom class informs the main class which in turn executes the commands as seen in the following code snippet.

public void updateBalancePID() {
  boolean[] changes = BTC.isBalancePIDChanged();

As seen in the code snippet, our main class overrides the updateBalancePID method from the observer interface which is called whenever the bluetooth communication class notifies its observers of a change in the balance PID values.

To receive all of the commands from the PC, the bluetooth communication class runs a thread which only purpose is to listen for new commands, and then decode the method that should be used and pass it on to the correct method for processing. This can be seen in the following code snippet.

  settingsJson = new JSONObject(dis.readUTF());
  method = settingsJson.getString("method");
  }else if(method.equalsIgnoreCase("lineFollowPIDChange")){

The BluetoothCom class and CalibrationObserver interface can be found here.


As seen in figure 7 we have created a GUI for calibrating our two PID controllers both completely similar in design, so only the values and settings differ.

Calibration GUI for balance PID controller. Figure 7: Calibration GUI for balance PID controller.

We also made the GUI for the remote control but we did not implement the functionality on the NXT as of yet. As can be seen in figure 8, we have mapped the buttons to actual keys on the keyboard, so we can control him by using controls as if it was a video game.

Simple movement control GUI for Max. Figure 8: Simple movement control GUI for Max.

We will in a later session implement the JSON Commands on both the PC and NXT version for remote controlling the movement of Max as this is not needed at the moment.

Calibrate PID control


In this exercise we will calibrate our PID control to see if we can make Max balance on the ball. For this we will make a make some safety measures and afterwards adjust the Proportional, Integral and Derivative constants while Max is running the ball balancing software.


We will simply run the ball balancing program on Max while he is placed on the ball. From there, the proportional constant will first be adjusted until it keeps balanced with an acceptable oscillation. Afterwards, the integral, derivative and scale constants will be added in the adjustments. These constants will then be adjusted until Max can balance by himself with little to no oscillation. The adjusting will also be done through the use of the earlier implemented calibration program which will send the changes in the constants to Max via bluetooth.

Max fastened with his safety rope. Figure 9: Max fastened with his safety rope.

As seen in figure 9, throughout the whole test Max will have a thin rope tied to him in one end, while the other end is tied to a table above him. This will work as a safety rope, so when Max tilts he will not be able to completely fall off the ball. This will save us time to put him up several times and we only need to figure out the PID constants according to when Max tilts only a little from the desired angle.


Since all the necessary programming was made in the previous exercises, no programming is needed for this exercise.


As seen in this video, even with the safety rope and with the adjustments on the PID constants, Max was not able to get and maintain balance on the ball for more than one or two seconds, when in balance. Even getting him to balance was a very rare occasion.

With this failure we took a took a step back looked for inspiration in two other ball balancing robot project papers, namely Bjärenstam & Lennartsson and Fankhauser & Gweder. Since both their projects take a many things into account when making and programming a ball balancing robot, two specific thing seem to stand out. The first is their descriptions of the theory on the inverted pendulum, which the which Max actually is, and the method for measuring more accurate data with the gyro sensor and the accelerometer with a complementary filter.

For the theory of the inverted pendulum the robot’s from the to earlier mentioned projects seems to be higher in ratio to the robot’s width, while Max is rather low. We will therefore in a following exercise look into the theory of the inverted pendulum and see if the height, among other factors, of Max can have an effect on why he cannot balance.

With the complementary filter, the earlier mentioned projects mentions that the are some implication only using an accelerometer to measure data, but there are also implication with using the gyro sensor. Bjärenstam & Lennartsson mentions using a complementary filter, but does not explain the theory of in desired detail. So we will therefore in a following exercise research into the complementary filter to understand its theory, and thereby its benefits, and implement it to our balancing program.

Research on the inverted pendulum theory


Through an earlier experiment on calibrating the PID controllers variables, it seemed as if no matter how much tuning was done, Max could not stand upright and would quickly fall of the ball.

We will therefore take a step back and look into the theory of the inverted pendulum and its various relations to see if there is a way to make another construction of Max’s body that will aid him in keeping a better balance. For this, we have made a few questions that we need to answer in order to achieve better balancing.


  • What is the relation between the mass of the end point and the base?
  • What is the relation on the length between the end point and the base?
  • How are the these two relations connected in the reverse pendulum?


To actually investigate this, we tried looking up more information on the internet. Furthermore, we used our network and got to talk with a physicist about the different relations in the inverted pendulum. She explained that we need to look further into the center of mass.

Center of mass considerations

In context to improving the reaction speed of Max it is relevant to discuss the position of the center of mass. This can be understood by considering the following system; the inverted pendulum on a cart. The system can be directly generalized to 3 dimensions. The system is displayed in figure 10.

Max fastened with his safety rope. Figure 9: Max fastened with his safety rope.

The system consist of a mass m mounted on a (massless) rod with length l, which is attached to a cart. When the mass is displaced an angle , the cart will experience a force F in the opposite direction. In our case, the mass and rod is Max and instead of a cart, the force is exerted on a ball, which is not attached to the system. In order to describe this force, we utilize the Lagrangian of the system

which consists of the total kinetic energy of the system minus the potential energy in the system. In our case, this becomes

which, when expressing this in terms of the horizontal displacement x and the angular displacement , becomes

We then utilize that the force exerted on the ball is described by the equation of motion

which with the Lagrangian inserted becomes

or, expressed only in terms of angular velocity and angular acceleration

From this, it can be clearly seen that the force exerted on the ball greatly depends on the length of the rod l. As an example, choosing a mass of 1 kg and a displacement of 10 degrees, we get (in arbitrary units)

for a rod of length 10 cm and

for a length of 20 cm.

That is, only by doubling the length of the rod, the force exerted on the ball is multiplied by ten. Or, alternatively, it requires a smaller angular displacement to exert the same amount of force.

Furthermore, in order to determine how the force is affected by the mass, we now fix the length of the rod at 20 cm and instead vary the mass. Firstly, maintaining the initial mass of 1 kg, the force becomes

whereas it when the mass is doubled, becomes

From this it immediately seen that the force exerted is directly proportional to the mass.

In context to Max, we immediately conclude that by raising the center of mass, or, alternatively increase the mass, the angle adjustment which must be performed in order to maintain balance becomes correspondingly smaller. That is, by raising the center of mass, adjustments can be performed much quicker. For this reason, we will rebuild Max in the next session.




We will now answer our questions stated earlier:

Question: What is the relation between the mass of the end point and the base? Answer: When the mass is displaced an angle, the ball will experience a force in the opposite direction. As we found through calculations, doubling the mass will double the force, showing there is a direct proportional relation.

Question: What is the relation on the length between the end point and the base? Answer: The aforementioned force on the ball will depend greatly on the length between base and end point. As we found through calculations, doubling the length will multiply the force by ten.

Question: How are the these two relations connected in the reverse pendulum? Answer: This means that if we raise the center of mass, the angle adjustment for maintaining balance can be performed much quicker.

To conclude, this means in order to improve Max’s chance of balancing, we will rebuild his construction and attempt to raise the center of mass by constricting a higher robot.

Define and implement complementary filter for the PID controller


In this exercise we will look into the definition of the complementary filter, which has been used in another robot balancing related project by Bjärenstam and Lennartsson. We will look into the theory behind the filter and how it will benefit us in making Max better at balancing. Afterwards, we will implement our own version of the filter to be used together with the PID controller.


For the first part we will do some research on the theory behind the complementary filter and how it benefits to Max’s balancing abilities. Then we will try to implement a complementary filter for the PID controller.


For the implementation of the complementary filter two lines of code defines the rest of the code that must be implemented.

yXAngle = alpha*(yXAngle+yXGyroAngleVelocity*deltaTime)+(1-alpha)*yXAccAngle;
zXAngle = alpha*(zXAngle+zXGyroAngleVelocity*deltaTime)+(1-alpha)*zXAccAngle;

In the code snippet above, the two lines are basically the complementary filter for the angles of the tilt on each plane, yXAngle for the tilt on the Y-axis and X-axis and zXAngle for the tilt on the Z-axis and X-axis, and deltaTime is the time for each loop to complete. Since the accelerometer can take measurements 100 times per second, the deltaTime is given as a 10 miliseconds constant.

Since the filter is using measured angles from the accelerometer, the accelerometer behavior class is implemented with a few lines of code to measure these angles, as shown in the code snippet below.

double radian1;
double radian2;
radian1 = Math.atan2(yValue-yOffset, 1-xValue);
yXAngle = Math.toDegrees(radian1);
radian2 = Math.atan2(1-(zValue-zOffset), 1-xValue);
zXAngle = Math.toDegrees(radian2);

With the implemented complementary filter, the PID controller handles angle as an input instead of the earlier acceleration. However, we speculate this to be a better solution. Other than the above mentioned implementations, there are no other major changes to the code since the methods for calculating the projected errors for each motor are still usable with the angles of tilt.

The code for making Max “balance”, which includes the complementary filter can be found here.


To make Max balance some input is needed. In our case we have the possibility to use either Max’s two gyroscopes or the three axis accelerometer. However, in the guide to make, what the author calls, a Seg…stick, either type of sensors has its implications.

The accelerometer does not seem to be very good when it comes to sudden changes. This is due to the fact that the accelerometer is very susceptible to external forces and that it cannot distinguish between the force of gravity and the force of being in motion. However, in step 9 of the guide it makes a statement that “[when] Taking a long-term average, though, the only ‘acceleration’ that remains is gravity.” Therefore the accelerometer is still useful for long-term angle averages, but is not really efficient when having quick changes..

The gyroscope itself is good for short-term angle averages which are very accurate and not susceptible to external forces, unlike the accelerometer. However, to measure the angle, the gyroscope’s angle velocity (degrees per second) times the times between each measured velocity and gives an incremental change in the angle. If the measurements from the gyro sensor is not exactly zero while Max is standing completely horizontally, which the author of the Seg…Stick say it will never be, it will cause the integration of the gyro sensor to drift. This means that the gyro sensor does not work for long-term angle averages.

This is where the complementary filter comes in.

angle = alpha*(angle+gyroAngularVelocity*dt)+(1-alpha)*accelerometerAngle

The formula above is the formula of the complementary filter from the Seg..Stick guide that is modified to fit with our PID. Since we before did not have a method to measure the accelerometers angle, this then been implemented in the Accelerometer behavior class. This formula will help give a more precise estimate of the angle by using both the accurate short-term angle average from the gyro sensor and the long-term angle average from the accelerometer. The way this is done is by giving a value for alpha. Alpha, which is always between 0 and 1, determines how much of the time the gyro sensor is trusted and thereafter filtering in the accelerometer. An example will be that if alpha is 0.98, then for every time the the angle shall be measured, 98% of the measurement is from the gyro sensor and the last 2% are from the accelerometer.

A complementary filter has been implemented into our PID control. Snippets of the implemented code and links for the implementations can be found in the programming section.



We had some serious problems with the NXT Camera which was caused by the NXT camera for no apparent reason tried to reinstall its own firmware. This made the NXT unable to connect with the camera and receive data.

To correct this we had to go through a series of steps which are as follows:

  1. Make sure to have installed NXTCamView and all needed USB drivers described in the guide found here.
  2. Install the enhanced LEGO Brick firmware version 1.29 which can be found here by doing the following steps, described in the guide found here:
  3. First we need to have installed LEGO Mindstorms NXT V2.0 which can be found here.
  4. Open the application and select Tools→ Update NXT Firmware.
  5. Selecting the firmware download in step 2.
  6. Connecting the NXT via USB and press Download.
  7. Download the firmware upgrader application from here.
  8. Get the following three files: nxtcam-settings.rxe; nxtcam_AVRbootstrap.hex and nxtcam_def.hex, which according to the original guide from mindsensors is done by writing the [email protected] E-mail and asking for them.
  9. Install the nxtcam-settings.rxe application on the NXT through these step, as described in the guide found here.
  10. Open the NXT window found in the lower right corner of the LEGO Mindstorms NXT V 2.0 application.
  11. Open the Memory tab.
  12. Press the download button and select the nxtcam-settings.rxe file.
  13. Retrieve the hardware settings from the NXTCam doing the following steps:
  14. Attach the NXT Camera to sensor port 1 of the NXT.
  15. Run the nxtcam-settings.rxe program on the NXT.
  16. Write down the value displayed; for example Current Value:57.
  17. Close the application.
  18. Now we can restore the AVR firmware via the PIC processor by doing the following steps, as described in the guide found here.
  19. Exit all applications that can connect with the NXT so not to cause connection issues while installing the new firmware.
  20. Make sure the NXT is turned off and connected via USB.
  21. Run the Firmware Upgrader application downloaded earlier.
  22. Turn on the NXT.
  23. Select: Device→ Select Device Type→ NXTCam.
  24. Select: Device→ Open Firmware hex file→ select nxtcam_AVRbootstrap.hex.
  25. Select: Device→ Upgrade Device.
  26. Within 10 seconds connect the NXTCam to sensor port 1 and if already connected then disconnect and reconnect it within the time.
  27. Then wait for the process to complete which is around the time it gives a device checksum error which is to be ignored.
  28. Wait ~45 seconds.
  29. Disconnect the NXTCam from the NXT.
  30. Close the Firmware Upgrader application.
  31. Power off the NXT.
  32. Reconnect the NXTCam to the NXT while the NXT is powered off.
  33. Power on the NXT and wait for it to apply the firmware update which takes ~30+ seconds.
  34. We can now restore the PIC Firmware by doing the following steps:
  35. Do the same as in 7.a → 7.i BUT selecting the nxtcam_def.hex file instead of the nxtcam_AVRbootstrap.hex.
  36. Power off the NXT.
  37. Disconnect the NXT Cam.
  38. Now we only need to restore the hardware settings that we retrieved earlier doing the following steps:
  39. Attach the NXTCam to sensor port 1.
  40. Run the nxtcam-settings.rxe application.
  41. Use the gray arrow keys to select the correct value.
  42. Press enter to select and save the correct value.
  43. The NXTCam should now be ready to use which is confirmed by running the NXTCamView application and capture an image from the camera.

Other walkthroughs of this process can be found in an unofficial version here and the official version here. All the needed guides, applications etc. can be downloaded from here.


We have in this session constructed our tightrope platform as well as a robot to ride it. Furthermore, we have found that using reverse pendulum theory for making Max balance might assist us in achieving this. For this reason, we are now ready to rebuild Max and move his center of mass to a higher position, while at the same time get ready to calibrate our PID controller. We have, however, started getting serious doubts that we will actually manage to make Max balance on the ball. This is because of the LEGO system in which he is constructed that might not be suitable for such a type of ball balancing robot, but instead more small and simpler types as for example the one found here. We will reflect on this further in a later session.