Autonomous Shuttle Software for Campuses and Resorts: How Stop-to-Stop Service Works

Autonomous shuttle software is the layer that turns a self-driving cart into a service people can actually use. The cart’s own onboard computer does the driving. The software lets riders choose stops on a map, hail a cart or book ahead, watch it arrive, board within a set time and pay a fare if there is one. On closed sites with fixed stops, this stop-to-stop model is the simplest way to run on-demand self-driving transport.

This guide explains how the model works, how routes are set up, what riders see, which safety details matter and what to ask before choosing a provider.

What is stop-to-stop on-demand shuttle service?

In a stop-to-stop service, a shuttle travels along a known route and picks riders up and drops them off only at named stops. Unlike a bus with a timetable, it runs on demand: a rider asks for a trip from one stop to another, and a cart comes to them. Unlike a taxi, it does not go door to door. It stays on routes the site has prepared.

For self-driving vehicles, that limit is a strength. A known route with known stops is far easier to operate safely than open streets with unpredictable destinations. Riders understand it straight away too: pick where you are, pick where you are going, get in.

Which sites suit autonomous shuttles?

Closed and semi-closed sites share a few traits: private roads or paths, low speeds, a clear set of destinations and one owner who decides the rules. Good examples include:

• Resorts, moving guests between the lobby, villas, pools, restaurants and the beach.
• Universities, linking halls, libraries, sports grounds and car parks across a wide campus.
• Hospital campuses, helping patients, visitors and staff cover long walks between buildings.
• Data centres, moving staff and contractors around large, secure sites.
• Theme parks, connecting entrances, hotels, parking and different areas of the park.
• Office parks, covering the gap between buildings, canteens and the nearest transport links.
• Retirement communities, giving residents an easy ride to the clubhouse, shops or medical centre.

In each case the site owner wants reliable movement without a driver for every cart, and riders want a short, predictable trip.

How is a shuttle route set up?

Setting up a route is closer to drawing a bus map than to programming a robot. A typical setup looks like this:

1. Record the route once. The path is recorded on the site itself, so carts follow a route that has really been travelled rather than one guessed from a map.
2. Name the stops. Stops get names riders recognise, such as “Main Lobby”, “Library” or “Car Park B”, instead of coordinates.
3. Set pickup and drop-off rules. Most stops allow both. Some might be drop-off only, such as a busy entrance where carts should not wait, or pickup only.
4. Set wait times. Decide how long a cart waits at a stop for its rider to board.
5. Choose the route shape. A loop runs in a circle, which suits a resort ring road. Both ways lets carts travel back and forth along a line, which suits a long campus spine. One way suits paths where traffic can only move in one direction.
6. Set service hours. Riders can hail or book only while the service is running.

Because the route is the foundation of everything else, make sure changing it is easy. Sites add stops for events and close paths for maintenance.

What does the rider experience look like?

For riders, a good shuttle app feels like a ride-hailing app with fewer choices to get wrong:

• A map of stops. The rider sees every stop on the site and picks a pickup and a drop-off.
• Hail now or book ahead. They can ask for a cart straight away, or book a ride for later within service hours, which is handy before a dinner reservation or an appointment.
• A live cart on the map. Once a cart accepts, the rider watches it approach, so there is no guessing whether it is coming.
• A boarding window. When the cart arrives, the rider has a set amount of time to get on. That keeps the service moving for everyone else.

Because riders only get on and off at stops, every trip is predictable for the rider and for the site.

What safety design should shuttle software include?

The self-driving system handles steering, braking and obstacles. The service software has a different safety job: accepting only rides that can be completed, and behaving sensibly when something goes wrong.

The cart checks the route before accepting

Before a cart takes a ride, it should confirm it can actually serve that trip on its route. Accepting first and failing later leaves riders stranded at a stop.

Riders see the reason for a refusal

If a cart cannot take a ride, the rider should see why in plain words, not a spinner that never ends. A clear reason lets them choose another stop, try again later or decide to walk.

The boarding timer runs on the vehicle

Mobile signal on large sites is often patchy. If the boarding countdown lived only on a server, a dropped connection could leave the cart unsure whether to wait or go. When the timer runs on the vehicle itself, it keeps working without signal.

No link to the driving computer, no new rides

The service software talks to the cart’s onboard self-driving computer. If that link drops, the cart should stop taking new rides until it is restored, rather than accepting bookings it may not be able to carry out.

Private, invite-only fleets

On most closed sites the shuttle is for guests, students, patients or staff, not the general public. Private fleets that riders join by invitation keep the service for the people it is meant for. In Axons Mobility, self-driving fleets are always private.

Should shuttle rides be free or paid?

Closed-site shuttles usually follow one of two fare models:

• Free and operator-funded. The site pays for the service as an amenity: part of a resort stay, a campus service or staff transport. Riders never see a price, which removes friction completely.
• Flat fare. Every trip costs the same, whichever stops the rider picks. It is easy to understand and helps cover running costs when the site does not want to fund every ride.

Distance-based pricing makes less sense on short, fixed routes. Whichever model you choose, the software should let you set it per fleet, so a staff fleet can ride free while a visitor fleet pays a flat fare.

Free-floating sharing vs stop-to-stop shuttles

If you run shared scooters or bikes on public streets, the free-floating model and its tools are covered on the shared scooters, bikes and mopeds page.

What should you ask an autonomous shuttle software provider?

1. Who does the driving, and who does the service? Be clear which part is the cart’s self-driving system and which part is the software around it. Each side should own its part.
2. How does it connect to our carts? Ask how the software talks to the onboard computer and what happens when that link drops.
3. How are routes and stops set up and changed? Adding a stop for an event or closing one for works should be a quick job, not a project.
4. What happens without mobile signal? Ask specifically about the boarding timer and ride status.
5. Can we control who rides? Private, invite-only access matters on most closed sites.
6. What does the rider see when something fails? A refused ride, a delayed cart or a cancelled booking should all come with a clear message.
7. Which fare models are supported? Free, flat fare, or both, set per fleet.
8. Where is data hosted, and who can see it? Rider locations and trip history are personal data.
9. What is working today, and what is still planned? Ask to see it running, and ask how early sites are supported.

Where does Axons Mobility fit?

Axons Mobility self-driving shuttle software is in beta, and we are working closely with a small number of sites. The split is simple: the cart’s own onboard computer does the driving, and Axons Mobility runs the service around it: hailing, stops, the live map, the boarding safety timer and fares. The safety design described above, from the route check before a ride is accepted to the boarding timer on the vehicle, is part of that service. It sits on the same platform as the Axons Mobility operator console, and privacy is covered on our security page.

If you run a resort, campus or other closed site with self-driving carts, or plan to, you can join the self-driving shuttle beta and tell us about your site, your carts and the stops your riders need.