It sounds like you are have trouble talking to the board based on previous messages.
I recommend we stick to solving this problem in a single forum thread to avoid any further confusion.
There are two ways we can try and see what is happening.
I suggest you try both and send us the results of all the checks.
1. Scan the I2C bus
This will help to see if there is a problem with the cabling or boards.
Try both of these commands:
sudo i2cdetect -y 0
sudo i2cdetect -y 1
What are the results from both?
2. Try to find the board from Python
This will find the board if it is all connected and working.
First go to the PicoBorg Reverse directory and start Python:
It looks like nothing is shown on the I2C bus at all.
Bus number 1 is the correct one for you to use, so make sure that is how the script is setup.
Based on previous posts (https://www.piborg.org/node/2225) it seems like this board was working correctly.
Has anything about the wiring been changed recently?
I know a few people have had some strange behaviors with flat batteries.
Can you try recharging / replacing the batteries to see if the problem goes away?
Can you attach some photos of how the PicoBorg Reverse is wired up to everything?
In particular the connections on the GPIO and the PiocBorg Reverse itself are of the most interest.
Unfortunately this makes damage to either the GPIO or the PicoBorg Reverse fairly likely now.
Put simply the GPIO pins are not designed to tolerate more than 3.3v and they have been accidentally connected to 5v comming from the BattBorg.
Do you have a different Raspberry Pi that could be used to check the PicoBorg Reverse on its own?
If the Raspberry Pi is working they should both change between 3.3v and 0v at one second intervals.
Anything else suggests that the pin measured is not working correctly anymore.
Unfortunately it looks like the GPIO pins are damaged on your Raspberry Pi.
It seems that both of the I2C pins are damaged, along with some others.
Unfortunately this means that the Raspberry Pi cannot talk with the PicoBorg Reverse anymore.
The only fix I can suggest to you is to replace the Raspberry Pi with a new one.
Given the damage caused I would suggest making a careful note of the correct way to wire the pins up for next time.
Hopefully the PicoBorg Reverse itself is undamaged and replacing the Raspberry Pi is enough to fix everything.
hello
I hope not so, but it is possible that the second PBR is also damaged, but not because of me. I was very careful and i connected it after i checked all wires (from you)...
So i don`t think that it is may fault...
It is very strange, because the led of the first PBR funktion when it starts, the led of the second PBR doesn`t funktion at all.
So what can i do?
I don`t want to order a third PicoBorg Reverse....
Hello
Only for testing i connected the Ultra Borg und sudanly the PicoBorg Reverse function normally... And it is the old one, not the new one!
Now i am totally confused but also happy that it function...
It is good to hear that the first PicoBorg Reverse is undamaged :)
Sorry for the confusion in the previous message, I did not know you were testing with a replacement board.
I would suggest the latest trouble was probably a bad cable.
Some of the three-pin cables do not make a good enough connection for the I2C to work, this is why we supply a spare.
The best thing to do is take some photos of how it is connected now that the board is working.
If you run into problems again you should be able to go back to the connections from the photos.
I would suggest you stick to using the cables that are working at the moment if you can.
As for connecting other bits I would recommend attaching one new thing at a time and make sure everything still works.
That way it makes it easier to figure out what the problem is when something stops working.
We do have an example, but it is very simple.
It only uses one sensor, but it should give an idea of how this can be used for more complicated tasks.
It is based on the ubServoFromDistances.py example, but sets motor speeds instead of servo positions.
The script below will attempt to keep the distance seen from ultrasonic sensor #1 around 200 mm.
It does this by setting the motor speeds faster / slower depending on how far away it is currently reading.
The same script is attached to the bottom of this post so that you can download it instead of having to copy it.
diddyFromDistance.py
#!/usr/bin/env python
# coding: latin-1
# Import the libraries we need
import UltraBorg
import PicoBorgRev
import time
import math
import sys
# Settings
distanceMin = 100.0 # Minimum distance in mm, corresponds to DiddyBorg reversing at 100%
distanceMax = 300.0 # Maximum distance in mm, corresponds to DiddyBorg driving at 100%
# Start the UltraBorg
UB = UltraBorg.UltraBorg() # Create a new UltraBorg object
UB.Init() # Set the board up (checks the board is connected)
# Setup the PicoBorg Reverse
PBR = PicoBorgRev.PicoBorgRev()
#PBR.i2cAddress = 0x44 # Uncomment and change the value if you have changed the board address
PBR.Init()
if not PBR.foundChip:
boards = PicoBorgRev.ScanForPicoBorgReverse()
if len(boards) == 0:
print 'No PicoBorg Reverse found, check you are attached :)'
else:
print 'No PicoBorg Reverse at address %02X, but we did find boards:' % (PBR.i2cAddress)
for board in boards:
print ' %02X (%d)' % (board, board)
print 'If you need to change the I²C address change the setup line so it is correct, e.g.'
print 'PBR.i2cAddress = 0x%02X' % (boards[0])
sys.exit()
#PBR.SetEpoIgnore(True) # Uncomment to disable EPO latch, needed if you do not have a switch / jumper
PBR.SetCommsFailsafe(False) # Disable the communications failsafe
PBR.ResetEpo()
# Power settings
voltageIn = 12.0 # Total battery voltage to the PicoBorg Reverse
voltageOut = 6.0 # Maximum motor voltage
# Setup the power limits
if voltageOut > voltageIn:
maxPower = 1.0
else:
maxPower = voltageOut / float(voltageIn)
# Calculate our divisor
distanceDiv = (distanceMax - distanceMin) / 2.0
# Loop over the sequence until the user presses CTRL+C
print 'Press CTRL+C to finish'
try:
# Initial settings
speed = 0.0
driveLeft = 0.0
driveRight = 0.0
while True:
# Read all four ultrasonic values, we use the filtered values so we get accurate readings
usm1 = UB.GetDistance1()
usm2 = UB.GetDistance2()
usm3 = UB.GetDistance3()
usm4 = UB.GetDistance4()
# Convert to the nearest millimeter
usm1 = int(usm1)
usm2 = int(usm2)
usm3 = int(usm3)
usm4 = int(usm4)
# Determine the speed of DiddyBorg based on the distance readings
if usm1 != 0:
speed = ((usm1 - distanceMin) / distanceDiv) - 1.0
if speed > 1.0:
speed = 1.0
elif speed < -1.0:
speed = -1.0
driveLeft = speed
driveRight = speed
# Set our new speed
PBR.SetMotor1(driveRight * maxPower)
PBR.SetMotor2(-driveLeft * maxPower)
# Wait between readings
time.sleep(.1)
except KeyboardInterrupt:
# User has pressed CTRL+C
PBR.MotorsOff()
print 'Done'
If you run this script and the WebUI at the same time you will not be able to control the robot from the WebUI.
This is because the script above is updating the motor speeds very often.
Most of our scripts are designed to be run individually, but some parts can be shared.
For example the camera output on the WebUI can be used in conjunction with any script that does not use the camera.
It might be worth asking bui_hong_phuc if he can upload his completed script.
I would reply to his It works like a charm comment and see if he is happy to share.
Bear in mind that his ultrasonic modules are mounted differently so the code will probably need adjustment to work with your robot :)
piborg
Thu, 09/08/2016 - 10:28
Permalink
Checking we can talk to the board
It sounds like you are have trouble talking to the board based on previous messages.
I recommend we stick to solving this problem in a single forum thread to avoid any further confusion.
There are two ways we can try and see what is happening.
I suggest you try both and send us the results of all the checks.
1. Scan the I2C bus
This will help to see if there is a problem with the cabling or boards.
Try both of these commands:
sudo i2cdetect -y 0
sudo i2cdetect -y 1
What are the results from both?
2. Try to find the board from Python
This will find the board if it is all connected and working.
First go to the PicoBorg Reverse directory and start Python:
Now try these commands in Python:
What are the results from both?
cocoda74
Thu, 09/08/2016 - 11:19
Permalink
Bus Number 1 or 0 it is the
Bus Number 1 or 0 it is the same problem!
piborg
Thu, 09/08/2016 - 13:41
Permalink
Board not shown
It looks like nothing is shown on the I2C bus at all.
Bus number 1 is the correct one for you to use, so make sure that is how the script is setup.
Based on previous posts (https://www.piborg.org/node/2225) it seems like this board was working correctly.
Has anything about the wiring been changed recently?
I know a few people have had some strange behaviors with flat batteries.
Can you try recharging / replacing the batteries to see if the problem goes away?
cocoda74
Thu, 09/08/2016 - 14:52
Permalink
Hello
Hello
Wiring hasn`t been changed!
Batteries are brand new!
Could it be that the Board is dead?
Greatings
piborg
Thu, 09/08/2016 - 15:15
Permalink
Troubelshooting
It is rather unlikely that the board has simply stopped working.
It is much more likely that something is causing a problem.
Is there anything else attached to the GPIO on the Raspberry Pi?
cocoda74
Thu, 09/08/2016 - 15:37
Permalink
no
no
piborg
Thu, 09/08/2016 - 15:57
Permalink
Wiring photos
Can you attach some photos of how the PicoBorg Reverse is wired up to everything?
In particular the connections on the GPIO and the PiocBorg Reverse itself are of the most interest.
Also do you have a multimeter?
cocoda74
Thu, 09/08/2016 - 17:14
Permalink
Shure
Hello
I have a multimeter!
piborg
Thu, 09/08/2016 - 17:40
Permalink
Incorrect wiring
The problem appears to be that the left and right cables are swapped over.
On the Easy Multiplexing Board you need to swap:
cocoda74
Thu, 09/08/2016 - 18:14
Permalink
Wiring solved, still not found Board!
The wire Problem i have solved but the Problem with not found the PicoBoard Reverse is still her!
piborg
Thu, 09/08/2016 - 18:28
Permalink
Board(s) may be damaged
As the wiring was back-to-front it is possible that either the PicoBorg Reverse or the Raspberry Pi now have damaged I/O pins.
Can you retry the instructions we posted in the first reply above and show us the results again?
cocoda74
Thu, 09/08/2016 - 19:15
Permalink
OK
OK
piborg
Fri, 09/09/2016 - 10:47
Permalink
No luck
No luck there, the board still cannot be seen.
Unfortunately this makes damage to either the GPIO or the PicoBorg Reverse fairly likely now.
Put simply the GPIO pins are not designed to tolerate more than 3.3v and they have been accidentally connected to 5v comming from the BattBorg.
Do you have a different Raspberry Pi that could be used to check the PicoBorg Reverse on its own?
cocoda74
Fri, 09/09/2016 - 11:02
Permalink
Hello
Hello
No i have not a second Raspberry Pi !
No Luck...
piborg
Fri, 09/09/2016 - 11:57
Permalink
Cannot check
Unfortunately it is very difficult to check either board to see if they are damaged.
We can try and check the GPIO pins we need, it might help.
What I would suggest is disconnecting everything (that includes the Multiplexing board) from the Raspberry Pi.
Next connect the bare minimum you need to control the Raspberry Pi and power it from a USB supply.
Now try this script:
and check these pins using a multimeter while the script is running:
If the Raspberry Pi is working they should both change between 3.3v and 0v at one second intervals.
Anything else suggests that the pin measured is not working correctly anymore.
cocoda74
Sun, 09/18/2016 - 11:02
Permalink
Hy
Hy
I can not run this script correctly
piborg
Sun, 09/18/2016 - 20:09
Permalink
Python script
You need to run the commands in
python
for them to work.cocoda74
Sun, 09/18/2016 - 21:56
Permalink
im sorry, this was not good
im sorry, this was not good thinked from me!
when script is running then i go with the multimeter + to the pin3 and with - to the pin6?
cocoda74
Mon, 09/19/2016 - 02:02
Permalink
i was not able to run this
i was not able to run this script but perhaps is the wiring pi test with pictures helpful
piborg
Mon, 09/19/2016 - 09:10
Permalink
Damaged GPIO
Unfortunately it looks like the GPIO pins are damaged on your Raspberry Pi.
It seems that both of the I2C pins are damaged, along with some others.
Unfortunately this means that the Raspberry Pi cannot talk with the PicoBorg Reverse anymore.
The only fix I can suggest to you is to replace the Raspberry Pi with a new one.
Given the damage caused I would suggest making a careful note of the correct way to wire the pins up for next time.
Hopefully the PicoBorg Reverse itself is undamaged and replacing the Raspberry Pi is enough to fix everything.
Sorry for the bad news :(
cocoda74
Mon, 09/19/2016 - 12:20
Permalink
I ordered a new raspberry 3
I ordered a new raspberry 3 and i hope i don't make the mistake a second time...
cocoda74
Wed, 09/21/2016 - 09:52
Permalink
New RP3 and Picoborg Reverse, but same issue...
Hello
With an new RP3 and a new Picoborg Reverse i have the same problem! No Pico Board found...
(I it fitted direct, not with the Ultraboard)
piborg
Wed, 09/21/2016 - 14:19
Permalink
Damaged PicoBorg Reverse?
It is possible that the PicoBorg Reverse was also damaged, but it is hard to check.
Does the UltraBorg work if it is connected on its own?
cocoda74
Wed, 09/21/2016 - 16:36
Permalink
Pico Borg Reverse Issue
hello
I hope not so, but it is possible that the second PBR is also damaged, but not because of me. I was very careful and i connected it after i checked all wires (from you)...
So i don`t think that it is may fault...
It is very strange, because the led of the first PBR funktion when it starts, the led of the second PBR doesn`t funktion at all.
So what can i do?
I don`t want to order a third PicoBorg Reverse....
The UltraBorg i haven`t connected so far...
cocoda74
Thu, 09/22/2016 - 05:24
Permalink
totally Confused....
Hello
Only for testing i connected the Ultra Borg und sudanly the PicoBorg Reverse function normally... And it is the old one, not the new one!
Now i am totally confused but also happy that it function...
piborg
Thu, 09/22/2016 - 10:31
Permalink
Getting going
It is good to hear that the first PicoBorg Reverse is undamaged :)
Sorry for the confusion in the previous message, I did not know you were testing with a replacement board.
I would suggest the latest trouble was probably a bad cable.
Some of the three-pin cables do not make a good enough connection for the I2C to work, this is why we supply a spare.
The best thing to do is take some photos of how it is connected now that the board is working.
If you run into problems again you should be able to go back to the connections from the photos.
I would suggest you stick to using the cables that are working at the moment if you can.
As for connecting other bits I would recommend attaching one new thing at a time and make sure everything still works.
That way it makes it easier to figure out what the problem is when something stops working.
cocoda74
Thu, 09/22/2016 - 11:31
Permalink
I just taked the Fotos this
I just taked the Fotos this morning...
Is there a fully ended functional Script to use with the Ultra Borg and PicoBorg?
piborg
Thu, 09/22/2016 - 12:52
Permalink
PicoBorg Reverse and UltraBorg script
We do have an example, but it is very simple.
It only uses one sensor, but it should give an idea of how this can be used for more complicated tasks.
It is based on the
ubServoFromDistances.py
example, but sets motor speeds instead of servo positions.The script below will attempt to keep the distance seen from ultrasonic sensor #1 around 200 mm.
It does this by setting the motor speeds faster / slower depending on how far away it is currently reading.
The same script is attached to the bottom of this post so that you can download it instead of having to copy it.
diddyFromDistance.py
cocoda74
Thu, 09/22/2016 - 17:01
Permalink
Can i run this script
Can i run this script parallel to other script for example the WEbUi?
piborg
Fri, 09/23/2016 - 10:28
Permalink
Running multiple scripts
Sort of, it depends what you want to happen.
If you run this script and the WebUI at the same time you will not be able to control the robot from the WebUI.
This is because the script above is updating the motor speeds very often.
Most of our scripts are designed to be run individually, but some parts can be shared.
For example the camera output on the WebUI can be used in conjunction with any script that does not use the camera.
It might be worth asking bui_hong_phuc if he can upload his completed script.
I would reply to his It works like a charm comment and see if he is happy to share.
Bear in mind that his ultrasonic modules are mounted differently so the code will probably need adjustment to work with your robot :)