Ask HN: Anyone making software for kiosks, infotainments or similar?
How is it?
What is your company’s business model and what is the sw/hw stack you use?
55 comments
I work on a team building an application that displays real-time predictions/service alerts and other stuff on various types of strictly non-interactive screens posted around the MBTA’s* bus and rapid transit network.
Like others in the comments, we use a pretty straightforward architecture—our backend is written in Elixir and the frontend is rendered as a webpage with HTML/TypeScript/SCSS. We also use AWS Polly for on-demand readouts of the same content. The client periodically requests new data from the server—no web sockets involved for now.
The kiosk part is pretty basic; most of the interesting problems we face are related to the fact that we support a large variety of screen types/formats and need to strictly adhere to ADA guidelines (for both type size and audio equivalence). Screen types include solar-powered e-ink, portrait mode 1080p LCD, twin side-by-side portrait LCDs, and a set of screens owned by an ad vendor, on which our content appears in a rotation alongside ads.
The codebase is open-source! https://github.com/mbta/screens
* (Massachusetts Bay Transportation Authority)
Like others in the comments, we use a pretty straightforward architecture—our backend is written in Elixir and the frontend is rendered as a webpage with HTML/TypeScript/SCSS. We also use AWS Polly for on-demand readouts of the same content. The client periodically requests new data from the server—no web sockets involved for now.
The kiosk part is pretty basic; most of the interesting problems we face are related to the fact that we support a large variety of screen types/formats and need to strictly adhere to ADA guidelines (for both type size and audio equivalence). Screen types include solar-powered e-ink, portrait mode 1080p LCD, twin side-by-side portrait LCDs, and a set of screens owned by an ad vendor, on which our content appears in a rotation alongside ads.
The codebase is open-source! https://github.com/mbta/screens
* (Massachusetts Bay Transportation Authority)
That's basically what I did for some screens around the office (before covid sent us to remote work) - elixir backend with a raspberry pi on the back of each TV, then Drab[0] to update the screen over websockets (liveview wasn't a thing then IIRC)
[0] https://tg.pl/drab
[0] https://tg.pl/drab
Worked on a kiosk for the Pacific Oil Conference in 1982 for Gasboy, Inc.
Using Radio Shack Model ][ (with 8” floppy drive). and BASIC/Z80-assembly, a snazzy interactive presentator for those different kinds of folks (tech, CxO, finance, sales).
alongside the hands-on demonstrator and specification of the first credit card payment pad on the gasoline pump.
Instant sell out. Rich, too ($10,000/month back then or about $30,707/mon. today’s value.). Once bought out, royalty dried up. Fun while it lasted.
so, BASIC did my kiosk/infotainment and the key was making it robust enough as well as deep menu scoping with quick timed-out home menu for a large breadth of an audience. Took about 5 people busy writig content while I was programming onto a floppy.
Using Radio Shack Model ][ (with 8” floppy drive). and BASIC/Z80-assembly, a snazzy interactive presentator for those different kinds of folks (tech, CxO, finance, sales).
alongside the hands-on demonstrator and specification of the first credit card payment pad on the gasoline pump.
Instant sell out. Rich, too ($10,000/month back then or about $30,707/mon. today’s value.). Once bought out, royalty dried up. Fun while it lasted.
so, BASIC did my kiosk/infotainment and the key was making it robust enough as well as deep menu scoping with quick timed-out home menu for a large breadth of an audience. Took about 5 people busy writig content while I was programming onto a floppy.
I have worked on automotive infotainment systems, set top box and UI for certain kitchen appliances at various jobs before.
Some companies were taking contracts for big name companies, while some produced their own dashboards/hardware. The tasks start becoming repetitive after a while though.
Tech stack in almost all those places has been:
* Embedded Linux (Buildroot/Yocto) / rarely QNX.
* C++11 + Qt/QML/QtQuick for UI ( case study: https://www.slideshare.net/BurkhardStubert/qt-dd2014-casestu... ). We did prototype an application using Qt Webkit, but the performance was meh and we moved back to QML. This was in 2013 iirc. Things might have gotten better these days. It has almost always been 1 main UI application - so we didn't even need a window manager. We booted straight to the main application in 2-3 seconds and then used Qt's eglfs to render to full screen directly.
* Developers were free to implement other services (Notifications demon, Recovery/OTA system, logging etc...) needed by the main application in tech of their choice. We mostly ended up using C++ because that's what most of us were experienced in, and also meant less bloat/messy integration. Sometimes shell scripts.
Hardware has always been some NXP iMX6 variant.
None of those devices had any internet connectivity and Software updates meant using a usb stick etc... So never got to try out something like balena for OTA updates.
Some companies were taking contracts for big name companies, while some produced their own dashboards/hardware. The tasks start becoming repetitive after a while though.
Tech stack in almost all those places has been:
* Embedded Linux (Buildroot/Yocto) / rarely QNX.
* C++11 + Qt/QML/QtQuick for UI ( case study: https://www.slideshare.net/BurkhardStubert/qt-dd2014-casestu... ). We did prototype an application using Qt Webkit, but the performance was meh and we moved back to QML. This was in 2013 iirc. Things might have gotten better these days. It has almost always been 1 main UI application - so we didn't even need a window manager. We booted straight to the main application in 2-3 seconds and then used Qt's eglfs to render to full screen directly.
* Developers were free to implement other services (Notifications demon, Recovery/OTA system, logging etc...) needed by the main application in tech of their choice. We mostly ended up using C++ because that's what most of us were experienced in, and also meant less bloat/messy integration. Sometimes shell scripts.
Hardware has always been some NXP iMX6 variant.
None of those devices had any internet connectivity and Software updates meant using a usb stick etc... So never got to try out something like balena for OTA updates.
I did for a while. Mostly fun one-offs for popups and events rather than practical applications. Once I got a taste for it I tried seeking a career in it but there's just very few places doing it and I wasn't able to get my foot in the door. The market exists but it's small.
I can also tell you it's really not rocket science. We built UIs the same way we build anything else. A lot were just web pages with a machine locked in Chrome kiosk mode. Some were Electron or Unity if we needed razzle dazzle. You can get all kinds of off-the-shelf devices control lighting or read input from all kinds of sensors that just go in a USB port. You can rig stuff with microcontrollers but for a commerical project, you can buy bulk devices purpose-built for whatever task.
I can also tell you it's really not rocket science. We built UIs the same way we build anything else. A lot were just web pages with a machine locked in Chrome kiosk mode. Some were Electron or Unity if we needed razzle dazzle. You can get all kinds of off-the-shelf devices control lighting or read input from all kinds of sensors that just go in a USB port. You can rig stuff with microcontrollers but for a commerical project, you can buy bulk devices purpose-built for whatever task.
I've been doing one-offs as a freelancer for 10-15 years, though it has never been my sole focus/career. I think once you start landing some gigs and build a network, similar work will find its way to you. As much as it's a small niche with not very much demand, there isn't much supply or competition. The thing that helps with word of mouth with physical installation work is you can end up with something visually striking to show colleagues or prospective clients.
It's how I got my "real" start in the tech industry
Currently work at a self-driving car company working on interfaces for passengers to interact with a driverless vehicle
In the past I worked at an agency that specialized in kiosks for clients who didn't necessarily have the skillset or experience to deploy hardware to stores (Google Nest was one of our customers, and iirc they had some internal grumbling about owning Android but paying us to deploy Android-based kiosks)
One place I worked at had a very meteoric rise and fall. Their business model was selling a premium spin bike with an Android tablet attached (you can guess which company this is)
The common thread is "Android for HMI", and it's the niche I've based my career on.
Currently work at a self-driving car company working on interfaces for passengers to interact with a driverless vehicle
In the past I worked at an agency that specialized in kiosks for clients who didn't necessarily have the skillset or experience to deploy hardware to stores (Google Nest was one of our customers, and iirc they had some internal grumbling about owning Android but paying us to deploy Android-based kiosks)
One place I worked at had a very meteoric rise and fall. Their business model was selling a premium spin bike with an Android tablet attached (you can guess which company this is)
The common thread is "Android for HMI", and it's the niche I've based my career on.
Aside: Our local Taco Bells were a trial for ordering kiosks ~25 years ago. One of my friends worked on it. According to him, a significant contributor to the failure of the project, at the time, was that they didn't want to spend money on industrial PCs, and grease and commercial PCs don't get along very well together.
They were shockingly similar to the kiosks that got deployed at the same location ~3 years ago.
They were shockingly similar to the kiosks that got deployed at the same location ~3 years ago.
I was visiting a lot of Europe a few months ago and 90% of the fast food restaurants have moved exclusively to kiosk ordering. One thing I noticed is that the kiosks are all set back a good distance from the kitchen.
A McDonald's I stopped at had a row of kiosks against the wall lining the entire length of the restaurant; probably 10 kiosks 3-4 feet apart. I'm curious if they discovered the same thing about grease when installed on/close to the front counter.
A McDonald's I stopped at had a row of kiosks against the wall lining the entire length of the restaurant; probably 10 kiosks 3-4 feet apart. I'm curious if they discovered the same thing about grease when installed on/close to the front counter.
I built a wheelstand kiosk that’s still in use. Really just brochure-ware (wheelstand is the stand next to a car or equipment at a trade show or dealership).
Web app using Elm on the client side with a simple iOS webview wrapper and provisioning via remote MDM + apple’s enterprise store.
The sole purpose of the wrapper is to lock it down, and launch on start. I’d just use a kiosk app instead though if I had to do it again and try to avoid the whole MDM and Apple enterprise stuff… major pita.
Elm for the client side has been absolutely bulletproof and maintenance free. Adding random feature requests has been enjoyable. Highly recommend.
Web app using Elm on the client side with a simple iOS webview wrapper and provisioning via remote MDM + apple’s enterprise store.
The sole purpose of the wrapper is to lock it down, and launch on start. I’d just use a kiosk app instead though if I had to do it again and try to avoid the whole MDM and Apple enterprise stuff… major pita.
Elm for the client side has been absolutely bulletproof and maintenance free. Adding random feature requests has been enjoyable. Highly recommend.
I am also a big Elm fan, especially due to the maintainability as you mentioned. But I have never worked with it in a production environment. Just in case you were working with a team on this project, how easy was it to convince the rest of the team to hop on the Elm train? Have you encountered any shortcomings while using Elm in production?
I develop perhaps the most affordable family tree and organigram software. "Kiosks" in under-developed countries offer customers the option to create their family tree with it. Since it's collaborative, free, and cross-platform, customers can then share it with their relatives. The kiosk's cost can range from $0 to $12, no subscriptions charged
Front-end stack: Android and iOS: CN1, HTML5, java, obj-c Web: HTML5, js, wasm
Backend: nodejs, datastore (no-sql db), GCP buckets
6groups.com
Front-end stack: Android and iOS: CN1, HTML5, java, obj-c Web: HTML5, js, wasm
Backend: nodejs, datastore (no-sql db), GCP buckets
6groups.com
I previously worked at Intersection, an out-of-home (OOH) advertising company. Intersection does digital screens (displays and kiosks) in addition to traditional formats.
This is all public information that was previously shared, so it may be out of date: the devices are Linux (Ubuntu) [1], running an advertising player (Broadsign) [2], which has Chromium Embedded (CEF) for web content [3]. The kiosk app was written in React [4]. It does things like load most data ahead of time to provide that "instant" feeling [5].
[1] https://ubuntu.com/blog/digital-signage-the-face-of-the-smar...
[2] https://broadsign.com/blog/intersection-selects-broadsign-na...
[3] https://docs.broadsign.com/broadsign-ayuda/configuring-splas...
[4] https://mattj.io/posts/2019-02-12-building-smart-city-kiosks...
[5] https://mattj.io/posts/2019-07-09-improving-perceived-interf...
This is all public information that was previously shared, so it may be out of date: the devices are Linux (Ubuntu) [1], running an advertising player (Broadsign) [2], which has Chromium Embedded (CEF) for web content [3]. The kiosk app was written in React [4]. It does things like load most data ahead of time to provide that "instant" feeling [5].
[1] https://ubuntu.com/blog/digital-signage-the-face-of-the-smar...
[2] https://broadsign.com/blog/intersection-selects-broadsign-na...
[3] https://docs.broadsign.com/broadsign-ayuda/configuring-splas...
[4] https://mattj.io/posts/2019-02-12-building-smart-city-kiosks...
[5] https://mattj.io/posts/2019-07-09-improving-perceived-interf...
Thanks for the details. Do you have any ideal on why CEF was chosen as opposed to, say, WPE WebKit?
You'd have to ask Broadsign for an official answer.
Educated guess: WPE WebKit only supports Linux [1] and Broadsign supports more than Linux [2].
[1] https://wpewebkit.org/about/faq.html#is-wpe-ported-to-non-li...
[2] https://docs.broadsign.com/broadsign-control/latest/broadsig...
Educated guess: WPE WebKit only supports Linux [1] and Broadsign supports more than Linux [2].
[1] https://wpewebkit.org/about/faq.html#is-wpe-ported-to-non-li...
[2] https://docs.broadsign.com/broadsign-control/latest/broadsig...
I worked on a touch-screen gas pump terminal back in the late 90s. Was under a contract with a gas stations owner that did the numbers and realized that paying for a terminal will be less than what he was losing to the employee theft.
The terminal had a receptical for paper money, which was a crazy expensive thing back then, a massive touch screen (late 90s mind you!) and was hooked up to the internet through an X.29 modem. The pumps were controlled via a serial cable using a protocol that was documented just with a phone number of a guy who knew the details. Duck-taped the whole thing together, showed it off to the guy, he paid the balance in cash and then it was passed to the deployment guys, where it remained for a couple of years, because the client was assasinated (but lived) and had a subsequent change in life priorities.
Fun times. The stack was Windows NT.
The terminal had a receptical for paper money, which was a crazy expensive thing back then, a massive touch screen (late 90s mind you!) and was hooked up to the internet through an X.29 modem. The pumps were controlled via a serial cable using a protocol that was documented just with a phone number of a guy who knew the details. Duck-taped the whole thing together, showed it off to the guy, he paid the balance in cash and then it was passed to the deployment guys, where it remained for a couple of years, because the client was assasinated (but lived) and had a subsequent change in life priorities.
Fun times. The stack was Windows NT.
what country was the gas station in?
I had a kiosk software company for several years. Sold my part to my partners in 2008. We used Windows embedded for the hardware most of the time (until Mac Minis came out) and Flash for the front end.
I built out a Lua based server that lived on each of our units and communicated back to home base for updates using svnlib to grab changes. It was a pretty neat system, lots of hardware integrations and so on. Super fun. Lua was nice because its FFI is so pleasant to use. Flash was absolutely amazing for handling the UI. Our kiosks looked _so_ much better than all of the other hideous Motif-style UIs out there. Hell they looked better than most kiosks still look these days.
If you lived in Australia in the 00s and ever stepped foot in a Westfield or Stockland mall you'd have seen some of our kiosks.
I built out a Lua based server that lived on each of our units and communicated back to home base for updates using svnlib to grab changes. It was a pretty neat system, lots of hardware integrations and so on. Super fun. Lua was nice because its FFI is so pleasant to use. Flash was absolutely amazing for handling the UI. Our kiosks looked _so_ much better than all of the other hideous Motif-style UIs out there. Hell they looked better than most kiosks still look these days.
If you lived in Australia in the 00s and ever stepped foot in a Westfield or Stockland mall you'd have seen some of our kiosks.
I used to work for an avionics company’s in-flight entertainment (IFE) division for just one year. IIRC the business model primarily involved selling new systems to airlines to be installed into newly-delivered aircraft and secondarily upgrading those systems hardware, software and content.
The hardware stack involved PPC-based servers connected to what was essentially switches that serve groupings of 4-6 seats that distribute power and connectivity to what was essentially embedded low power x86 PCs with touchscreens attached (for the prior generation of hardware) or modified android tablets (for the current generation of hardware) all connected via Ethernet.
As for the software stack, everything ran a modified version of fedora Linux and sshd. For the seat-back units, they either ran an X11 server on the prior generation units or the android runtime for the current generation of units. Atop that the QML runtime ran 80% of interfaces on both generations that users interacted with. The other 20% were games and other 3rd party android apps we distributed typically not written in QML. There were also a few parts of the interface (diagnostic screens, etc) written using android widgets or IIRC qt (or perhaps even Xt?) and then maybe one or two legacy systems we supported which were written in the pre-QML era using android widgets , or Qt.
Often airlines would request content updates, which would include new movie releases (many of which were still in theaters. IIRC this was a selling point of buying a traditional IFE system over iPads since our company had a close relationship with several studios, acquiring the rights for films much quicker than other distribution channels). Content updates also included new or patched games and often updates to the UI with new commercial advertisements, new theming for a holiday or new language translation options. Most of this data needed to be loaded to the flash memory of each seat back unit (gui, games, commercials and a few movies) with the rest needing to be loaded to the head end units which there could be 2-8 all over 10/100 or 10-BASE-T Ethernet networks. This was cleverly done via libtorrent, installed on every unit. I was always blown away by the speed of these BitTorrent-powered content upgrades even on aging early- and late- 2000s embedded hardware and Cat3 Ethernet.
The hardware stack involved PPC-based servers connected to what was essentially switches that serve groupings of 4-6 seats that distribute power and connectivity to what was essentially embedded low power x86 PCs with touchscreens attached (for the prior generation of hardware) or modified android tablets (for the current generation of hardware) all connected via Ethernet.
As for the software stack, everything ran a modified version of fedora Linux and sshd. For the seat-back units, they either ran an X11 server on the prior generation units or the android runtime for the current generation of units. Atop that the QML runtime ran 80% of interfaces on both generations that users interacted with. The other 20% were games and other 3rd party android apps we distributed typically not written in QML. There were also a few parts of the interface (diagnostic screens, etc) written using android widgets or IIRC qt (or perhaps even Xt?) and then maybe one or two legacy systems we supported which were written in the pre-QML era using android widgets , or Qt.
Often airlines would request content updates, which would include new movie releases (many of which were still in theaters. IIRC this was a selling point of buying a traditional IFE system over iPads since our company had a close relationship with several studios, acquiring the rights for films much quicker than other distribution channels). Content updates also included new or patched games and often updates to the UI with new commercial advertisements, new theming for a holiday or new language translation options. Most of this data needed to be loaded to the flash memory of each seat back unit (gui, games, commercials and a few movies) with the rest needing to be loaded to the head end units which there could be 2-8 all over 10/100 or 10-BASE-T Ethernet networks. This was cleverly done via libtorrent, installed on every unit. I was always blown away by the speed of these BitTorrent-powered content upgrades even on aging early- and late- 2000s embedded hardware and Cat3 Ethernet.
I did about ten years back for a client. Android-based tablets, peripherals connected via USB HID, front end built on libGDX (it was a gaming-related product), in-house remote management agent + back end (a WebSocket key/value store + pubsub db managed with a Django app, SSH + adb for fallback device access). Overall I was happy with the approach but if I were building it today hopefully there would be better off the shelf software for the back end. The client's business involved renting the kiosks to customers of their larger gaming business.
Not as a main gig, but I frequent an arcade bar very often. I've started light research into how I might put together an arcade cabinet running a unity app using a raspberry pi. I was looking into how to automagically start the app in full screen using Linux. Something that I think may be accomplished using systemctl? The idea is to have it be plug and play; arcade bar staff should just turn it off and back on for it to restore video game service.
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
Any tips are welcome and appreciated. If not, I'll do heavier research when I am ready to hack this idea into life.
I would assume putting the app into the startup daemon should be enough? Should be easy to test either way!
My fear is if the unity app somehow loses focus, perhaps due to some annoying OS pop up. I'd love to learn more so I can be confident that it could run in production without too much concern.
Been thinking of getting into it. But, I do not think the tech stack is what matters as it would be the systems knowledge about that particular market and the best way to use the tech stack to leverage that systems knowledge of that market for the kiosk end-users.
An example, Fast food kiosks. What systems knowledge can I gain about all about McDonalds can I gain to them partner with my tech stack to deliver a McDonalds kiosk that amps up the McDonalds Experience.
An example, Fast food kiosks. What systems knowledge can I gain about all about McDonalds can I gain to them partner with my tech stack to deliver a McDonalds kiosk that amps up the McDonalds Experience.
Since you mention it McDonalds kiosks specifically, here's my UX observation.
It takes 10 touch screen presses to order and pay for a single item, also having to locate touchpoints (not always buttons?) which move up and down by several ft.
It takes 10 touch screen presses to order and pay for a single item, also having to locate touchpoints (not always buttons?) which move up and down by several ft.
I did for a little while. I thought it was going to be a lucrative untapped market, but really it's just not very in demand. Basically +1 to everything tootie said.
Here's the slides from a presentation I did if they're helpful: https://www.slideshare.net/ClaudiuLodromanean/start-developi...
Here's the slides from a presentation I did if they're helpful: https://www.slideshare.net/ClaudiuLodromanean/start-developi...
I have used Android Open Source Project (AOSP) as a basis for kiosk/embedded UI. For most projects it is overkill. In one case the need was to integrate an inventory management app into a commercial kitchen label printer. That made sense. But, unless you are starting from a large existing Android app, I would look for a simpler, more specifically kiosk-oriented platform.
How prevalent is remote work in this area? Assuming it is not common since you have to have access to the physical hardware in the office?
I work for LinkNYC. We have a few thousand kiosks all around New York City.
I work remotely from a different state without any issues, as does the rest of engineering.
They shipped all the relevant hardware to my home address. It was a bit of a hassle to put it all together and it can take a bit of space but it's definitely doable.
I work remotely from a different state without any issues, as does the rest of engineering.
They shipped all the relevant hardware to my home address. It was a bit of a hassle to put it all together and it can take a bit of space but it's definitely doable.
I worked at a company where another team built kiosks for malls and such. Last time I checked, they work remotely for the majority of the work but do have to go to the office to properly test the software at times. Fully remote is a no go for sure.
Not sure if it really fits your definition but I make interactive exhibits for museums, trade fairs and events. I am mostly using a visual programming environment called vvvv: https://visualprogramming.net/#Showcase
The "flow" type programming model reminds me a lot of TouchDesigner (https://derivative.ca/)
Well, in both you connect nodes through edges to build a graph :)
Seriously though, vvvv is a lot more low level and lends itself better to "application programming" while TD is rather focused on visuals. But ofc I am biased.
I didn't know this existed. It's very cool! Thanks for sharing it.
We used PCs in a kiosk form factor (circa 2009). We were using Flash for some games and Unity for others. Three games we did for a museum were Cryptogram, Cypher Express, and Navajo Code Match.
We didn't stick with making games for kiosks. Managing both the software and the hardware was too much overhead, and at the time I didn't think it was a tenable line of business compared to other opportunities.
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
We didn't stick with making games for kiosks. Managing both the software and the hardware was too much overhead, and at the time I didn't think it was a tenable line of business compared to other opportunities.
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
I am.
I have a few prototype kiosks that I use a android TV inside (cheap Chinese 1080p ones, The first version where just Rapsberries PIs inside but the dollar is expensive as hell in my country now, and I had to import them, so now they cost 5X more).
My original front / Back where in PHP brecasse I had to code it in 1 month and php is cheap as hell to host. Now I'm changing for a control panel in React / backend in C#.
And the application is a native android application that I will probably port to React Native. Just because I'm learning react native.
I have a few prototype kiosks that I use a android TV inside (cheap Chinese 1080p ones, The first version where just Rapsberries PIs inside but the dollar is expensive as hell in my country now, and I had to import them, so now they cost 5X more).
My original front / Back where in PHP brecasse I had to code it in 1 month and php is cheap as hell to host. Now I'm changing for a control panel in React / backend in C#.
And the application is a native android application that I will probably port to React Native. Just because I'm learning react native.
I work on a team building a real-time display of energy flows (production and consumption) on a regional basis (by municipalities). This is mainly used in town halls on a flat-screen display but of course publicly accessible as well. It‘s made with VueJS but will be rewritten with Svelte very soon. Here‘s one example of one of over 140 municipalities at the time of this writing:
https://energiemonitor.bayernwerk.de/abensberg
https://energiemonitor.bayernwerk.de/abensberg
I've worked on some start up ideas in this industry and love https://www.balena.io/ for this
I've worked on the software side of things. We typically just build web apps and run them using Chrome's kiosk mode (https://blog.suitebriar.com/chrome-kiosk-mode-what-is-it-how...).
The displays I've worked on generally run on standard touch-enabled TVs on something like an Intel NUC running Windows.
The displays I've worked on generally run on standard touch-enabled TVs on something like an Intel NUC running Windows.
I've worked in this industry quite a bit as a mechanical engineer designing the hardware.
Unused pi presents for a project a whole ago, it has very robust functionality including toggling io pins, etc. I've found it hard to justify using anything else, it's super simple and very versatile.
https://pipresents.wordpress.com/
Unused pi presents for a project a whole ago, it has very robust functionality including toggling io pins, etc. I've found it hard to justify using anything else, it's super simple and very versatile.
https://pipresents.wordpress.com/
Raspberry Pi + https://github.com/jareware/chilipie-kiosk
>Easy-to-use Raspberry Pi image for booting directly into full-screen Chrome, with built-in convenience features for unattended operation. Perfect for dashboards and build monitors.
>Easy-to-use Raspberry Pi image for booting directly into full-screen Chrome, with built-in convenience features for unattended operation. Perfect for dashboards and build monitors.
I’m Product at CHEQ (hiring in Greater Seattle area). Kiosks are part of our product portfolio that are used to order food and drink at stadiums. https://www.cheqplease.com/stadiums
Our kiosks are running Android.
Are you looking at building a kiosk? What is your use case?
Our kiosks are running Android.
Are you looking at building a kiosk? What is your use case?
I did it for years. Mostly interactive content for museums and marketing events. Last one was in 2014 I think.
My main stack was Adobe Air. Sometimes I used Cinder, a C++ framework when I needed more performance. The last projects were done using NWJS which was like Electron using whatever JS stuff was needed like Rivets, Pixi, even jQuery.
My main stack was Adobe Air. Sometimes I used Cinder, a C++ framework when I needed more performance. The last projects were done using NWJS which was like Electron using whatever JS stuff was needed like Rivets, Pixi, even jQuery.
In the industrial control world, they call these "HMIs", or human-machine interfaces. There used to be a lot of Windows CE on small SBCs with PC/104 (basically ISA) bus adapters for custom logic. The software was usually a normal GDI based Win32 application, using Windows CE's real time features either in app or in a separate thread/process to meet timing. QNX photon was also popular in applications that weren't cost sensitive (telecom switches, million dollar HVAC, 10 million dollar elevators, etc). The business model was usually a government contract, where we adapted existing in-house HMI libraries to a vendor's SBC mated to our proprietary control boards.
In between the reliability of consumer kiosks and a HMI, there are proprietary systems like Labview and GE Fanuc, which have the ability to create drag-and-drop GUIs for custom applications. I've built or modified a few of these for specialized factory lines, water/wastewater plants, or experiments under contract.
I've also built kiosks using Windows Embedded and Chrome on Raspberry Pi, for conventions as a volunteer, and for mass transit systems under government contract. The Miami International Airport monorail and portions of the BART airport extension both use these kiosks.
I want to emphasize that although web technology allows for extremely fast app prototyping, web browsers were by far the largest risk for all of these projects. Industrial control systems are expected to have 100% uptime, forever, period end of story, and in many cases are disconnected from the Internet and never patched. This is a very realistic expectation when the target system does not include a TCP/IP stack or even networking hardware (controls are done via RS-422 or a similarly deterministic bus), the total image size peaks at a few megabytes, there is no BIOS, and the bootloader is a jump instruction to a XIP image in memory mapped NOR flash.
On the other hand, in situations where a service contract is being pushed on the customer for business reasons, the Chrome+Raspberry Pi option is great because it breaks all the time. SD cards, even high endurance ones (I'm looking at a dead 32G Samsung HE card from a Helium miner right now) break for no reason, Chrome or Raspbian's WM throw up dialogs for irrelevant issues, uboot will sometimes not, and the HDMI transceivers between the Pi and the display will sometimes just refuse to talk. Don't even get me started on the USB touchscreen bits.
Despite what you might think, you don't need a web browser for infotainment or movie playing. All the major embedded frameworks include video, and if you really want to use web technologies there's node bindings for Qt and that kind of thing. Kiosks are fixed DPI, fixed resolution, fixed font systems, and there's no need to involve HTML, CSS, or any other dynamic layout technology.
In between the reliability of consumer kiosks and a HMI, there are proprietary systems like Labview and GE Fanuc, which have the ability to create drag-and-drop GUIs for custom applications. I've built or modified a few of these for specialized factory lines, water/wastewater plants, or experiments under contract.
I've also built kiosks using Windows Embedded and Chrome on Raspberry Pi, for conventions as a volunteer, and for mass transit systems under government contract. The Miami International Airport monorail and portions of the BART airport extension both use these kiosks.
I want to emphasize that although web technology allows for extremely fast app prototyping, web browsers were by far the largest risk for all of these projects. Industrial control systems are expected to have 100% uptime, forever, period end of story, and in many cases are disconnected from the Internet and never patched. This is a very realistic expectation when the target system does not include a TCP/IP stack or even networking hardware (controls are done via RS-422 or a similarly deterministic bus), the total image size peaks at a few megabytes, there is no BIOS, and the bootloader is a jump instruction to a XIP image in memory mapped NOR flash.
On the other hand, in situations where a service contract is being pushed on the customer for business reasons, the Chrome+Raspberry Pi option is great because it breaks all the time. SD cards, even high endurance ones (I'm looking at a dead 32G Samsung HE card from a Helium miner right now) break for no reason, Chrome or Raspbian's WM throw up dialogs for irrelevant issues, uboot will sometimes not, and the HDMI transceivers between the Pi and the display will sometimes just refuse to talk. Don't even get me started on the USB touchscreen bits.
Despite what you might think, you don't need a web browser for infotainment or movie playing. All the major embedded frameworks include video, and if you really want to use web technologies there's node bindings for Qt and that kind of thing. Kiosks are fixed DPI, fixed resolution, fixed font systems, and there's no need to involve HTML, CSS, or any other dynamic layout technology.
As a web developer, I certainly agree that doing this sort of stuff using web techs is almost certainly like using a howitzer to swat a fly, especially when security is a concern, and I'm kinda surprised… well, not surprised, but more dismayed by the number of replies to the OP saying they did this with web techs. When all you have is a hammer…
I worked for an Automaker for a while. When I was doing POC work we did a lot of Ubuntu on NUCs, and occasionally Raspberry Pi’s. We did a lot of QT/QML
When we were doing production work, the stack was QNX/QT. I specifically did work on a web layer
When we were doing production work, the stack was QNX/QT. I specifically did work on a web layer
There are various Linux distros for this, Webconverger for example:
https://en.wikipedia.org/wiki/Webconverger
https://en.wikipedia.org/wiki/Webconverger
used to develop drivers for infortainment system. boring as hell.
Arm/cpp/linux
Arm/cpp/linux
I work for Intersection, a company behind LinkNYC kiosks deployed in New York City: http://link.nyc
The basic idea is that we have ~2000 kiosks deployed across all 5 boroughs. Each screen has 2 displays so that's ~4000 displays playing various ads. Kiosks also provide free Wi-Fi for the public, free phone service since they replaced the payphones, and there is an Android tablet that can be used for various online services such as applying for food stamps.
We have some kind of partnership setup with the city, and we also get money from ad plays. The business structure is a lot more complicated than that but I don't want to go into details because it's highly likely I'll say something wrong.
Like most things, it's a mixed bag. Working with hardware that's deployed in public changes the game in interesting ways. Things can break for so many different reasons since they interact with the physical world all the time.
There was a funny moment when we noticed one of the kiosks being down. It wasn't responding, we couldn't reach it over the network at all so we decided to take a look at it in the street and....it wasn't there. A 7-8 ft kiosk just disappeared off the street. We later found out that a truck smashed into it in the early morning and it was all cleaned up by the time we realized something was wrong.
Hot weather, cold weather, car traffic, people smashing kiosks with a baseball bat because they think wifi spreads covid, there are a lot of things that can break physical devices on the street and it's been fairly interesting dealing with it.
Bad stuff: Ad tech. I hate the whole advertising industry with a passion of a thousand suns. I have moral issues with it and every ad tech thing I touched is horrible from a technological standpoint.
Good stuff: It's interesting. I work on a ton of different stuff. I could be doing a lot of operations work for a while, then go develop a new service next week, then design a bunch of analytics so we can get more insight the following week. Engineering team is not huge and we all have to do everything. We are all remote and the company made sure to ship us all the hardware we need, which is nice.
Nice stuff: Free wifi covering most of the city is a useful thing for people. I'm happy we provide it and it's what makes me feel good about this. Kiosk tablets are also used by the poor and homeless to apply for various programs such as food stamps.
Tech: Nothing very surprising. Various single board computers, Linux, Python, Go, js, SQL, Ansible.
The basic idea is that we have ~2000 kiosks deployed across all 5 boroughs. Each screen has 2 displays so that's ~4000 displays playing various ads. Kiosks also provide free Wi-Fi for the public, free phone service since they replaced the payphones, and there is an Android tablet that can be used for various online services such as applying for food stamps.
We have some kind of partnership setup with the city, and we also get money from ad plays. The business structure is a lot more complicated than that but I don't want to go into details because it's highly likely I'll say something wrong.
Like most things, it's a mixed bag. Working with hardware that's deployed in public changes the game in interesting ways. Things can break for so many different reasons since they interact with the physical world all the time.
There was a funny moment when we noticed one of the kiosks being down. It wasn't responding, we couldn't reach it over the network at all so we decided to take a look at it in the street and....it wasn't there. A 7-8 ft kiosk just disappeared off the street. We later found out that a truck smashed into it in the early morning and it was all cleaned up by the time we realized something was wrong.
Hot weather, cold weather, car traffic, people smashing kiosks with a baseball bat because they think wifi spreads covid, there are a lot of things that can break physical devices on the street and it's been fairly interesting dealing with it.
Bad stuff: Ad tech. I hate the whole advertising industry with a passion of a thousand suns. I have moral issues with it and every ad tech thing I touched is horrible from a technological standpoint.
Good stuff: It's interesting. I work on a ton of different stuff. I could be doing a lot of operations work for a while, then go develop a new service next week, then design a bunch of analytics so we can get more insight the following week. Engineering team is not huge and we all have to do everything. We are all remote and the company made sure to ship us all the hardware we need, which is nice.
Nice stuff: Free wifi covering most of the city is a useful thing for people. I'm happy we provide it and it's what makes me feel good about this. Kiosk tablets are also used by the poor and homeless to apply for various programs such as food stamps.
Tech: Nothing very surprising. Various single board computers, Linux, Python, Go, js, SQL, Ansible.
I have my own product in this area which is basically a web app. Then I ask customers to open it with the most popular Android kiosk app and it works like a charm.
ipad. Industrial human machine interface/HMI, Swift/XCode/iOS with single app mode and remote MDM.
You could check out Magic Mirror²: It is open source and runs in kiosk mode on an SBC like Raspberry Pi. Based on JavaScript and Electron.