Why are ships still waiting at anchor?

Our own live vessel feed from the Bay of Bengal, going into AISHub.

Problem

Most of the Bangladesh coast simply had no terrestrial AIS coverage. If you wanted vessel positions here you bought a satellite feed, or you went without.

Approach

Together with AISHub we put up receiver stations on the coast. They decode the VHF AIS signals from the shipping lanes and push the data into AISHub's global network. The stations have been live for a while now and have kept going through power fluctuations, which is not a small thing here. Every other maritime track on this page sits on this data.

Knowing roughly when a ship will actually arrive, and not only the ETA she declared.

Problem

Port planning depends on declared arrival times, and those slip by hours, sometimes by a full day. Then the whole berth plan has to be redone.

Approach

We're testing forecasting models on vessel position history from our own stations and on port activity data, to see how far ahead we can predict the real arrival time with useful accuracy.

Catching engine and system wear before it becomes a breakdown at sea.

Problem

Most equipment failures on board are found after the damage is already done, because planned maintenance still goes by the calendar and nobody is looking at the actual condition of the machine.

Approach

We're exploring deep learning on onboard sensor data, mainly vibration, temperature and pressure logs, to check whether we can pick up early wear patterns well before a failure.

A single live picture of every vessel moving in a busy waterway.

Problem

At present a port authority has to piece the traffic picture together from a few separate feeds, AIS, radar, VTS logs, and each one covers only a part of it. On a narrow channel like the Karnaphuli that gap matters.

Approach

We're researching sensor fusion, basically merging vessel tracking, radar and port data into one combined view that doesn't fall out of sync as the traffic moves.

Less waiting time at anchorage, because port entry gets planned in advance.

Problem

Arrivals aren't coordinated with each other. Ships turn up when they turn up, and then they wait at anchorage for a berth to become free.

Approach

We're designing queueing and scheduling algorithms that plan the entry sequence before the ships arrive. The aim is that ships wait less overall, and when they do have to wait, they do it somewhere cheaper than at anchor.

Early warning for risky close-quarters situations in dense traffic.

Problem

In crowded waters a dangerous encounter is often noticed too late, when there's very little room left to manoeuvre.

Approach

We're modelling traffic density together with weather and visibility conditions, so that high-risk encounters can be flagged earlier, while there's still time to do something about it.

Approvals and reporting handled by a workflow, with a person involved only where one is really needed.

Problem

In most companies here a surprising amount of office time goes into moving the same numbers between email, Excel and the ERP, and then following up with people for sign-off. We've seen this at nearly every client.

Approach

We're testing n8n workflows with an LLM in the middle, on document reading, approval routing and report generation. The honest question is which of these jobs can be handed off fully and which ones still need somebody in the loop, and we don't have a clean answer yet.

Orders and invoices moving between two businesses without anyone typing them in a second time.

Problem

Between a distributor and its retailers, or a factory and its suppliers, most orders still arrive as a phone call or a WhatsApp message, or as a PDF that somebody then types into the system again. Mistakes creep in at every step.

Approach

A lot of this comes out of the Amar Bot work. We're researching how to capture these orders from chat and from documents and push them straight into the other side's system, so a person only looks at the exceptions. Getting the two sides to agree on a format is the hard part, more than the tech.

Cameras that count, read and flag things on site, so nobody has to sit and watch a screen all day. That's the aim, we're not there yet.

Problem

Factories and yards here mostly have cameras already. The footage just gets looked at after something has gone wrong, if at all.

Approach

We're experimenting with vision models on live camera feeds, for counting, for reading plates and labels, and for spotting unsafe situations. Much of the work is checking how well these models hold up with the camera quality and lighting we actually find on site, which is usually a lot worse than in the demo videos.

Language models that understand Bangla and Banglish properly, the way people here actually write it.

Problem

Most language models are weak on Bangla, and weaker still on Banglish, the Bangla-written-in-English-letters that fills comment sections and Messenger chats. Spelling differs from person to person, and dialect changes from district to district.

Approach

We built a custom NLP engine for Bangla and Banglish for Aivax, and that one is in production. The research side is taking it further, better handling of dialect and spelling variation, and finding out how far open-source models can be tuned for Bangla before you have to build something custom.