Cape power issues


#1

Hello!

I broke down and finally found a BB white, plugged the cape in, hooked a 9V and 2 AA batteries in series (OK hacky but best I could do quickly) to get the 12 volts necessary, the power LED comes on on the BB, it does not boot, the green LED on the cape comes on, and LED3 is red ALWAYS.

What am I doing wrong? This also means I cannot upload the firmware to the Cape and I don't have an arduino to hook it up to and manually upload it either. Any help would be greatly appreciated!

Kelly


#2

In addition, if I hook up 18V (2 9V batteries) the beaglebone starts to boot, and then the red LED on the cape flashes and the boot up process stops.


#3

More tests:

I have the beaglebone powered through my computer, the cape powered with 18V (the 2 9V batteries) and the red LED stays on and the beaglebone boots up. Yay!!! Right? Until I plug in ethernet... then the red LED flashes and the beaglebone is no longer booted, it restarts itself and doesnt manage to complete boot up unless I unplug the ethernet cable, once I do that it magically boots again.


#4

I had similar problems with two brand new capes. I started this thread but no one was able to help: http://openrov.com/forum/topics/beagle-cape-power-problems

Based upon my testing, I believe the problem is in the NCP349 overvoltage protection part of the circuit. I ended up making my own cape using a DC-DC power supply from Dimension Engineering and it has been running non-stop for several weeks.


#5

Hi Kelly

Right off I would say it's not a good idea to have two power sources to run the BB & Cape. The BB & Cape are connected together so that they can power each other. You mentioned that when you plug in the Lan cable the BB reboots, it could be that the Lan Cable is providing a ground path for power or ground loop. The Cape should provide the +5V and also 3.3V using the 18V Batteries and you should not need the +5V from your USB off the computer to the BB. I would do things in steps. connect only the BB and make sure you can connect up to it through putty or browse to the cockpit. If that works connect up the cape with no servos or esc's. Power the cape up with 12V or 18V source and measure your voltages on the cape to make sure you have +5 & 3.3V, if you do, then connect up the Lan cable and see if you can connect using putty or the browser. if all is ok then add in your usb Camera to see if you can get this working in the cockpit. then move on to the Camera servo and remember about the 5v jumper on the cape, with no esc's connected the jumper should be in for the USB Camera servo to work, It should be removed if the esc's are connected as they will supply the servo voltage. You may have already done some of these steps but from your post it seems that you just plugged in the cape to the BB and powered things up.


#6

Hi David,

I did do everything in steps. First I had just the BB plugged in and working and updated the code (which didn't allow for me to get to the cockpit so I reverted back to the code that came with the Image). Then I added the cape because the next step was to update the firmware. Without the LAN connection to the router I didn't have access to do any of the updates so it was already plugged in. The cape turned on only when I gave it the 18V, I eventually replaced the batteries I was using and it started to work with the ethernet plugged in and all was well even with one ESC plugged in and the camera.

So my solution was to replace the 9V batteries, even replacing all batteries for the 12V hook up did not work, only the 18V worked. I do not have it plugged into the computer any more. But after 3 weeks of fighting with the Black to get it to work, tonight my students and I just wanted to see 1 motor run and that is why I had the additional power source for a while because it seemed to be the only way to get the system to boot.

Now I have run into the problem of updating the firmware. The wiki page for how to do all the updating is great and I have seen several posts where people point to it to figure out how to update the firmware, my problem is, I can do all of those steps, however what file do I upload, and where do I get that file? I see that it is names rov.tar.gz... where did that file come from? Is it just the zipped file from the whole git page or is it only a zip of the arduino section?

The camera also does not send data back, it does say it is plugged in but no image appears just a broken file image that chrome seems to like, but again right now I only am worried about finally seeing motors moving.

Thank you!

Kelly


#7

Hi Kelley

Great to hear that things are moving forward for you on this project.

It's been awhile since I have update the code and my memory is not as good as it use to be.

The file for the Arduino code is part of the master downloaded from here:

https://github.com/OpenROV/openrov-software

there is a download button on the right side of the page.

If you have updated the BB from the Master you should have these files on the BB.

But you can also download the master to your laptop, to a folder of your choice then point to it from the cockpit.

One item to try on the software that *might* increase the odds of success:

try changing the :
/usr/share/arduino/hardware/arduino/board.txt
change the atmega328.upload.speed=57600 to 115200

Also, you can get more detail by editing "
/usr/local/lib/python2.7/dist-packages/ino/commands/upload.py"
and changing the end of the file by adding the -vvv option as:

subprocess.call([
self.e['avrdude'],
'-C', self.e['avrdude.conf'],
'-p', board['build']['mcu'],
'-P', port,
'-c', protocol,
'-b', board['upload']['speed'],
'-D',
'-vvv',
'-U', 'flash:w:%s:i' % self.e['hex_path'],
])


#8

Also on the webam issue.

If you are using an older webcam and not the one used on the OpenROV it could be that the driver is missing or another possibility is that your power source can't provide enough current to power up the webcam properly. This will happen if you try to power the BB from the USB port.


#9

Good morning!

I'll look into the webcam issue, I thought we were using the same one but I can check later this morning. So, do I just point the "Upload firmware" area of the cockpit to the entire zip file that comes from downloading the open-rov-master?


#10

Here is some notes that I had for doing Arduino updates that may be useful:

User: rov
Password: OpenROV

User: root
Password: root

Manually update OpenROV Software
Step 1: log in as rov PW:OpenROV
Sudo Password : OpenROV
http://wiki.openrov.com/index.php/Update_Software
cd /opt/openrov
sudo ./update.sh

sudo rm -rf openrov_old
sudo /etc/init.d/openrov stop
cd /opt/
sudo mv openrov openrov_old
sudo git clone https://github.com/OpenROV/openrov-software.git openrov
sudo /etc/init.d/openrov start

If the OpenROV doesn't start and you see this lines that contain npm errors:
npm ERR! you can do the following.

sudo bash
cd /opt/openrov
sudo rm -rf node_modules
npm install
sudo /etc/init.d/openrov start



Step 2: Update the OpenROV Cape

While still connected to the BeagleBone type the following.

cd /opt/openrov/arduino/OpenROV
sudo tar -cvzf ../../src/static/rov.tar.gz *

Now switch over to the browser you use to interface with the cockpit and load the following.

http://yourservername:8080/rov.tar.gz

http://10.0.0.112:8080/rov.tar.gz

tail -f /var/log/openrov.log

These changes are need to upload to the Arduino from the cockpit.
"One item to try on the software that *might* increase the odds of success:

try changing the :
/usr/share/arduino/hardware/arduino/board.txt
change the atmega328.upload.speed=57600 to 115200

Also, you can get more detail by editing ""
/usr/local/lib/python2.7/dist-packages/ino/commands/upload.py""
and changing the end of the file by adding the -vvv option as:

subprocess.call([
self.e['avrdude'],
'-C', self.e['avrdude.conf'],
'-p', board['build']['mcu'],
'-P', port,
'-c', protocol,
'-b', board['upload']['speed'],
'-D',
'-vvv',
'-U', 'flash:w:%s:i' % self.e['hex_path'],
])
"



















Methode 2 for updateing the Cape by Stefan:

I use to edit the Arduino files directly at the beaglebone (using putty and the vi editor),
so I don't use the cockpit software to update the Arduino firmware. But from the console,
I have a reliable script to upload the code from there.

create a subdirectory called 'src' and another one
called 'lib'. I put all the files (Openrov.ino etc.) from the directory
/opt/openrov/arduino/Openrov to the subdir 'src'. Thie 'lib' directory is empty, but is
required by the 'ino' command.

When I want to upload the firmware, I go to /opt/openrov/arduino/Openrov and execute the
following simple script from there (as root with sudo):
Sudo reboot 0
cd /opt/openrov/arduino/Openrov
sudo rm -rf src
sudo rm -rf lib
sudo mkdir src
sudo mkdir lib
sudo cp * src

sudo ino clean
sudo ino build
sudo /opt/openrov/linux/setuart.sh
sudo /opt/openrov/linux/reset.sh &
sudo sleep 0.4
sudo ino upload -p /dev/ttyO1

Which builds and uploads the code reliably. The crucial thing about this was to find out the
correct sleep value (0.4 seconds) after starting the reset and before starting the upload -
the time window seems to be very narrow.

Maybe this is the key for making Brian's code work?
to remove the old Folder


#11

I think I found the fix for the Arduino upload issue: http://openrov.com/forum/topics/looking-for-folks-to-test-a-possible-fix-to-the-program-the (go to the end of the thread).

The issue is with timing of the toggling of DTR. The fix is a modification to upload.py.


#12

Thanks Len

By chance do you know the path to the upload.py file without having to power your BB to find it, if not I will search for it the next time I power up the BB


#13

If I was at home I could tell you. My BB stays powered all the time ;-)


#14

Ok it seems I have gotten further in the process! Thank you for the help! Now I am hitting a wall where it says there is no space left on the device when I try to upload it. I did make the changes to the upload.py and to the upload speed and I tried it through both the cockpit and through the terminal using Stefans solution.

Detecting Arduino software version ... 1.0 (1.0)
Scanning dependencies of src
Scanning dependencies of arduino
Scanning dependencies of Servo
src/Timer.cpp
src/Timer.cpp:18:1: fatal error: error writing to /tmp/ccqGzi2Z.s: No space left on device
compilation terminated.
make: *** [.build/uno/src/Timer.o] Error 1
Make failed with code 2

Thoughts?


#15

Looking back on my question I realize that it is not the smartest one to ask without adding some detail:

So, a bit more detail, I have added absolutely nothing else to the image besides following the instructions for updating, I even reverted back to the code that came with the image and deleted the folder with the code I cloned from the repository. But, when trying to use the cockpit I suppose it could've added files it was unzipping, would these have caused it to decide it was out of space? And if so, where are they so I can remove them?

I am using a 4GB sd card, would it be better for me to switch to a 8 or 16?


#16

I have the Same message, how can we clear the arduino?


#17

The Arduino "clears" everytime you upload new firmware. Either the current firmware is too large for the particular type of Arduino on the cape, or the compiler/bootloader is being told the wrong Arduino. Only the Arduino developer could answer that, and I don't know who that is yet.


#18

I had a similar problem when the firmware was not uploading correctly. I found that there was not enough space allowed for the tmp directory to compile the firmware.

Check the size of tmp by connecting through a terminal and using the 'df' command. Try modifying the software (firmware-upload.sh) to save and compile the arduino firmware in a directory other than tmp.


#19

Here it is: /usr/local/lib/python2.7/dist-packages/ino/commands


#20

Well, color me wrong... I think Kurt is right. But df doesn't show /tmp listed and from what little info I've been able to find online, it appears that Ubuntu doesn't handle /tmp the way I am used to.