Next generation communication links for unmanned aviation

#1

Now that we have UAVCAN adoption happening, we are looking towards the next communication standards

Ethernet is where many UAS companies want us to go, so we have Ethernet/CAN options on the drawing board.

The question for ardupilot is, what should this actually be.

From a hardware point of view, adding Ethernet is not difficult, but how we use it is a bit more complicated.

With so many existing Ethernet protocols, do we want to grab one of them and do a com’s bridge? ProfiNet or EtherCat to Mavlink for example…

From a hardware point of view, what would the team prefer? A whole new autopilot that takes advantage of the added features, or external modules that gives Ethernet to PH1 users as well?

I’d love some input from this team rather than letting the other team drive these standards.

So I have few questions for Ardupilot developers…

  1. What function will this Bus have on Ardupilot?

  2. What data speeds are we needing?

  3. From a hardware point of view, we will be offering multiple solutions. 1, JST-GH 5 pin shielded twisted pair 2 fibre optic

  4. How would you like to see this used with Ardupilot

  5. Should this bus be standard IP? Or should this be a special UAVNET via IPLink

  6. Any other thoughts.

3 Likes
(Matteo Galet) #2

Not a developer, but as system integrator, I give my two cents based on facts I saw in the last years…

Answering your questions:

  1. basically high speed communication, payload standardization and easy IP network interaction between modules
  2. al least 100mbit/s should be the focus
  3. fiber optic seems a bit overcomplicating things. We have 10g ethernet on copper up to some meters, isn’t short distance 1gbit ethernet feasible on JST-GH 8 pin?
  4. one over all: seamless module discovery and software update from GCS. See next point.
  5. Let say we connect GCS to drone at his address using standard IP; there we find a DHCP lease list of attached onboard modules, and we can send each a new firmware via SMB/FTP/whatever. Once for all, payload included. Plug and play payload also possible via DHCP.
    Also streams from cameras are easily integrated (realtime h264/h265 converters are quite good these days).

6a. Being an onboard bus, should be as easy and light to implement, both physically and in software.
So it should be natively implemented in various modules, rather than adding converters or adapters.
Old hardware should remain on TTL serial or I2C, new hardware embrace ETH.

6b. CAN coexistance: single point of failure, low latency communications should remain on UAVCAN.
Dual-protocol connectors or even dual connectors for both standards may be implemented.

2 Likes
(Kendall Wells) #3

Common usage of Ethernet For Command and Control has been used for many years in Military UAS. It is ideal protocol for universal modem usage. TCP/IP is not the priority protocol due to the additional error corrections and packet resends. My experience has been that UDP is preferred because latency is lower and missing packets generally do not present a problem when sending telemetry, serial, video streams or even control signals.

2 Likes
#6

Read Q 1,2,4,5… all are questions that need to be answered to form that knowledge.

(Kendall Wells) #7

In My opinion based on Experience

Answers:

  1. Simple Ethernet to dedicated TTL/UART no need for Transformer at the Board
    a: This will provide low latency serial (SBUS) through the airborne modem (18 channels)
    b. Telemetry is added benefit over UDP port 14550 and or VCOM (Com XX) for payload control
  2. Provide 1Gb per second…Why not?
  3. Why Fiber? you will barely need 100Mb per second even Streaming RTSP
  4. See answer to #1
  5. Keep it standard, UDP, TCP, SSH…etc Why introduce UAVNET now when Mavlink already works
  6. Good to see ya’ll finally thinking about this… I have been using Ethernet on Flight controllers since the mid 90’s… Modem Ethernet via RS232, TTL and UDP
2 Likes
(Alberto Roca) #8
  • Functions: databulk information (video, audio, point clouds…) but also control data in e.g. tethered solutions could be interesting
  • Speeds >100Mb/s
  • JST-GH shielded should be enough for short distances
  • Agree with @MatteoGalet seamless module discovery and software update from GCS is a must
  • No need to create a new standard. Ethernet/IP has no fees, a bunch of support, any topology and centralized or decentralized control is possible, …
1 Like
#9

I totally agree that the IP link should be just an IP link. no need to re-invent the wheel!

the reason for fibre has nothing to do with speed. there are multiple airframes where it just makes sense. anything that is dealing with high RF noise, high electromagnetic interference, or the need for physical isolating of payloads from vehicles etc…

onboard connectors would tend to be JST-GH for general connections, or a higher quality connector for areas that need more robust connections.

I’m keen to avoid new standards… I hate meetings, and rarely do "new standards by isolated groups end up better than international standards.

2 Likes
(Alex) #10

I absolutely am in support of fiber for the reason you stated. As future drone complexity increases, so will the number of onboard sources of noise, and fiber is a guaranteed way to reduce interference. For some larger craft, a thin jacketed multimode fiber might be significant weight reduction over 4/8 wire ethernet, even for thin gauge wire.

Also, I do not think that the Cube/ carrier should be the “switch” for all the devices. It should have maybe 1 or 2 ports for direct attach devices, but main use case IMO should be as follows:

  • Cube with 1/2 ports (optical or fiber) connects to switch via copper or fiber (probably 100Mb/s)
  • Switches are lightweight and use micro size connectors (jst-gh for its locking would be great) unlike commercially available switches, and come in different flavors:
    1. Supporting optical (option for bidirectional single fiber or dual fiber) / copper / both
    2. Supporting different speeds (all should support mixed speeds, up to that switches max)
    3. Supporting different number of ports
    4. Can be daisy-chained if necessary
    5. May offer bus conversion (Ex: a 4 port “ethernet” switch that also has 2 can ports, 3 uarts, and 8 rc out channels that communicates with the cube via “mavlink over ethernet?”)

This opens the possibility for other manufacturers to make custom switches without re-engineering an already great and commercially available autopilot or carrier board. I also think RC control over an IP based radio link should be an option, putting low (8/16) channel count radios in the museum. Herelink could likely be adapted to this as well, possibly only requiring a modified air unit. Note, I do think that whatever IP-based radio is used should reserve priority for command and control packets over payload sensor messages or other data

Having all sensors be able to report values to mission planner/ QGC in custom fields would be incredibly useful for DIY/custom sensors. Even for a mapping lidar or high-res camera that might generate too much data to be streamed real time, sending back a count of the number of points collected or total number of images may be a good check to ensure data quality. Of course, as it would be an IP bases system, any sensor could communicate with a groundstation based program for data display.

FWIW, I’ve used this on a UAV I built with ethernet enabled sensors, however it did not connect to the FC directly, but via a companion computer.

1 Like
(Kendall Wells) #11

NO way you can today use fiber on a small UAS. You will not have any room, mass or power for any other payload at all. Fiber is small yes but you are greatly restricted by bend radius, termination, mass of transducers, mass of switches, mass of media converters and the most unfavorable is the Cost compounded for each termination for each single mode or multimode cable using Siemens, Omron. BlackBox…etc, etc

#12

Just remember that our hardware goes on small UAS, as well as UAS that are massive! Different platforms require different solutions

1 Like
(Olliw42) #13

this is interesting.

I don’t yet see the grand picture though. It would be great to see a process to condense ideas down to a final conclusion within a reasonable time …

2 Likes
#14

For critical sensors, CAN makes sense. But for communication with companion computers and any industrial gear, Ethernet is standard.
There are many places where Ethernet nodes are handy…

(Olliw42) #15

yes, sure, this I think isn’t disputed :slight_smile:

but as you also noted some things need to be settled for getting things going …

5-pin JSTGH or 8-pin? pin layout? must be shielded or only twisted pairs ok? transfomator or not? POE? … ???
would be a add-on like the W5100 used in Ardunio world be OK and sufficient, or does one needs more elaborate/advanced features and essentially has to use dedicated ethernet MCUs?
what will be the typical topology?
real-time EN or not? video/photos on the same line, or not? … ???
and so on.

very simply spoken: If I/one would want to be serious and add ethernet to some component (like a gimbal ;)) what would one have to do? Hardware wise, and possibly firmware wise.

if it’s not about getting there it’s all blabla, isn’t it? nails need to be put in the coffin … and it was this what I was wondering about, not the general motivation
:slight_smile: :slight_smile: :slight_smile:

2 Likes
(Matteo Galet) #16

IMHO to really start to see this thing adopted, it should be implemented in hardware, and then when it’s there, people will start exploiting it. A lot.

Personally I would go for 8 pin JST-GH, twisted pairs but unshielded (in my experience with CAT5/6 cabling, shielding is more of an issue than a benefit, even near 220v powerlines).

PoE shouldn’t really be necessary; if you think, PoE was invented for buildings and remote applications (cameras, antennas, ecc…) where lying an additional power cord would be an issue.
We can easily route two additional, appropriate AWG wires to each board on the drone.
This will save a LOT of real estate (and weight) on each device, as we wouldn’t need to add PoE hardware.

I think implementation of ETH should be left to each module manufaturer: one wants to go easy? use W5100. One wants full control and save space? Use MCU embedded capabilities.

Also we’re starting to see more and more cameras with ethernet output and control; I think adhering to the standards will be the smartest way to achieve day-one interoperability with already available payloads and hardware in general.

Then firmware will come… I mean, over TCP/IP everything is possible :slight_smile:

#17

Yep, agreed with all of that…

(Olliw42) #18

you make some very good points. But some one hardly can agree with, and they are actually rather naive, IMHO.

to really start to see this thing adopted, it should be implemented in hardware, and then when it’s there, people will start exploiting it. A lot.

Seriously? ???

We are homo sapiens, and one key feature of us is that we can learn from out past mistakes. And we can and should learn from - e.g. - CAN/UAVCAN. It was hailed as future already in 2014, hardware was distributed around to devs many years ago, but nothing happened because of lack of software and adoption (and I guess much to the frustration of the hardware designers). Only now it’s coming along, but now it’s 2019, nearly 2020. FIVE YEARS !!! 5 years to catch up to have something competitors have since more than 5 years. And there are other examples of this kind.

over TCP/IP everything is possible

Seriously? ???

I think I don’t have to comment further on that.

Fact is, I could add ethernet to the STorM32 gimbal controller in 1 month (thx to W5X00). By the end of the year it could then talk TCP/IP. Similar for other hardware. Give them few months. It’s easy to do the hardware and some basic communication stack. But ethernet is not going to fly anytime soon with the level of seriousness shown here.

So, I conclude, if this is it, it’s naive, childish chit-chat talk. IMHO. My suggestion was, and is, to get serious.

Good luck,
Olli

1 Like
#19

Try 2013… we made all sorts of hardware…

However… I have now actually hired Siddharth and Jonathan full time, so we won’t be waiting for an ever changing protocol in this case…

This is not a plan for a project to impress Ted audiences or VC’s… our questions are for our next project, not we wanted to gauge a few things first

(Matteo Galet) #20

@olliw42 I’ll elaborate more on my two unfortunate phrases.

Regarding the implementation, it is clear that CAN was not used as the implemented standard has been too much disputed for a while (remember the Zubax events?).
And given that is a bus connecting really delicate real-time flight control hardware, people took a lot of time to consider it safe; only now we’re starting to see it integrated in more products.

ETH and TCP/IP instead has been a well-defined standard since… forever, and also writing software for it is extremelt easy, as every MCU has its own libraries already. High level OS too.

In the application we’re discussing, at least in the beginning, the high data rate of ethernet would be used for high level data processing, that only after some intense computation will eventually result in direct commands to the flight control (if ever at all, may just be payload data transfer to GCS).

Critical hardware should still remain on actual busses like CAN or at least have a dual connection (think about how USB3 works).

Then writing software to work on the onboard TCP/IP will be extremely easy, and much software for payloads is already using TCP/IP on the ground, so virtually no effort at all.