Ethernet and TCP/IP in ArduPilot

Tested out the BotBlox SwitchBlox mini with custom made cables to HereLink, Pixhawk 6x and CM4 module. “Just works” after setting IP addresses.

Not sure if I set things up correctly though. I had DHCP enabled and it pulled an address. However I had to manually set NET_P1 address/port manually. Is this normal and expected? Also Mission Planner didn’t detect MAVLINK stream on 14550 automatically but did see the stream from HereLink controller over WiFi. It did connect manually though.

Does this option work like a normal IP multicast, where there’s a source IP and multicast IP/port? Should we be using 224.0.0.0/4 subnet for the multicast streams?

Also any plans on IPv6 support? Here in the US most mobile networks are IPv6 primary with non-public IPv4 unless you buy a static IP.

This video explains how to setup PPP support with ArduPilot, so you can get full IP networking on flight controllers that don’t have an ethernet port:

1 Like

yes, that is normal. The DHCP sets your boards IP address, but it can’t know what you want to connect to

if you want to do multicast, then yes. Multicast is great for swarming. For single aircraft a UDP unicast is a better choice.

not at the moment, I expect for those wanting IPv6 will gateway via their GCS laptop

1 Like

This is wonderful. One question - is there any reason not to run the web server on the AP on port 80?

I’d suggest looking at a VPN @ReadyKilowatt - you will want security anyway and most VPN software like Tailscale (my favorite) or Zerotier, etc. will give you secure virtual IP4 network.

You might need to do some routing on the Pi to get traffic from the ppp link to the VPN and back.

1 Like

Log file download speed compare. Is it a valid compare.

I think have to increase the USB or USB to serial speed for a valid compare.

So, should try change it to 12.5Mbps to serial 0 and compare it again. Provided MP interface support it.

I hope to see the Telemetry Radio manufacturer to incorporate this.

this is very cool, it would be nice if it could run on something smaller than a pi like esp32.

the baudrate is not used on USB - the speed does not vary at all by changing baudrate as USB is packet oriented

@tridge Having PPP networking looks really promising.
Is it possible to use the PPP functionality at pixhawk 2.4.8 board and the clones? How significant would be performance penalty for such boards?
Is there data encryption at data link layer? Asking because I’ve read some PPP documentation pages and it looks like PPP ECP is kind of optional-ish. Having encrypted telemetry link over serial would be way more secure than just signed mavlink packets.

Asking questions before actually trying. To see if it is worth a try.

I haven’t tried on a STM32F4xx. Please have a try, but you may find you run low on memory

there is no encryption support

Brilliant. A thousand thanks to tridge and everyone who contributed to this milestone in flight controller development:

With master firmware on a new Pixhawk 6x, the UDP connection to Mission Planner and simultaneously an HTTP server with the demo LUA script worked like “out of the box”. Still an unfamiliar sight: FC connected to the home network.
n2

both

Since no GPS is connected to the FC on the workbench, the AHRS and GPS location are logically not displayed:

Great: If a GPS fix is available, the AHRS/GPS position are displayed as hyperlinks, when I click on it, the position is displayed in google maps on my laptop.

I have not stopped the time for the log file download, but it feels much faster compared to the USB connection. To test this, I copied a 136 MB log file from some flight to the SD card and renamed it accordingly. The speed is impressive, so it’s not worth connecting the USB or removing the SD card and inserting it into the laptop for reading:

It would be great if you could also execute LUA commands on the server side by clicking on a button, for example.

Regards Rolf

2 Likes

Looks like BVLOS seamless operation is going to be easier and easier going forward with companion internet ready stack board.

Thanks for this nice feature! I can confirm that it works great with my “more or less” DIY-Project, the NucPilot. A PCB, with IMUs, Baros, Mags, SD-Card, FRAM, 32Mbit Serial Flash, double CANFD, Serials, PWMs, RCIN, up to 12S input voltage via XT30, that you can put on a Nucleo-Board, in this case the one with dual core MCU ( NUCLEO-H755ZI-Q). You can direct connect a RJ45 plug into the board and use the new Ethernet feature of ArduPilot.

3 Likes

Nice board Mirko, are you using both H7 cores? What for?

Thank you Amilcar. The used MCU STM32H755ZI has a Cortex-M7 + Cortex-M4. At the moment only the H7 is used for ArduPilot. I have a couple of these boards lying around in my office. That is the reason for having that board.

sure, it is easy to add anything that can be done by lua. What sort of example would you like to see?
We can create a full GCS if that is wanted. I do plan on adding parameter editing

Amazing. For Ajax dyslexics like me, it would already be very helpful if the script contained examples of how LUA can be used to react to button clicks and text inputs.

Rolf

I’m having a problem with ppp on the AP timing out before the Pi connects. Here’s 2 scenarios.

I have an existing plane running a Durandal with a Raspberry Pi Zero. I previously had uart2 connected to the Pi using mavlink so I know it works. (I can actually get ppp to work by force rebooting the AP after the Pi is up).

Scenario 1: Pi takes longer to boot than the AP

  1. Plugin the flight battery. AP and PI start to boot.
  2. AP completes booting and starts listening for ppp connections
  3. AP gets no ppp connections, throws an error and stops listening
  4. Pi finishes booting (It’s a Pi Zero so it takes about 60 seconds)
  5. Pi fires up pppd, tries to connect to AP but fails because it’s no longer listening

Scenario 2: Set up AP on USB power before booting the Pi

  1. Plugin the AP to a PC using USB
  2. Spend some time (5 - 10 minutes???) setting up a mission or whatever on the AP
  3. ppp on AP times out because it got no connections
  4. Plugin flight battery (USB still connected) - Pi starts booting
  5. 60 seconds later (10-15 minutes after AP booted) Pi finishes booting
  6. Pi fires up pppd, tries to connect to AP but fails because it’s no longer listening

My thought is that ppp on the AP should not timeout and die, it should loop, maybe with a delay, and continue to listen for attempts to connect. The companion computer may not connect on ppp within any hard time limit.

this PR should fix it: AP_Networking: auto-restart PPP on error by tridge · Pull Request #25893 · ArduPilot/ardupilot · GitHub

Yes that works. Thanks @tridge