New 2.7 build - can't connect to beaglebone


#1

We’re having trouble with step 18 of OpenROV 2.7 Guide 6. Connecting from Chrome to http://192.168.254.1:8080/ gives the error: This webpage is not available ERR_CONNECTION_REFUSED.

We’ve tried from 3 different laptops and have verified the static ip and subnet settings are correct and we are able to ping 192.168.254.1 successfully.

We’ve isolated the issue to the beaglebone by removing it and connecting the ethernet cable from the laptop directly with the BBB powered off a 5v source independent of the control board and Tenda adapter. Ping succeeds but we get a connection refused to port 8080 from Chrome. Connecting via putty also produces connection refused.

We’ve tried updating the software using the procedure in the Operator’s manual, first with the v30.0.2 ROV FLASH image and then with v30.0.0 ROV SD card image and then again using the v30.0.0 ROV FLASH image with two different SD cards.

It seems like all of our attempts to flash the BBB from the SD card are unsuccessful. Any suggestions?


#2

Some progress. I had set the laptop’s static ip to 192.168.254.1 instead of 192.168.254.2 as directed.

After fixing that I did an ipconfig /flushdns and was able to ping the actual beaglebone and connect via putty using rov / OpenROV as the credentials. I was even able to reach the cockpit web page, though this was while the beaglebone was still only connected directly to the laptop.

Next I connected the beaglebone back to the control board and was able to ping it. The putty connection prompted for user (gave rov) but terminated right away after supplying OpenROV as the password. Connecting to http://192.168.254.1:8080/ still gave This webpage is not available ERR_CONNECTION_REFUSED.

Everything appears to have power. The LEDs are lit on the topside Tenda (green power, orange HomePlug connect, and orange Ethernet connect).

On the control board the lights are on for: LED6/HPWR, LED7/HP, LED8/ETH, LED1/PWR, LED1/BRX (flashed)

On the beaglebone I can see activity on the blue user LEDs.

Periodically the LEDs on the light board to start flashing every second. At times I hear the servo buzzing.

Now I’m wondering if something is happening with an auto-update of the control board firmware?


#3

A couple of points that may help your debugging; The flashing of the light board will occur when the cockpit is running but there is no communications with the surface, if these are flashing for a period and then stopping it sounds like the beaglebone is booting up, successfully loading the cockpit and then rebooting after a period. The same with the servo buzzing, the buzzing is when the servo can’t hold the correct position, again if it is stopping and starting I suspect that the beaglebone is resetting.

I would start by making sure the batteries are fully charged and that there are no poor connections (either on the D25 connector or the way the batteries/terminals are mating). Do you have an IMU installed? If so double check the wiring as faults here have caused people a range of headaches. If you cant find anything wrong here, removing everything bar the tether and battery connections from the D25 connector and re-test.


#4

I am having the exact same issue. The funny thing is, a month and a half ago I did connect to the cockpit just fine! That was on a different computer though. Im going to charge all my batteries again I think. All connections seem to be secured. This is frustrating that I didn’t touch the robot for 50 days and now it isn’t working.

Question: Could the robot be flashing its LEDs, trying to turn the servo, and the beagle bone flashing its lights and the batteries not be charged?

Thanks


#5

To answer my question: I opened up the battery tubes and plugged in the USB and everything still happened as before. Ugh. I don’t know where to go from here.


#6

Hey guys, we’re building a tool to help people figure out where to start troubleshooting this issue.

Please give it a try and see what happens. It’s still in BETA but you might be able to find a solution.

https://openrov.yonyx.com/y/conversation/?id=7c5b2d70-eac3-11e4-a42b-bc764e1028dd&h=1&st=0

Thanks, and keep us posted.

Zack


#7

Thanks for all the suggestions. Yesterday we got back to work on the OpenROV and found that the Tenda board mounted underneath the beaglebone was causing a short. Only part of the board is protected by a plastic shield. We covered the rest with electrical tape and were finally able to make the connection to the cockpit. After wrapping up the remaining build steps it went in the pool for a successful maiden voyage. Still need to find a better long term solution than the electrical tape to ensure the pins don’t poke through and cause the same issue in the future.


#8

@Zack, My computer could not ping the openROV no matter what. power: green. Middle light: orange. Ethernet: off until I plug in ethernet to my computer, the it goes orange. I tried increasing the IP address to no avail. I added a small piece of paper between the tenda and the Beaglebone as a temporary solution to see if shorting was the issue. It was not. The most confusing part for me is that I was able to connect to the cockpit almost 2 months ago now, didnt change a thing, and now I cant.

After about 2-3 of it not being able to connect, the servo is still buzzing and the LEDs have all started flashing at 1 minute intervals. Im just not sure how to continue from here. If anyone has any suggestions, I would love them. I’ll try anything.

Edit:

Also, as a side not, after being plugged in for a while the Beaglebone Black was getting pretty hot. Not at the levels where it could damage the electronics (I don’t think), but pretty hot nonetheless.

Is this normal?

Edit 2:

Ive reached the commenting limit on this thread so here is the transcript of three different attempts to ping the board. Weird that they are different:

— 192.168.254.1 ping statistics —
4 packets transmitted, 0 packets received, 100.0% packet loss
owens-mbp-2:~ Owen$ ping -c 4 192.168.254.1
PING 192.168.254.1 (192.168.254.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

— 192.168.254.1 ping statistics —
4 packets transmitted, 0 packets received, 100.0% packet loss
owens-mbp-2:~ Owen$ ping -c 4 192.168.254.1
PING 192.168.254.1 (192.168.254.1): 56 data bytes
ping: sendto: Host is down
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2

— 192.168.254.1 ping statistics —
4 packets transmitted, 0 packets received, 100.0% packet loss
owens-mbp-2:~ Owen$ ping -c 4 192.168.254.1
PING 192.168.254.1 (192.168.254.1): 56 data bytes
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: Host is down
Request timeout for icmp_seq 2


#9

Are the user LEDs flashing or are they in a Cylon visor pattern back and forth like step one of the Troubleshooting Guide post? When the BBB is booted up properly this is the light pattern.

Can you connect directly to the BBB using the ethernet cable and connect?

The electronics will get warm.


#10

I cannot connect directly to the BBB even straight through my computer.


#11

When you connect the BBB to your computer which of the blue lights are on or blinking?


#12

I was able to connect straight with the computer! Will try to connect again tonight and see if I can connect when the DB-25 connector is in and the BBB connected to the main board. I am beginning to run out of time to fix this!


#13

Make sure that both your homeplug adapters are seated into their parent boards well. Additionally you can replace the RJ45 jumper with a known working ethernet cable to remove this as a source of the error. Furthermore, you should also check that the tether is connected at the terminals.

Also, when you connect to the bone, are you saying that you get connection with the cockpit?

Z


#14

So here is what is happening now.

[Album][1]

I can ping the BBB through the tenda as well as straight through the computer.

I get these results:

PING 192.168.254.2 (192.168.254.2): 56 data bytes
64 bytes from 192.168.254.2: icmp_seq=0 ttl=64 time=0.071 ms
64 bytes from 192.168.254.2: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 192.168.254.2: icmp_seq=2 ttl=64 time=0.150 ms
64 bytes from 192.168.254.2: icmp_seq=3 ttl=64 time=0.148 ms

— 192.168.254.2 ping statistics —
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.071/0.115/0.150/0.034 ms

I plug in the robot through the tenda and I immediatley hear the buzzing of the servo, unless the webcam is in the correct position on boot up. After a minute or two the main bright white LEDs on the front board start to flash once every second or so. I checked all the connections, they appear to be good. The homeplug adapters can only fit the pins about half way (maybe 3/4) because of the ethernet plug hitting the bottom board, I assume this is OK however. I really don’t know whats going on here. Thank you so much for the fast replies!

Edit: Zach, to answer your question, I have not been able to load the cockpit through the BBB, regardless of being connected to the DB-25 and bottom board, only able to ping it.

Also something that may be worthwhile to note:
When i try to load the webpage: 192.168.254.1:8080

It takes a long time and then says Gateway Timeout: can’t connect to remote host

If i do 192.168.254.2:8080 or any thing else it says immediately webpage not available.
[1]: http://imgur.com/a/3cWi5


#15

I am seeing the same problem. Here, it happened after upgrading to 30.0.2, so I downgraded later to 30.0.0, but see the same problem.

After flashing the BBB with v30.0.0, the ROV started fine, and I could load the Arduino firmware. The second startup failed, but the third one was ok, and I could control the ROV and read telemetry. Every later startup fails with the ROV flashing the lights at the end.

Occationally, I have had a continously ping running. Sometimes, I get a response for a short while, but the connection breaks just before the lights starts flashing.

The four blue user leds keeps flashing (no cyclon pattern). At the end of the startup, only 0 and 2 keeps flashing.


#16

I just found something that might be interesting… It seems like my file system is corrupt. I am not sure how this can be solved…

As a sidenote, I read somewhere that the BBB offers serial debugging, but had problems finding any documentation on how to do this for the OpenROV. In a drawer I found that I had a TTL-232R-3V3 cable, and also found that the pinout matched the BBB debug connector J1. Connecting with Putty, using 115200 baus gave me some details straight away… (se the output below)

There were messages after the startup, where I was encouraged to run a fsck command to clean up the file system. Unfortunately, the device wanted the root password which was not OpenROV. Is this password available?

Anyway, as I couldn’t get to it as root, I found it worthwhile to try another load of the Flash image, still with the debugging console attached. At the end, this also reported errors with my file system: Volume was not properly unmounted. Some data may be corrupt. Please run fsck.

I will investigate further, but appreciate any input from you experts. This is the end of the output from the regular boot:

[ 4.192523] udevd[91]: starting version 175
Begin: Loading essential drivers … done.
Begin: Running /scripts/init-premount … done.
Begin: Mounting root file system … Begin: Running /scripts/local-top … done.
Begin: Running /scripts/local-premount … Scanning for Btrfs filesystems
done.
[ 5.097893] EXT4-fs (mmcblk0p2): mounted filesystem without journal. Opts: (null)
Begin: Running /scripts/local-bottom … done.
done.
Begin: Running /scripts/init-bottom … done.
INIT: version 2.88 booting
[info] Using makefile-style concurrent boot in runlevel S.
[ 6.225533] random: nonblocking pool is initialized
[…] Starting the hotplug events dispatcher: udevd[ 6.351591] udevd[316]: starting version 175
. ok
[ ok ] Synthesizing the initial hotplug events…done.
[…] Waiting for /dev to be fully populated…[ 6.848021] omap_rtc 44e3e000.rtc: rtc core: registered 44e3e000.rtc as rtc0
[ 6.855686] 44e3e000.rtc: already running
[ 7.148252] omap-sham 53100000.sham: hw accel on OMAP rev 4.3
[ 7.253381] omap-aes 53500000.aes: OMAP AES hw accel rev: 3.2
done.
[ ok ] Setting parameters of disc: (none).
[ ok ] Activating swap…done.
[ 8.310516] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[…] Checking root file system…fsck from util-linux 2.20.1
rootfs contains a file system with errors, check forced.
Unattached inode 37561

rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck died with exit status 4
failed (code 4).
[…] An automatic file system check (fsck) of the root filesystem failed. A manual fsck must be performed, then the system restarted. The fsck should be pe[FAILed in maintenance mode with the root filesystem mounted in read-only mode. … failed!
[…] The root filesystem is currently mounted in read-only mode. A maintenance shell will now be started. After performing system maintenance, press CONTRO[warno terminate the maintenance shell and restart the system. … (warning).
Give root password for maintenance
(or type Control-D to continue):


#17

Just another update, I now started the BBB detached from the ROV, with ethernet cable directly to my computer, and the Dashboard (http://192.168.254.1) and the Cockpit (http://192.168.254.1:8080) opens up just fine. This is the same experience as before, where the first startup works fine. I expect later startups to fail…

Output from startup this time:
[ ok ] Starting system message bus: dbus.
[ ok ] Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon.
[ ok ] Loading cpufreq kernel modules…done (none).
[ ok ] CPUFreq Utilities: Setting ondemand CPUFreq governor…CPU0…done.
[…] Starting OpenROV NodeJS server: openrovchown: cannot access /var/log/openrov.log': No such file or directory chown: cannot access/var/log/openrov.err.log’: No such file or directory
[ ok ] —> started OpenROV NodeJS server: openrov.
[ 63.628637] IPv6: ADDRCONF(NETDEV_UP): usb0: link is not ready
/opt/openrov/proxy//app.js
[…] Starting OpenROV NodeJS proxy server: openrov-proxychown: cannot access /var/log/openrov.proxy.log': No such file or directory chown: cannot access/var/log/openrov.proxy.err.log’: No such file or directory
[…] —> started OpenROV NodeJS proxy server: openrov-proxy[…] —> set HTTP_PROXY/HTTPS_PROXY environment variables: openrov-proxy[…] —> [ ok git proxy variables: openrov-proxy[…] —> set NPM proxy variables: openrov-proxy[…] —> set BOWER proxy variables: openrov-proxy.
[ ok ] Starting OpenBSD Secure Shell server: sshd.
Starting very small Busybox based DHCP server: /usr/sbin/udhcpd already running.
udhcpd.
[ 129.002182] mmcblk1: unknown partition table
[ 129.040382] mmcblk1: p1 p2
[ 301.136891] EXT4-fs (mmcblk1p2): mounted filesystem without journal. Opts: (null)


#18

I can’t load the cockpit or dashboard on my BBB detached from the openROV. My lights seem to be fine, 2 and 4 are flashing back and forth in a cylon visor pattern, 3 and 5 do not turn on. Will someone help guide me in the right direction? Any advice would be appreciated


#19

Today everything was good with my OpenROV but now I have the same problem… I try to solve this issue by the guide: http://beagleboard.org/getting-started#step1

USR0 is configured at boot to blink in a heartbeat pattern /on
USR1 is configured at boot to light during microSD card accesses /off
USR2 is configured at boot to light during CPU activity /on
USR3 is configured at boot to light during eMMC accesses /off

I can’t install drivers (BONE_D64) on windows 10: http://imgur.com/FeT2Ozn
Also Windows didn’t see BBB (earlier was everything good) Any ideas?

@UPDATE
Good news. Finally (after ‘xx’ attempts) I can install software + Arduino update (http://openrov.dozuki.com/Guide/Update+Software+Image+From+SD+Card/90). Unfortunately the system has capable to crashed. We have to have all time the microSD card with latest software.


#20

Have the same problem. Managed to connect to cockpit the first time I set up, but stopped working after that. Comes up with the same error first announced. A bit annoying as I hadn’t touched it in between and was happy that it worked. Thanks for all the conversation on this topic, will try to run through some of the fixes. Will let you all know how it goes.