Hacker News Reader

Comment by systemtest | Hacker News Reader

I recently had a discussion about how hard it would be to have a system inside a bus to announce the next stop. Sounds like a weekend project right?

Think a bit further:

- Hardware needs to be resistant to harsh diesel engine vibrations

- 3G/4G connectivity

- Need a mobile data contract with local ISP

- Software needs to be able to handle network disconnections

- GPS needs to be able to pin-point at which stop the bus is currently stopped, even with bad GPS coverage in larger cities

- If the bus skips a stop because of a detour, the software should be able to detect it and announce the next stop

- The announcement should be bi-lingual for Airport busses

- The announcement should work for people with hearing aids

- Server needs to know all bus-stops

- Server needs to know different stop types, such as bus terminals, intersection stops, regular stops, hand-over stops, virtual stops

- Server needs to be able both work of a yearly bus schedule and real-time update

- Server needs to output in an understandable JSON/XML because the government subsidies demand an open-data format

- Server needs to publish data to an open-data server because of the subsidies

- Because the bus-company is sponsored by European Union money the control interface should be translated to German/French/English/Spanish

And now this weekend project takes a team of 10 engineers working for a year.

View on HN

All London buses do this. I don't think you need a server, 3G/4G connectivity or even GPS really. You might be over thinking it.

On the other hand, the overthinking in question (which is probably true for bare-bones next stop indication) provides the base for my personal bus bug: know if/when a bus is reaching a stop from outside the bus in question, especially with geofencing, in order to know whether the bus I want to take is running early/late/not.

They actually do this as well (and many have live updating signs), so the buses do have GPS linked to a server of some kind. It's normally absolutely fine, but on the couple of occasions for me where it broke it seems that the server doesn't conduct the bus in any way and kind of hopes the bus is on the right route.

That's all speculation though.

> They actually do this as well (and many have live updating signs)

I don't know about London, I've seen some systems where the stops had "live-updating signs" but only provided the time of the next official passage. And while I wasn't clear, my bug is not just stop signage but phone access as well (that's most useful when e.g. it's raining cats and dogs and you want to avoid waiting in the rain at uncovered bus stops)

There's a standard by Google for transit timings, and Translink, the public transport authority in my state, outputs these times. They're live.

Apps like 'Transit' also (accurately) show the current GPS location of the bus as it approaches, and it updated every minute (I believe)

In London you can go to the TFL website and see live updating times for when the bus will get to your stop: https://tfl.gov.uk/travel-information/stations-stops-and-pie...

OK, that's really cool. Definitely means they have "a server, 3G/4G connectivity [and] GPS" though.

Not necessarily. I think some of the systems use radio links to a central location and transponders at fixed points on the route to track the buses.

Oslo, Norway has realtime data available for all stops as well :)

http://reisapi.ruter.no/Help/Api/GET-StopVisit-GetDepartures...

>Returns a List of StopVisits (departures) from a Stop. If no time parameter is supplied, departures in realtime will be returned.

There is an API for London: https://api.tfl.gov.uk/

The TFL system will remove a bus if it doesn't get an update often enough that includes actual progress on the route. This is in fact the opposite problem of what you mention, in that they don't do a very good job of predicting based on past performance. E.g. I used to take a specific bus to pick my son up from nursery that always would "disappear" for a certain number of minutes at a certain part of the journey because a very short stretch of the route was always extremely congested at that time of day.

It's a tricky one, because they have big concerns about over-promising (e.g. the bus could be stuck behind an accident instead, in which case guessing that it's 5 minutes away because of past behaviour will really annoy people) so in some situations they err on the side of caution.

But they are unable to get rid of all of the corner cases. E.g. a bus that moves rapidly for a short stretch, then gets "stuck", will often appear, disappear, appear, disappear, with much less progress in time estimates than elapsed time should indicate.

The thing is, the team working on it has a huge amount of gathered info on how to give these predictions in a way that tries to minimise surprise and avoid making promises that cause problems for people. E.g. often it's better to take a bus off the list so people who are in a hurry will grab a taxi, rather than "promise" the bus will be there in just another few minutes. They still get it wrong too often, but I really don't envy them trying to get the right balance between promising too much and too little.

This is available for public buses in NYC. The city added GPS to their buses and then the ability to query distance from current stop via SMS.

Then they opened their APIs, and now I have a half dozen apps to choose from that will show the approximate time until the next bus from a particular line will reach any given stop.

(Not always 100% accurate, but useful enough to know when to wait indoors for 5 min if it's raining, or pick another line/choose to walk because of delays.)

>know if/when a bus is reaching a stop from outside the bus in question, especially with geofencing, in order to know whether the bus I want to take is running early/late/not.

We had that, through GPS + GPRS (or SMS?), back in 2001-2 in a small city I was living in Europe. Complete with full (flash based) website map of where each bus is.

I used it to get out of the tech park/institute I worked at and into the bus stop outside at the very last minute (since bus timetables where completely unreliable).

GPS is insufficient to give accurate enough estimates these days. It may or may not work depend on your local routes and stops, but it's too imprecise for a lot of locations and traffic conditions to give decent precision. It's good as a "first approximation" and if you don't have anything better. Most systems today end up integrating data from multiple different sensors to improve on gps.

Many providers have an API for this. I used one in my city to build a very simple display that shows you bus times (and I put it in a toy bus):

https://i.imgur.com/LjV7MtB.jpg

Sydney even uses the electronic ticketing system to provide an estimate on the capacity of the bus.

Thats clever. Most public bus systems I know in the US still see frequent cash payments onboard (the elderly, mostly). Is this not the case in Sydney, or is the system cashless?

Over the past few years they've rolled out a new electronic ticketing system which is used exclusively.

On some bus routes (and/or outside of peek times) you can pay a cash fare on the buss, but even that is still a single-use paper RFID card that should be tapped on and off. These sales are in the extreme minority though - the elderly require an electronic card to get their discount IIRC.

Really?! Where can I see this? On an app? I admittedly only use Google Maps when I'm in Sydney.

TripView has it.

This is the only thing I want. Displaying a bus timetable can be done just fine with laminated paper, and I'm not convinced that the ability to update (with cancellations, route changes, etc) justifies a tech solution.

Displaying the actual bus status, though, is huge progress.

Halifax, NS, was doing that in the mid-'80s without the benefit of GPS or handy mobile apps. (Every bus stop/route had a phone extension, and major stops/terminals had talk boxes.) Granted, it wasn't a huge system, but it was hitting rocks with sticks and hollering over tin cans and string compared to what's available as a starting point today, and it worked. The idea that it should be a hard problem today, given GPS, vastly improved wireless communications and eleventy-seven different ways of figuring out where a user is (if entering a stop code seems like it might be too much work) is just plain silly. Or we've significantly redefined what "hard" means.

Or expectations have increased, both in terms of accuracy and in keeping costs low.

Consider that e.g. in London the old route indicators on the buses used odometers. Which worked for telling you were along the route a bus was. Most of the time. But didn't tell you how long it takes until the bus reaches the next stop other than on average, as it would tell you nothing about traffic etc.

Today London buses don't use just GPS to replace it either, because that's nowhere near good enough. See the "Tracking" section here [1].

https://en.wikipedia.org/wiki/IBus_(London)

When I said "worked", I meant worked, not approximated working or came lose enough not to have caused too many upsets. If expectations have grown to be higher than plus-ten-second accuracy (early wasn't tolerated), then we collectively need some sort of counselling/therapy.

You don't get that kind of accuracy in any system that has to deal with congested roads, or any dense major city. E.g. there's plenty of bus-stops near me where stops on the same route involves going around corners and traffic machines and stopping close enough that GPS would be insufficient to be guaranteed to tell the stops apart if you don't get a good enough fix on additional satellites quickly enough.

Even with all the extra data, and a lot number crunching, in London it's a challenge to get it to withing a few minutes during rush hour.

So, sure, if you're dealing with simple, small systems with little congestion, you can simplify.

German bus drivers have it as well. The routes are lists of stop names and their change is triggered by opening the doors. Can be adjusted by the driver if stops are passed, etc.

Runs on some windows if I remember correctly and routes are probably hardcoded along with the data for the segment display outside above the windscreen.

Many cities also have an app that displays how many minutes the bus is expected to run late, based on when it passed the previous stop.

what about the bus stop broadcasting a signal with the id, name etc? the system is activated by the proximity..so you can have smthing like approaching station A, leaving station A.

it is scalable because the bus-stop transmitters are added , moved, removed as needed.

updating the data can also be done remotely

That's more expensive because the cost (installation and servicing) scales with the number of bus stops.

Also, there are things you want to do that this doesn't cover. For example, announcing the next stop when you pull away from the last stop.

The announcing the next stop could be achieved with a dual radio setup, one high powered and low powered. The high powered could be used to detect an upcoming stop and the low powered could be used to detect proximity to the stop.

(Lets ignore the security issues that have been shown with amplifying the low powered radio in cars for a second) It's a method used in keyless entry in cars. A higher powered radio is used for button press on the cars key so you can unlock the car/open the boot/sound the horn to locate the car at a distance but keyless unlock should only work at a much closer distance.

Not saying its the correct way to do it (my local bus network doesn't do this) but stop proximity can be worked into their idea.

My local bus network use M2M Sim's running on the Vodafone network but its basically a virtual private mobile network running on top of Vodafone's network with no connection to the internet.

These connections are in both the busses and the stops. The reason is so the stops can provide real time updates to people at the stops too. If a bus breaks down its no longer tracked on the real time updates so you are not effing and blinding because a the stop said there is a bus due in 5 mins and no bus comes. And if a bus is removed from service unexpected then the information on why can be feed to people waiting for the bus. People are less likely to be pissed that a bus didn't come when expected if they are given a valid reason.

Personally I was hoping they used some form of radio link I could of sniffed with a SDR so I could put a live updating sign in my house. I just scrape the data from their live feed they use to update the tracker on their mobile app/website instead.

Broadcasting out a signal from the stops could need a transmitter that may need to be licensed as the signal would be to be picked up quite a distance from the stop. Also not all the stops in my area are these "real time updating" stops as they are normally put into covered stops (EDIT: Bus Shelters... The correct term wouldn't come to mind while I was typing this.) and some of our stops are just poles in the ground with a sign on them. The busses tracking their own position wouldn't need these stops upgrading to give this information to people on board the bus as the covered stops can be quite a distance between each other and removes any issues if a stop get damaged and stops broadcasting data (say a car crashes into it).

The busses tracking themselves also have benefits that don't visibly benefit passengers. The services back office can monitor busses and spot problems on the network as they happen. Unexpected heavy traffic on a route may trigger the company to skip or stagger a bus (one of my local routes in advertised as being "every 5-10 mins". The real time traffic condition information could also be sold on to other companies (not sure on the value of this data esp for busses that run once an hour or even longer).

There are systems that solve Bus shelter problem by piggybacking on FM station RDS

http://www.windytan.com/2013/11/decoding-radio-controlled-bu...

I was surprised my local network didn't do something similar as it seemed like a logical choice. But after some research I found nothing about them using RDS to do this.

I would love to be able to talk to a tech at the travel network about this. My own research came to the suspicion that because where I am in the country they would of had to strike up deals with multiple transmission sites to get the coverage needed.

you need it. what if you want to connect to something and make some special announces.

What special announces? Either the bus driver does it or it's one that's used frequently (like 'Please move down inside the bus'), in which case there is a button for it.

They use GPS receivers on the bus, which calculates the position then transmits back using GPRS for central reporting https://en.wikipedia.org/wiki/IBus_(London)

Same in Munich. I think those work offline, also the driver can pick the next stop.

I guess it is easier in the long run to have all routes mapped and instead of GPS you use something like doors open / doors close as a trigger to jump to the next entry.

I work part time at the company that manages the new style signs for bus stations (EDIT: in London, to be clear), so we've gotten to see a bit of the size of the operation TFL has to deal with gathering and processing the bus information. He might have some details wrong, but he's certainly not gotten the complexity level wrong.

The GPS and mobile data are overthinking it. The routes are known so simply trigger on door open/close (with some logic for denounce/etc) and cycle through.

For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.

And the entire data set for the route should be able to live offline onboard the bus. Changing bus/numbers routes should include the step for updating route data.

Except that quickly becomes inaccurate if the bus driver decides to re-open the doors for an incoming passenger, or due to traffic conditions, opens the bus doors further from the stop than the beacon reaches. Or skips a stop due to road conditions.

1. Set a minimum time until next stop can be announced 2. Add a button to skip a stop

And then when the driver accidentally hits the button and needs to go back?

Notice how we're now adding more complexity now anyway though...

RFID like chips on bus stops too, maybe?

While active RFID is possible, other radio tech designed to work as beacons is more likely

Consider a bus stuck in traffic. It is not unusual, at least in London, for a driver to open/close the door multiple times between stops when traffic moves slowly enough, often with longer intervals in between than there usually would be between stops.

> Set a minimum time until next stop can be announced

This feels like a dangerous hack that will come back to bite you in any number of unexpected scenarios that probably occur frequently during an average bus driver's day.

Bluetooth beacon (estimote?) at stops would help.

For an robust system I would use multiple data streams including bust status data/beacons/GPS. I've seen busses with offset stations.

3G is necessary for live ETA, if you want to get fancy. All these complications, in my view, are worth it if you want a system that works 24/7 and serves thousands of people daily. The HW and SW dev costs are acceptable, but it does need a decent team, depending on what the starting point is and the ability of the team members.

changing bus/numbers routes manually is not feasible. in complex networks this happens daily a hundred times.

I'm confused, are you suggesting there are places where bus routes change hundreds of times a day?

I can't imagine many reasons a route would have to change on short notice (accident blocking a road?), and in those situations the announcements not quite being right would not be the end of the world.

Buses are often assigned to a route and then leave that route unexpectedly in the middle of the day to service another route (accident, other bus broke down, traffic, subway shutdown etc) , often not starting at the beginning of that route.

Oh right, that makes more sense. I guess you could just keep a record of all the different routes in every bus though? And skip to the right spot manually as needed.

Then the bus changes its route number - certainly in the UK I see the drivers punching in the route details when they take over a bus.

I've worked in transit. This is not only feasible, it is how it is done.

cannot see why you would want to do it manually. it is done automatically in munchen.

> For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.

Yeah, and now we need to install and manage thousands of beacons in bus stops in pretty hospitable conditions.

Of course, GPS isnt perfect either. It tends to fail in CBD areas.

This has all kind of usability issues (now you're expecting the driver to pay attention to and correct mistakes), while providing less accurate data (buss pulls away from stop, gets stuck in traffic; estimates at next stop are based on the bus having pulled away and average times; customers gets angry) and less ability to do traffic management (e.g. spacing out buses by slowing down later buses slightly) without having drivers guessing and reporting data back.

> For maximal accuracy simply have an electronic beacon of any sort broadcasting an ID that corresponds to the stop and you've got it solved.

That's not remotely accurate for the reason above.

> And the entire data set for the route should be able to live offline onboard the bus. Changing bus/numbers routes should include the step for updating route data.

It can. E.g. the old London system used odometers. But that was sufficient only for showing "next stop ..." and for reporting very rough estimates. Today it uses odometers, gps, rate gyros and turn rate sensors to be able to more accurately position the buses along a route, and they still regularly "give up" and take a bus off the schedule when traffic conditions means the uncertainty is too high.

One of my "fights" at work is prototypes. A prototype can be build very quickly (cheaply) and can exhibit many problems that may be overseen by the "heavy design process". A prototype is a marvelous way to get feedback from users very early in the projects.

The only downside to prototypes is that then the managers don't understand why the actual project takes so much longer and end up asking to just go with the prototype for production.

Get better managers.

I've never had this problem.

>- Hardware needs to be resistant to harsh diesel engine vibrations

That's a non-issue.

>- 3G/4G connectivity, need a mobile data contract with local ISP

This is a duh!

>- The announcement should be bi-lingual for Airport busses

It can always not be. How would that be worse than NOT having the announcement at all? Besides what would the other language be? French, German? That would still be useless to 90% of foreign visitors...

> Besides what would the other language be? French, German?

I guess the names of the stops are untranslatable anyway :)

Canada. Here it would need to be bilingual by law.

umm I travel in GO and DRT everyday. Neither have bilingual announcement. Same with Mi-way.

Sorry, meant Montréal.

This exists in offline versions.

I think it just counts the number of stops and has some input from the driver

But, adding the wireless connections and the servers and the technical staff to code and maintain, would save the driver the labor of pressing the button. That's what technology is for.

It could just use the open the doors button with some hysteresis for opening/closing doors few times in a row in some short time.

KISS applies here. By keeping the 'driver presses a button' interaction, the complexity is reduced by at least a factor of 5, and the TCO ends up being much less.

Sometimes, a doorbell just needs to be a doorbell.

Sure but if I add all the above complications then I get automated bus tracking system where everyone on their phone can see where the bus is and when it's arriving, I can track and automatically detect issues with traffic, with the bus, with the driver.

Sure you can do the simple announce but the even easier one is to just have the driver talk over a mic, he needs one anyway. There I one upp'd you on KISS. But there is a reason not to KISS.

You can publish wireless / Internet data on where the bus is, but keep the driver pressing buttons as the source of the data.

That's how it works in our (German) city. It works great.

How often do you want the driver to press buttons? And how do you mark the intermediate positions in between bus stops? Because on any remotely complicated high congestion route, you will not get reasonable estimates if you only update at bus stops.

I think you missed the implied /s

I think the GP was being sarcastic ;)

but the driver forgets to press the button and then people are affected. ah, was that my stop, why wasn't it announced?

That's why bus drivers get training. And if they don't perform as expected, it's not that hard to hire a better one.

I am so glad you said this. With the boom of the tech industry, it feels like a lot of stuff is getting over engineered these days. Instead of products that focus on something that does it really well, it does its job mostly alright with half-broken bells and whistles.

Except asking a bus driver to keep track of button pushing is distracting and could endanger the lives of the passengers or people outside. The stop needs to be announced 30-60 seconds before they arrive at the stop so then is driver is still actively driving. This is something the drivers union would be all over, it's not as straightforward as you assume.

The stop needs to be announced 30-60 seconds before they arrive at the stop

Why? You can announce the next stop a few seconds after departing from the current stop, and then again at the opening of the doors.

If there's a long gap between the stops, people may forget what's the next stop. Announcing at the opening may be too late or the stop has to be long enough. Even for slow passengers in a crowded bus. Announcing a minute before the stop is a good heads-up that bus is approaching the stop and people should prepare.

Then make the delay for the announcement of the next stop adjustable, configured according to the timetable.

A skilled engineer weighs the costs and benefits of a system before architecting it.

Is it more economical to pay for constant cellular connectivity across 1,000 buses, support IT staff for when the system fails or needs upgrades, etc. or to have the guy you're already paying $15/hr press a button after each stop?

At least on most UK buses, the driver already needs to tell the computer where on the route the bus is so that it can issue the correct tickets to customers. This has been the case for decades.

Check out APRS[0]. Solves most of the above already by centralizing data-collection. Would just need a beacon on every vehicle. No need for internet connectivity. Receiving stations can be scaled up as required. Logging of course not an issue as can be logged on-board and/or externally.

The on-board display can overlay a map and call the next stop based on proximity. Not a weekend project, I'll admit, but many existing moving parts available off the shelf.

Hams play with this stuff... a lot.

[0] https://en.wikipedia.org/wiki/Automatic_Packet_Reporting_Sys...

I don't think anyone would have assumed that you can build such a system in a weekend.

Half of your points assume that current transportation companies don't have any digital data about bus stops and reroutes.

Anyway I haven't been in a bus that doesn't have such a system for at least for a few years (in western Europe and China).

> Half of your points assume that current transportation companies don't have any digital data about bus stops and reroutes.

The question is what is more work: Using the existing data that is stored in some obscure format for which you first have to write an importer/converter or just recreating the data. Add the fact that the existing data might need some cleanup/additions (e.g. times on timetable are only stored with minute precision and you want second precision for more accuracy).

Alternatively, you could have the driver press a button.

Far more useful is the system which tells you, at the bus stop, what the ETA of the next bus(es) is. And that really does need the whole GPS+data system, along with physically robust signs. But on the other hand, that can still be done by a small company - I know there's one here in Edinburgh but I can neither remember their name nor find them in a search.

You can do quite a lot with a small local company. It's global reach that's expensive, as soon as you start needing any kind of high-touch sales.

You can do this with a RPi and a RFID reader. Every station would have a tag, when bus stops tag is read and your script just announces the station.

You generally want to make the announcement before the bus stops so that people can be ready to get off when the bus stops. Also buses don't always stop at every station on it's route so have to deal with what happens when stop is skipped.

You can certainly do it with an RPi - although you might have to keep rebooting it every hour or so. :)

GPS and 3G/4G are trivial add-ons. There are stacks for mobile data.

RFID doesn't have the reliable range, so that won't work as a solution.

It's not really a hard problem for a competent small engineering team with a mix of embedded hardware and software skills. It's not quite a trivial problem, because there are some interesting edge cases, mostly when a bus is diverted. But there is absolutely zero rocket science required.

You could hack something unreliable together in a weekend, but it would take up to six months to get all the bugs out, do the production engineering for a bullet-proof solution, standardise the installation process (if retrofitted), and so on.

Double that if management is poor. :)

Those last parts often get forgotten in software. Hacking something together that kind of works if you don't look at it with a visible frown is hobby coding, not engineering. Engineering is the boring work that happens after that, to build something with a quantifiable many-9s uptime that meets or exceeds a standard spec with comprehensive test cases.

That sounds expensive.

Usually the announcement is not "we have stopped at Foo and Main". The announcement is "Next stop Foo and Main" while you're on the way to it, so you have time to sling your bag back over your shoulder, get your coat back on, and make your way towards the door. Depending on the density of stops along the route this can come anywhere from 1-7 blocks ahead of the stop.

Source: I don't drive,and ride the bus a lot.

Complicated, but not that bad... just need to optimize for the worst case and the best case will purr along happily.

Some sort of near-field beacon on the stops might be more durable than relying on GPS, but it won't help with missed stops.

This seems like a problem that has been solved many times in the Western world.

Or... microphone and speakers for the driver to announce the stop. If you'd like visual indicator too (accessibility FTW!) plenty of low tech and/or cheap solutions that would meet the requirements.

> Or... microphone and speakers for the driver to announce the stop.

Breaks down quickly if you need bi- or tri-lingual announcements, which is the norm in many popular tourist destinations.

Laminated card in the cab with phonetic spellings for the other languages.

Aside: I'm impressed with the amount of bike-shedding for this one. Though I'm part of the problem, too :-)

Ha, indeed. Just thought of another - even lower tech - a printed list of all stops, visible to passengers on the bus, then clear signage for each stop. If the bus stops every stop by default, then this is simpler, if not then the passenger needs to be able to see this on the approach, with another time to signal that they want to get off. Can this get even lower tech?

Really? Either it's a location 'Piccadilly Circus' or its a place type 'Airport' - any of those can easily be learnt by the driver. Or writen on a printed sheet that they can easily see. Don't jump to making it more complex than it needs to be.

I see you have never tried it in practice. Train conductors in Austria/Czechia/Germany – which tend to be more trained and less busy than bus drivers – tend to stumble around for half a minute for each unintelligibly badly pronounced sentence. Even the pre-recorded messages in buses are of so bad quality that tourists prefer asking other passengers rather than trying to figure them out.

You've just described a cellphone running apps that already exist.

> And now this weekend project takes a team of 10 engineers working for a year.

More like 2 guys working for a month.

I'd say ~ 5 Engineers working for ~ 3.5 months

(I calculated the geometric mean of the numbers both of you have given, in case you're wondering ;) )

Generallly my approach if engineers disagree significantly on a timeline is to multiply the worst case estimate by a large factor, on the assumption that odds are good it means neither one has a clue what the actual complexity is if they don't manage to get to rough agreement...

Absolutely impossible. There is hardware involved.

I'd say something like 3 people for 6 months to 1 year (not all 3 being needed 100% of the time).

You are massively overthinking the problem. The very first system of this type I saw didnt even have a microcontroller. Just an eprom for driving LED array, bunch of TTL logic and two inputs. One linked with 'open doors' switch, the other going to undo switch. And it worked fine for couple of years in a >million city.

But nobody wants that. They want conductors back. This is not a problem with a technological solution.

> They want conductors back

That's just faster horses though.

Conductors aren't a solution to a problem in themselves, they're a means to solve a problem. So what's the actual problem? WHY do they want conductors back?

Move to China, every bus in Shenzhen has a lady conductor.

Reply on news.ycombinator.com