Buffet Menu System

The buffet menu system is a custom engineered device for Angelo's Steak and Pasta in Myrtle Beach, South Carolina. The restaurant has two conjoined buffets, which are served by restaurant staff to the customers. At the time, orders for the buffets were placed by having a buffet staff member walking to the kitchen and telling the cook staff the order directly. This was causing staff shortages at the buffet, and also was error prone. I was tasked to create a solution to this issue. The solution I devised was to use the Raspberry Pi 3 along with the official Raspberry Pi 7" touch screen to create two small touch-based devices in the buffet and cooking area. The buffet side shows the list of items on the buffets to request, and the kitchen side shows which items are requested, along with how long ago they were requested, and lastly which location that requested them.

The kitchen also can send feedback to the buffet staff by acknowledge them with the "Wait" or "Prep" buttons on the screen. Wait will turn the selection red on the requesting device, alerting buffet staff the order is not yet being fulfilled and might take longer to prepare. Prep will turn the ordered item green on the requesting device, alerting the buffet staff the order is currently being fulfilled.

The software is 3 sets of programs: One for the requesting (Buffet) device, one for the acknowledging (Kitchen) device, and one server application that verifies requests and synchronizes necessary data between all devices.

The device name which requested any item is also sent with each request, so if more devices are needed into the future, making it scalable between multiple requesting and/or acknowledging devices.

Things I Discovered

The client programs were written with the SLD2 library on desktop and then ported to the Raspberry Pi touch screen. The applications worked on the embedded hardware, but had a severe performance issue. To fix the issue, I ended up having to disable the Xorg display driver and using SDL2 allocated a framebuffer directly to the screen. This fixed the performance issue, going from single digit frame rates to the target of 60 frames per second.

It turns out that the SDL2 support for the Raspberry Pi touch screen was only available through the Xorg display driver, so disabling it disabled the touch inputs into the application! To solve this issue, I ended up having to write a Linux /dev/input/event handler to read the touch screen manually, and handle the touches passed from the input subsystem back into the buffet application. After implementing this input shim, the touch screen worked properly again and the embedded version had feature parity with the desktop development version.

I also discovered during this project that being proactive solves some problems in regards to detecting issues. My original code to detect a downed network connection between the devices was to actually wait for the socket to be closed before reconnecting. This took a long, long time as the linux kernel doesn't instantly down a socket connection, even with the cable unplugged for quite a long time. To solve this issue, I made each device down the connection if there was 10 seconds with no communication. Each device, however, proactively sends a packet to the server (which is always replied to) every 3 seconds to constantly reset the timer for both ends of the connection. This means if we go 10 seconds without communication on either end, we could detect a network issue and can declare it down much faster than kernel socket monitoring would allow.

Other

Project started June of 2016, and final hardware and software was installed in September of 2016. Source code currently is not available for this project.