Suspected networking error; macbook pro to raspberry pie 3b

I am at the dry testing point of building a (mostly all) ROV2. Some structural parts of enclosure and thrusters are 3d printed, motors are substitutes.Connecting MAC to Pixhawk usb shows successful communication with QGC. I am connecting directly through ethernet cable without the amplifiers as my tether is fairly short. I cannot ping the raspberry from the MAC unless I plug the ROV internet cable into my router but I do see the IP address in use connected directly. Maybe that is simply because the IP is in the table.
I was under the impression that crossover ethernet cables are no longer required for pc to pc connections as the ethernet interface is supposed to sense configuration. My MAC is 2012. I tried to purchase a crossover cable this morning in town but none are available (everything online now). I have ordered one online for testing tomorrow.
Any and all advice is welcome. At 71, my networking knowledge is fading quickly.
I have found clear statements on raspberry forums that, even though the ethernet connection is not gigabit, Auto-MDIX is definitely enabled. So, next …

Hi @ogopogo,

Have you been following our Software Setup Guide? The network setup section explains that the topside computer is expected to have a static IP of 192.168.2.1 assigned to its connection with the vehicle. If you’re using a direct ethernet connection rather than an FXTI then you’ll need to configure the IP for Ethernet instead of the USB 10/100 LAN shown in the image :slight_smile:

“Crossover cable” is not something I’d heard of before. You should definitely be able to use a standard ethernet cable (I do it regularly at my desk) - no crossover cable required :slight_smile:

I have followed all instructions - quite a number of times now. I have the surface IP configured as described (don’t use USB to ethernet at this point). I have found confirmation on the Raspberry blogs that the ethernet port is auto-sense so no crossover cable required (Eliot, you are clearly not old enough to have dealt with those :slight_smile: .) I have also found a post about MAC UDP ports failing to function as expected as a result of software/firmware updates. My windows laptop complains of missing DLLs when I try to install QCG to test alternative options. As I have access to a second 2012 MacBook Pro on an older version of OS, I will try QGC there. After that …

Let me retype this for a little less confusion. docs.groundcontrol.com states the minimum macOS version is “10.20”. Do they mean 10.2.0 (Jaguar) as there is no 10.20 - they moved from 10.19 to 11 to 12.

So it would seem :laughing:

The previous minimum version was 10.10, so I’d guess they made a mistake and should have written 11.20. I’ve just submitted a pull request to have that corrected :slight_smile:

I’ve just seen from another comment that you’re currently running 10.15, so it’s possible that’s too old for the latest QGC versions. Our previous recommended QGC version was v4.0.5, which was released before the macOS 10.10 → 11.20 minimum version recommendation, so that might be worth a try :slight_smile:

since that would be beyond the capabilities of the 2012, that would mean buying a new Mac . That is out of scope I’m afraid. I will try a Windows machine that I have to see if it is capable.

The 2012 MacBook Pro is apparently compatible up to Catalina (10.15), so I assume it should be able to use QGroundControl v4.0.5 (linked in my previous comment). Are you able to try that? :slight_smile:

oh dang, no dmg… hope I can remember how to make the tarball :slight_smile: been a very long time … see what I can re-learn

Oh sorry, didn’t notice that! Pretty sure it’s supposed to have one…

That tarball is for linux installs - it likely won’t work on Mac (they have some different components). I’ll see if I can sort out a download link for you.

I so greatly appreciate your support. I tar’d the file then got stuck - yup, linux

1 Like

I wasn’t able to find an internal one (it’s possible I got the link structure wrong, or we may only keep a copy of our latest recommended version), and also wasn’t able to find the one I used on my own computer.

I did still have 4.0.5 installed though, so I’ve turned that into a .dmg with Disk Utility, which seems to work normally on my system, so hopefully that’s all it takes :slight_smile:

Google Drive link

EDIT: BR Download Link

(I probably didn’t need to zip that as well, since dmgs are already compressed, but at least it’s a few fewer MB to download I suppose)

no love there - waiting for connection :frowning:
it’s about midnight here so perhaps tomorrow I will pick up an i7 windows laptop and try that. ping to 192.168.2.2 shows “no route to host”

Hmm - I wonder if your Raspberry Pi has a corrupted SD card, or the wrong software on it or something.

  • Do you see a green light flashing on the Raspberry Pi (next to the red power light) when you turn it on?
  • Does the Raspberry Pi ethernet port have a solid amber status LED, and a flashing green one?

Maybe try flashing on a fresh Companion image, or try a different SD card?

What’s the output of ifconfig (when run in Terminal)? If there’s a connection over the ethernet cable (regardless of IP) one of the outputs should be something like

enX: ...
    ...
    inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
    ...
    status: active

If the ethernet connection with inet 192.168.2.1 has an inactive status then it’s not recognising that there’s another device on the other end of the ethernet cable, which should be detected regardless of IP (in which case it’s likely a Raspberry Pi / hardware issue rather than a topside configuration issue).

Could also be worth trying a different ethernet cable if possible, or double checking that your existing one is working properly :slight_smile:

Wouldn’t hurt to try :slight_smile:

ok, picked up a Dell Lattitude E7450 i7 today to test. Installed QGC. Same result - no connection.
on the pi, solid red, intermittent green leds on board corner, at ethernet port, solid yellow, intermittent green
on the pixhawk, large led blue, 2 pwr green, flashing blue act
replaced ethernet cable
I will redo sdcard

This is so odd. That all sounds normal, so it’s quite surprising that it’s not working to connect to it.

Given the Raspberry Pi ethernet status LEDs are indicating a valid connection then it seems the main suspects would be the network configuration on each end. On the Raspberry Pi flashing a new image should ensure that end is in a known state, and the topside needs the correct IP set for the ethernet port, firewalls turned off, and relevant permissions granted for QGC.


I believe I didn’t ask earlier - are you able to access the Companion Web Interface (http://192.168.2.2:2770) in your browser?

DO NOT MAKE ASSUMPTIONS. How many times are we told that? My assumption was that the Pi would establish communication with the surface computer regardless of Pixhawk status. That is apparently not so. I would have expected the Pi to report a failed connection with the pix … not. Perhaps the code tries to establish this first and does not get to the surface until that is successful. I replaced, for the second time, the usb cable from pi to pix and up she came !!!

That is actually a correct assumption, but only for the communication that don’t require the Pixhawk - i.e. the web interface should be accessible, and the camera stream if you’ve got a USB camera connected that supports H264-encoded output.

If the connection to the Pixhawk isn’t working then the Pixhawk would fail to show up as a connected device in the web interface, but unfortunately QGC doesn’t have a mechanism to indicate “Companion is connected but autopilot board is not”. There also must have been some other issue as well originally, given ping was failing, which is unrelated to the Pixhawk.

A shame the time and effort it took to determine the issue, but excellent news that you’ve managed to resolve it! :slight_smile:

well, I have the latest Raspberry camera connected by ribbon and that may need to be configured yet?
the change of usb was within moments after booting with the new sdcard so perhaps it was not finished ?
I must commend you for your support Eliot. Even though I received another blue delivery today, my total purchases wouldn’t pay the light bill. You are a credit to BlueRobotics and I thank you.

1 Like

The Companion software is supposed to work with Raspberry Pi cameras. Does it show up in the Detected Devices on the System page of the web interface?

Thank you for the kind words - they’re much appreciated :slight_smile:

There’s not much value in making useful products and software if people aren’t able to use them, so we do our best to try to resolve any support issues as they arise. More generally, Blue Robotics as a company is all about enabling marine exploration through marine robotics, so we care a lot about fostering and helping the community. That includes everyone from beginners to experts, and is by no means confined to just what we’ll make the most money on :slight_smile:

re-etched pixhawk sdcard, moved to windows machine - we are communicating well. voltage and current telemetry ok, depth barometer ok - 5 of 6 motors spin up on depth hold (1 to check over). no video yet - have to answer your earlier question re system page detection. progress at last

1 Like