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…
What function will this Bus have on Ardupilot?
What data speeds are we needing?
From a hardware point of view, we will be offering multiple solutions. 1, JST-GH 5 pin shielded twisted pair 2 fibre optic
How would you like to see this used with Ardupilot
Should this bus be standard IP? Or should this be a special UAVNET via IPLink
Not a developer, but as system integrator, I give my two cents based on facts I saw in the last years…
Answering your questions:
basically high speed communication, payload standardization and easy IP network interaction between modules
al least 100mbit/s should be the focus
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?
one over all: seamless module discovery and software update from GCS. See next point.
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.
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.
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
Provide 1Gb per second…Why not?
Why Fiber? you will barely need 100Mb per second even Streaming RTSP
See answer to #1
Keep it standard, UDP, TCP, SSH…etc Why introduce UAVNET now when Mavlink already works
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
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.
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:
Supporting optical (option for bidirectional single fiber or dual fiber) / copper / both
Supporting different speeds (all should support mixed speeds, up to that switches max)
Supporting different number of ports
Can be daisy-chained if necessary
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.
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
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…
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
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
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.
@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.
Apologies if this is considered a necropost.
I wanted to update you and others who may be interested in our experience. We are and have been using optical fibers on our UAS and UGV. I have 10G fiber that can bend in a 1" radius by spec, but in practice we have tested it to 0.3" without issue (though we do not use or recommend that). Media converters are not as large as you’d think, unless you’re referring to the consumer “boxes” for Ethernet/RJ45 to fiber or similar. We use generic SFP+ modules for our high data rate applications and smaller transceivers elsewhere.
I don’t endorse a particular type or brand, but I’ll link some for reference:
These are useful for their ease of termination for low-speed applications
Regarding cost/difficulty of termination, it isn’t that bad. Even from a marked up, retail outlet like amazon (useful for small orders) you can get the no-epoxy pre-polished quick SM SC connectors for $0.70/ea, SM LC for $2.50/ea, or MM LC (anaerobic glue) for $2.50/ea. Splices are similar in price. All the tools needed for that type of connector are available from amazon, ebay etc for $50-70. For the lengths involved in UAVs, the low loss of fusion splices are just not necessary. Compare to roughly 25 cents for a 8pin JST-GH and 8 three cent pins, and a 30 cent board header, it’s roughly between 50 cents to two dollars more per connector and $5 (and up) more for the board part. Termination of a single fiber with a quick connector is faster than terminating 8 crimps and installing them in the connector housing/shell.
@Kdub you are correct for the smaller UAS this will not be practical. For people who need the noise immunity, electrical isolation, or other benefits, it might be the right choice. On a large UAS with high-data rate sensors, it might be your only option. I’m not a die-hard fiber advocate, but I want people to know it’s an option, and you don’t have to jump feet first into the jaws of fusion splicing and 10G to access it. For example I made use of a setup using cheap ($1 to $5) 200kbaud transceivers and arduinos for high voltage (~3kV DC) isolation.
~edit for link correction, last time it was pointing at an anaerobic glue connector, that while faster than epoxy, was not the quick <1 min ones I was attempting to reference
