Installation Issues

All of the instructions are up on this website.

We recommend you install the software first: software install instructions.
Once that is done proceed to the build instructions.

There are some extra bits of software you will want for talking to the Pi Camera:

sudo apt-get -y install python-picamera libcv-dev libopencv-dev python-opencv

You should be able to fix the easy_install error by installing it first:

sudo apt-get easy_install

Everything should work fine with Raspbian Lite, the code itself has been tested. We are only using easy_install to setup pygame, on recent versions of Raspbian pygame is already installed so the step is usually unnecessary.

Well the good news is that the motors are almost certainly fine. Even if they did get powered they should not have exceeded any electrical limits.

The bad news is that the ThunderBorg is almost certainly dead, most of the components do not like being reverse powered :( It is possible the the Raspberry Pi has taken some damage to the GPIO pins even if it does power up, but it may have escaped without problem as well.

It is fairly likely that everything will be fine if you replace the ThunderBorg with a new one. You can order them from our shop here.

On a side note it may be easier to connect your LiPo to the V+ and GND screw terminals on the ThunderBorg instead of the 9V connector. This should reduce the chances of making a polarity mistake on the 9V connector, but it does prevent the power switch from working.

It sounds like I2C is not enabled or has a different name on your Pi.

First I would check I2C is setup in raspi-config. You can do this by:

1. Enter the following command in a terminal: sudo raspi-config
2. Move down to option 5 Interfacing Options and press ENTER
3. Move down to option P5 I2C and press ENTER
4. Make sure Yes is highlighted and press ENTER
5. When the dialog says I2C is enabled press ENTER
6. Move right until Finish is highlighted, then press ENTER

After that re-run the ThunderBorg install script:

cd ~/thunderborg
./install.sh
sudo reboot

Hopefully the script will now be working correctly. If not run this command:

ls /dev

and post the results so we can take a look :)

This is a tricky question to answer, but put simply it basically does already.

I will try and explain by describing what happens in the situation where the front left wheel is on the ground and the rear left wheel is in the air.

The first thing to know is that both motors are connected in parallel. This means at 100 % power both the front left and rear left motors have the full 12 V from the battery provided. The current given to each motor depends on the resistance of the motor and the voltage. The total power (torque and speed) comes from the voltage and current multiplied together, giving a wattage.

The motors actually have the lowest resistance when the are completely stationary. In other words they draw more current when stopped compared to when they are moving. As the motor turns faster the resistance increases, lowering the current drawn by the motor. This is why the motors have a natural maximum speed when they are not attached to anything, they get to the point that the motor is not getting enough power to increase speed.

So to sum up the last two paragraphs the slower a motor is going the more current it draws from the battery. At the same time both motors must be at the same voltage because they are connected in parallel. Finally the power to each motor is equal to the voltage provided multiplied by the amount of current it is drawing.

So for our example:

1. The front left and rear left motors both have the same voltage, 12 V
2. The front left wheel has a large load (MonsterBorg weight on ground) and is spinning fairly slowly (maybe stopped)
3. The rear left wheel is free in the air and is spinning quite fast

This means the current to the front left motor will be much higher than the rear left. In turn as the voltages are the same this means the total wattage to the front left motor is higher than the rear left motor.

Since the power (wattage) is split between speed and torque what actually happens is that the front left motor has a large increase in torque compared the rear left motor, allowing it to keep turning :)

On a side note this is why it is not a good idea to connect motors in series. If you did that the voltage is split unevenly between the motors based on their resistance. In that case the free-wheeling motor would take nearly all of the power and the other one would not turn at all!

Hopefully that clears things up a bit :)

It sounds like the I2C signals are getting messed up at some stage and no longer get through. I2C connections can be difficult to debug so this make take a few tries to fix.

My first thought is that if you are running from batteries they may be getting low after the long run with the motor. This might be causing the 5V signal to the Pi to dip a bit low and in turn upset the I2C signals. If you are using a power supply make sure it has a high enough current rating to cope with all of the motors, power surges to all of the motors (stall currents), and powering the Raspberry Pi.

My second thought would be cabling, all of the following may help:

• Make sure the connections between pins and the wires are solid, poor connections could explain things.
• Use the shortest connections you can for the 6-pin connection. Longer cables have larger losses and pick up more noise.
• Keep the wiring away from motors, they like to generate electrical interference.
• Shielding around the cabling to block noise. Some tin foil could work here but make sure it cannot make electrical contact with anything.

I would check the supply first as it is the more likely issue and is easier to fix / change.

We have not tested the monsterWeb.py script on a Pi Zero W, however we have tested the yetiWeb.py script which is extremely similar.

In either case the script should not be able to cause such a crash on its own, there is probably something else involved.

Is the MonsterBorg moving when the Pi crashes, or is it stationary?

This can be tricky, there is not really a good simple way in this case. Hopefully some questions will shed more light on the problem.

1. What does the monitor show when the Pi has crashed?
2. Are the MonsterBorg motors moving when it crashes?
3. Are you powering the Pi zero from both the USB and the ThunderBorg?
4. Is anything happening at all once the Pi has crashed (e.g. flickering LEDs)?

The most likely explanation is that the script(s) you are running are still trying to talk to the default address, which is no longer valid.

You will need to setup the scripts to talk to the new addresses like this:

# Setup the library ready for use
import ThunderBorg

# Board #1, address 0B
TB1 = ThunderBorg.ThunderBorg()
TB1.i2cAddress = 0x0B
TB1.Init()

# Board #2, address 0C
TB2 = ThunderBorg.ThunderBorg()
TB2.i2cAddress = 0x0C
TB2.Init()

# Quick test to check can talk to both boards
TB1.SetLedShowBattery(False)
TB2.SetLedShowBattery(False)
TB1.SetLeds(1, 1, 0) # Yellow for address 0B
TB2.SetLeds(1, 0, 1) # Purple for address 0C
print TB1.GetLed1() # Should be 1, 1, 0
print TB2.GetLed1() # Should be 1, 0, 1

The standard BOB script (tbBob.py) sets the LED colour to blue at a regular interval while it is still waiting to get a connection to the gamepad / joystick. It is possible that something like this is still going on in the background and causing problems.

First I would check to see if you have any other scripts running in the background / on startup. If more than one script is trying to control the LED it will be unclear which one has control.

If you are not sure try running this command from a terminal:

sudo ps -A | grep python

If you see something like this:

pi@PiBorg-Stretch:~ $ sudo ps -A | grep python
  434 ?        00:00:04 python
pi@PiBorg-Stretch:~ $

it means there is a Python script already running. If you do not see any output then there are probably no other scripts running.

If you do have any scripts already running try terminating them with this command:

sudo killall -9 python

You can then try the tbLedWave.py script again and see if the LED now behaves.

If that does not work you can quickly check that the LED / ThunderBorg itself is working as follows:

1. Shutdown the Pi
2. Disconnect the battery / power
3. Wait for about a minute to let all the power drain
4. Reconnect the battery / power
5. The LED should quickly cycle these colours: red, green, blue
6. Finally the LED should go off and then switch to battery monitoring mode

If the LED changes colour again after that it would mean that there is a script running at startup which is controlling the LED colour.

It sounds like the LED on your ThunderBorg is probably faulty and will need to be replaced to make it function correctly.

If you can send the board back to us we will be happy to repair it for you :)

The address to send the board back to is:

Freeburn Robotics Limited
Unit 15, Earith Business Park
Meadow Drove
Earith
Huntingdon
Cambridgeshire
PE28 3QF
United Kingdom

Please include a note with the following details:

1. State that the board is being returned for repair
2. A quick description of the problem
3. The address to send the ThunderBorg back to when repaired

The installation command changed slightly when we moved over to our new shop site.

The correct installation command is now:

bash <(curl https://www.piborg.org/installer/install-monsterborg.txt)

You can find the up to date instructions on the site here.

When running the monsterJoy.py script the colours shown mean the following:

1. Red to yellow to green
   This is the normal battery monitoring mode that ThunderBorg defaults to (levels set by tbSetBatteryLimits.py). As it is showing red all of the time it means the ThunderBorg believes the batteries are low on power.
2. Blue
   The script shows blue while it is waiting for the joystick / gamepad to be connected. It may also briefly show when the script starts while it is setting up.
3. Purple
   This indicates that the ThunderBorg may have detected a power problem with the batteries or motors. Usually it is safe to ignore unless it will not turn off when the MonsterBorg is moving / trying to move.

Given the constant red from the battery monitoring and occasional fault detection I would suggest your batteries are flat and probably need to be recharged. If you try fresh rechargeable AAs remember that they generally require charging before use.

You can get the battery voltage by running these commands:

cd ~/thunderborg
./tbReadBattery.py

Another possibility is if any of the AAs are placed in the holder upside-down. Each AA should be inserted so that the flat end is pressed against the spring. If any are backwards they may have damaged the other batteries so it is safest to replace all of them. If any of them have leaked, look rusty, are covered in white power, or are an odd shape make sure to dispose of all of them as they are definitely damaged!

Good news, it looks like you are just missing a connection :)

The ThunderBorg needs to have a GND connection between the 6-pin header and the GPIO on the Raspberry Pi. Without it the two boards have a different voltage level for 0...

Any of the GND pins on the GPIO header will do. The pinout for the 6-pin headers on the ThunderBorg is:

Once that is connected make sure the script is set back to bus 1 and try again :)