I’m currently making a first attempt to port the ADS-B avoidance and GCS display code to work with AIS data (the equivalent of ADS-B for shipping). This would then allow the use of an AIS receiver (currently using the dAISy as it’s firmware is open source) onboard our boats. I hope this is a first step towards integrating collision avoidance autonomy into arduboat.
The AIS data protocol is quite detailed, so I’m posting to ask if anyone is interested in this functionality, and if so which AIS parameters they would consider valuable. I’m currently planning MMSI (ref no), Course over ground, speed over ground, nav status (fishing/underway/anchored) and position.
This would be a great addition to ArduPilot. I think the fields you’ve identified are the ones we’d need.
As a reference, the uAvionix Ping ADSB sensor provides this mavlink message. We don’t need all this info though, just the other vehicle’s id, position and velocity vector (i.e. ground speed and ground course). The status (fishing, underway, anchored) also sounds good to have.
Hi, I was also considering adding AIS collision avoidance and I also have some code already written, determining trespassable zones with a vector field of speed vectors constantly updated using the MMSI code.
Is the ADSB collision avoidance system used by ArduPilot compatible with a 2D representation employed in AIS?
The ADSB collision avoidance feature currently only works with data about the position and velocity of airborne vehicles provided by mavlink messages (which is what the uAvionix ping sensor provides). It sounds more like you’ve got code which provides no-go zones… so that would be quite a different approach. No-fly zones are on the to-do list but none of the developers has gotten to it yet.
My plan was to try to reuse as much AdSB code as possible, with a view to adding path planning or more intelligent avoidance later, with different safe distances from different vessels (more distance behind a trawler for example). Since boats can’t change altitude (hopefully!) in the existing code we are restricted to stopping. I am planning to add a change speed command too (to avoid stopping completely) otherwise in a busy section of waterway it may simply get stuck. That would probably use speed vectors to predict collision points and adjust speed until the vessels did not intersect. No go zones would be a nice feature but until it comes in upstream ardupilot probably beyond my capabilities!
The daisy receiver currently spits out NMEA but I’ve been in contact with the developer with a modification to spit out mavlink instead (the firmware can be updated over usb), and he seemed positive about implementing it in the official firmware (a cut down version of the firmware is open source and I wrote my modification based on that)
I think using a typical RTL-SDR dongle would be a much easier solution rather than the daisy receiver, especially at the sea where there are no barriers.
Then you can modify converters which print out raw data to send mavlink messages instead.
For the sailing/no sailing zones algorithm I have something already working and tested, the code is on GitHub which takes care of speed vectors defined using AIS data.
This brings a big smile to my face.
AIS awareness would be great.
Repurposing the adsb mavlink message is absolutely the wrong way to implement it though. This needs it’s own message.
Totally agree.
As I see it, ADSB and AIS collision avoidance should be separate both in terms of MAVlink messages consumed and code base, not only do they use a different grid system, but also ADSB often just gives out the current position making it difficult to create a speed vector field, whereas AIS always contains the basic info to determine (with reliable approximation within small T) the future positions of each detected vessel.
The daisy is cheap and has a serial bus already so it should be a trivial modification. There’s obviously nothing to stop anyone using different receivers as long as they can output mavlink over serial!
Sorry I wasnt clear! My plan was to make a new mavlink message and new ardupilot library, distinct from ADSB, but based on some of the ADSB code for storing other vehicles and sending them to a gcs to reduce duplication there (perhaps modify the ADSB message to the GCS to be a generic message for all surrounding vehicles whether detected through AIS/ADSB/other, with a flag for vehicle type or something?)
So basically you are suggestion to use AIS in a mere informative way, without any collision avoidance system, right?
Honestly I don’t find it useful since there are lots of websites giving out very accurate AIS readings for most locations in the world, the advantage of having an AIS receiver onboard is to use it to perform a basic path planning whenever the ASV trajectory intersects with the speed vector of another boat.
As a first step yes, because I need just basic avoidance (stop/change speed) for my transatlantic project. Much like the ADSB code is currently experimental we have to start somewhere!
Then I would hope other features can be added but some changes would be needed to the core autopilot routine code to allow for route modifying on the fly around detected obstacles. At the moment this is usually done with a companion computer with more computing power.
I agree path modification decisions would be useful, I am an autonomy engineer and I would like to see full collision avoidance in ardupilot, but at the moment the necessary environment sensors are not quite ready yet. I hope that if we follow similar structures (where possible) to ADSB avoidance that it will be easier to share guidance code and take advantage of new functionality (such as the no go zones) coming into copter in future.
I will try to put together an initial version of the code I have and then perhaps we can see how our effort can be merged
Well actually thinking about it there is no point in implementing a full AIS tracking system onto the ArduPilot, much better to leverage the processing power of a companion computer and then simply pushing trajectory messages to the ArduPilot. Think of the Raspberry (or any other SBC) as the Captain and the AP as the Helmsman, why would the latter need to know about AIS?
So maybe we should reconsider adding AIS MAVlink messages and handling code to the AP to work on the companion computer instead. For simple visualisation purposes, you can push data to marine traffic and enjoy a world coverage.
I’m interested in having the feature in ArduPilot directly because the setup will be relatively easy for the end user and I think we have the processing power to do this (we can handle ADSB). … also I will be better placed to help out. Writing up some code so we can discuss and decide on the direction is a good first step.
Of course some stuff has to be done on a companion computer … I’m not sure if this is one of those things…
I have had time to sit down and put my ideas into some code, but it will obviously also require changes to MAVLINK (a new message type) and MissionPlanner codebases (to send/display the data). How would one go about requesting changes to these?
We have been working on AIS implementation as well, but more at the MAVROS level. I would love to see AIS included in ArduPilot, much like ADS-B functionality but with more smarts.
We may have some contribution in the way of NMEA 2000 translation to custom MavLink messages, but it currently requires a companion computer. This is how we pull in engine diagnostics, control the radar mode, get sonar data, etc. As well, we have been working on getting radar data past the chart plotters through to the GCS over IP radios. The new NMEA OneNet protocol (still in beta I think) may help tremendously in that regard.
So, AIS is a great foundation for predictive avoidance, but radar for reactive…
BTW - Our AIS messages also broadcast a ‘notes’ field. This is where we include our contact info for how to pause the vessel over VHF (DTMF tones, morse, or speech). Be nice if we could include that data too.
I’m actually almost done coding a simple AIS interface (much like ADSB) and paired MAVLink message. However, as I see it, ArduPilot should mainly handle pre-formatted MAVlink AIS messages whereas all the capturing and parsing should be done on a companion computer.
In this way it is possible to handle a huge range of detectors, from the cheap SDR RTL dongles to dAISy and more expensive RX/TX equipment that needs licensing.
I noticed you’re talking about radars too, due to their weight and power consumption I believe supporting such instruments is quite secondary.
I would love to test your code when you have something ready, if that would be helpful to you. We have quite a few different AIS RX and transceivers we could test it with.
I certainly didn’t mean to muddy the waters with the mention of radar. I included it in the conversation because you mentioned (basic) collision avoidance. AIS is certainly a great step forward and I hope easily implemented.
Maybe on the second stab or for a more advanced collision avoidance project we could look at AIS + Radar + forward sonar (surface & subsurface) + dispatching to really get things safe. I think this is mainly because AIS transceivers are expensive, and most personal or non-commercial operators don’t transmit. When we are operating off a busy inlet we can visually see 30 or more vessels, and only 2 or 3 are transmitting AIS. Open ocean, we run across sailing vessels all the time that are not transmitting.
Radar tech has come a long way from the days of magnetron. The radar we use is solid state, 3kg, and draws 48W at full transmit power - very similar to the Garmin Fantom. On the UAVs, the ground radar devices are even smaller.
