Installation Issues

The PicoBorg Reverse and DiddyBorg are both compatible with the Raspberry Pi v2, we have tested them both.

I have added a more complete listing of what we did to setup the Raspberry Pi v2 to run DiddyBorg on the other thread:
https://www.piborg.org/comment/696#comment-696

It sounds like the PicoBorgRev.py file has been altered or corrupted in some fashion.

The second line of the file should be:
# coding: latin-1
which declares the file encoding.

The character it mentions is the ² symbol, which it cannot understand without the encoding.
You could try adding the coding line back in to the file so that the first few lines of the file read:

#!/usr/bin/env python
# coding: latin-1
"""
This module is designed to communicate with the PicoBorg Reverse

Alternatively you can re-install the DiddyBorg software.
This can be done as follows:

cd ~/diddyborg
rm examples.zip
wget http://www.piborg.org/downloads/diddyborg/examples.zip
unzip -o examples.zip
chmod +x install.sh
./install.sh

I think this is because the scripts are trying to use the wrong I2C bus for your Raspberry Pi.

By default the scripts try looking for the PicoBorg Reverse on i2c-1, then if they cannot find it they try i2c-0.

Try changing line 194 in PicoBorgRev.py to be:

    busNumber               = 0

This should make the script try i2c-0 before i2c-1.
Since all of the examples use PicoBorgRev.py it should fix all of them.

i2c-1 is listed, but not i2c-0.

I think you need to change the bus selection line (194) back to using bus 1:

    busNumber               = 1

This should make the script try i2c-1 before i2c-0.
This is the default setting after installation and is correct for most Raspberry Pis.

It sounds like the I2C is not correctly setup.

Could you try enabling the I2C using raspi-config as described here:
https://www.piborg.org/comment/688#comment-688

Since the I2C bus number has changed between the last time you had this working and now I am guessing that you have done one of the following recently::

1. updated or reinstalled Raspbian
2. changed your Raspberry Pi for another one
3. changed to a different Linux distribution

Could you tell us what was changed before the problems occurred?
The more information you can tell us the quicker we can get your robot working again ^_^

The most likely explanation is that the wires are not connecting with the PicoBorg Reverse properly.

Could you try the following:

1. Run sudo i2cdetect -y 1 and show us the result
2. Check the wiring matches the instructions:
   For PicoBorg Reverse: see the diagram below the connections heading.
   For DiddyBorg: see Step 44 - First cable attached to the PicoBorg Reverse to Step 49 - Checking the cable connections
3. Check the cables make a nice firm fit, they should not be loose in any way
4. If you have a multimeter check the cables are okay (all six pins)
5. If you could take some photos of the connections on both the PicoBorg Reverse and the Raspberry Pi it would help

So the only problem is that the board does not show up on the I2C bus at all...
We also know the board was working with the previous Raspberry Pi.

Does the LED on the PicoBorg Reverse come on briefly when you connect power to the Raspberry Pi?

If you now have a Raspberry Pi 2 then you should download the new SD card image as stated here: http://www.raspberrypi.org/raspberry-pi-2-on-sale/
You can grab the latest Raspbian image here: http://www.raspberrypi.org/downloads/
Then re-install the PicoBorg Reverse software and try again.

Could you try connecting the PicoBorg Reverse to the old Raspberry Pi and running these two commands:
sudo i2cdetect -y 0
sudo i2cdetect -y 1

It seems like the board is not working on either Raspberry Pi at this point.

Since the LED comes on the board is loading correctly, it should be ready when the LED has turned on and off again.

The most likely explanation is that the cables are not connecting properly, meaning the I2C communications do not work as intended.

I think the best solution is for us to send you out some new cables to replace the current pair.
Could you please use the contact form to tell us what address to ship the replacement cables to?

You do not actually require all six connections for PicoBorg Reverse.

The only connections you need are:

• 3v3 - pin 1
• SDA - pin 3
• SCL - pin 5
• Ground - pin 6

3v3 and Ground are used for powering the on-board control chip.
SDA and SCL are used for the I²C communications.

I have attached a diagram below to show the connections.
As long as the daisy chain connector is either unused or connected to a PicoBorg Reverse there should be no need to connect pins 2 and 4.

If you are referring to the red triangle next to the 5-pin header, it is intentional.
The triangle marks which pin on the 5-pin header is pin 1.

Now that we are sure this is definitely not a cable problem, there are only two remaining possibilities I can think of which explain the problem:

1. Something is wrong with the software on the Raspberry Pi, preventing the I2C working
2. The PicoBorg Reverse has damaged I2C connections

If you could try the following to see if software is the problem:

1. Download a copy of the latest Raspbian image here
2. Write it to an SD card, ideally a new one if you have any
3. Boot up the Raspberry Pi with it in
4. Enable the I2C in raspi-config when the screen appears
5. Follow the PicoBorg Reverse software installation instructions
   Do not install any other software
6. Reboot the Raspberry Pi
7. Run sudo i2cdetect -y 0
8. Run sudo i2cdetect -y 1

In that case the most likely explanation is that the PicoBorg Reverse is actually faulty.

If you could send us back the faulty board and we will send you out a replacement.
I have sent you an email to give you our address and check we have the correct address for you.

Apologies for how long this has taken to solve.

What version of Raspberry Pi are you using?

Have you tried enabling I2C in raspi-config, you can do this using these instructions:

1. Enter the following command in a terminal: sudo raspi-config
2. Move down to option 8 Advanced Options and press ENTER
3. Move down to option A7 I2C and press ENTER
4. Make sure Yes is highlighted and press ENTER
5. When the dialog says I2C is enabled press ENTER
6. Make sure Yes is highlighted again and press ENTER
7. When the dialog says I2C will be loaded by default press ENTER
8. Move right until Finish is highlighted, then press ENTER

If this is an older Raspberry Pi (such as a B rev 1) you might need to change the I2C bus in the PicoBorgRev.py script.
You will find this file in ~/picoborgrev, if you have a DiddyBorg it also needs to be changed in ~/diddyborg.
The line you want to change is line 194 in PicoBorgRev.py so that it reads:

    busNumber               = 0

If the line already uses 0 then try 1 instead.

Does either motor move if you run the following:

import PicoBorgRev
PBR = PicoBorgRev.PicoBorgRev()
PBR.Init()
PBR.ResetEpo()
PBR.MotorsOff()
PBR.SetMotor1(0.9)
# Wait to see if motor #1 moves
PBR.MotorsOff()
PBR.SetMotor2(0.9)
# Wait to see if motor #2 moves

It is possible that your battery supply is too close to the 6v minimum power requirement.
The PicoBorg Reverse has on-board protection which turns the motors off in the event the power is too low.
Some boards can be a bit more sensitive then others.

If you are using rechargeable AAs then you should use a minimum of 5 batteries, we would recommend at least 6.
Also if you are using any kind rechargeable batteries it may be they are getting a bit flat, try charging them fully and see if the problem is resolved.

We did receive the original board you sent back, it seems to be completely fine.

It is possible that having swapped over cables would cause the BattBorg to push 5v to both the 3v3 line and one of the serial lines, causing damage.
Alternatively if you are not using a BattBorg you may have damaged one of the serial lines by connecting it to ground with swapped cables.

It does seem likely the Raspberry Pi has a problem at this stage, so testing the GPIO pins would be a good idea.
If you have any LEDs and resistors you can do this by testing you can control each pin manually.

First disconnect anything attached to the GPIO.
Next wire up an LED & resistor between the 3v3 and a ground pin, this should turn on when the Raspberry Pi is powered.
If that is working attach the LED & resistor between a GPIO pin and ground, you will want to test pin 3 (SDA) and pin 5 (SCL).
Use some software to change the output value of the GPIO pin, you should be able to control the LED if all is well.

You can see the GPIO pin layout here: http://pi.gadgetoid.com/pinout
This guide is good for attaching LEDs: https://projects.drogon.net/raspberry-pi/gpio-examples/tux-crossing/gpio...

I think this is probably due to the different pin numbers used with the Raspberry Pi.

Try this python code for toggling both the pins:

import time
import wiringpi2 as wiringpi
wiringpi.wiringPiSetup()

PIN_SDA = 8
PIN_SCL = 9

wiringpi.pinMode(PIN_SDA, wiringpi.GPIO.OUTPUT)
wiringpi.pinMode(PIN_SCL, wiringpi.GPIO.OUTPUT)

print 'Press CTRL+C to exit'
while True:
    wiringpi.digitalWrite(PIN_SDA, 1)
    wiringpi.digitalWrite(PIN_SCL, 1)
    print 'LEDs ON'
    time.sleep(1)
    wiringpi.digitalWrite(PIN_SDA, 0)
    wiringpi.digitalWrite(PIN_SCL, 0)
    print 'LEDs OFF'
    time.sleep(1)

You can install WiringPi 2 using these commands:

sudo apt-get update
sudo apt-get -y install python-dev python-setuptools
sudo easy_install wiringpi2

Then the script should work as intended.

It sounds like the SCL pin may be damaged then.

Based on the description of the problem I am guessing there is a small amount of control electronics within the motor / gearbox assembly.
This is a common practice if they are using a brush-less DC motor (BLDC) and want to simply connect a + and - connection to it.

I am assuming that the other DC motor is just a simple motor with no gearbox assembly.
Some pictures of both motors and how they are connected would help clarify if I am correct or mistaken.

The way PicoBorg Reverse controls speed is to turn the output on and off at high speed, a technique known as PWM.
With a conventional DC motor the voltage gets smoothed out to a steady level and turns as though the average voltage was applied.

If this motor does have electronics inside it then using PWM presents a problem.
What now happens is that the electronics in the motor draw their power from the output, which is regularly turned off.
The electronics in the motor turning on and off at about 8 KHz is then causing the audible buzzing instead of rotating the motor.

There are two possible ways we can try and work around this, assuming the PWM itself is the issue.

Method 1 - other connections

If there are any connections other than the + and - to the motor it may be possible to connect the motor in a way that will behave as intended.
This will depend entirely on what connections are available.

Method 2 - smooth the voltage

Instead of relying on the motor to smooth out the voltage we can perform the smoothing externally.
This page explains PWM in more detail, and how you can use a resistor and capacitor to smooth out the voltage:
http://provideyourown.com/2011/analogwrite-convert-pwm-to-voltage/
I think a resistor between 1 and 10 KΩ and a capacitor around 1.0 μF should work well enough.
Be sure the capacitor can handle the full battery voltage.
Finally make sure you connect the capacitor the right way around, otherwise it may blow up!

I am guessing the board that will not detect is the last one in the daisy chain, is that correct?

The most likely explanation is the problem board is not getting enough power.
This causes the board to continually attempt a restart, and each time it starts the LED blinks once.

There are a few possible solutions, depending on what you have available:

1. Try a different power supply, higher current ones are more likely to work
2. Try using shorter cables between the boards, this should reduce the amount of power lost over the cabling
3. Try using fatter cables between the boards, this should also reduce the amount of power lost over the cabling (fat and short will probably work best)
4. You could try connect a power source (such as BattBorg) directly to the last board in the chain.
   DO NOT power the Raspberry Pi from the USB connector at the same time!
5. You might have more luck connecting each board in a shorter chain.
   For example using a TriBorg all three boards could be connected directly to the TriBorg instead of daisy-chaining them