Posts

  • OpenWaiterAI Devlog #2 Retrieval Augmented Generation

    In this post, we will look at the retrieval augmented generation system of OpenWaiterAI.

    OpenWaiterAI should know its restaurant. It should know working hours, table counts etc. Also it should know items in the menu, their ingredients and possible allergens. It should be able to query erfficiently these datas.

    Since this is a standalone project, i created everything from stratch. I tried to choose best database and data structure for llm performance. After long discussions with ChatGPT O1, i decided to use PostgreSQL with simple table schemas. Thats because current llms are good at writing complex SQL queries. And by doing so, we will be able to reduce our tool count and increase llm performance on long conversations.

    I did not use JSON in PostgreSQL for better querying performance. You can find current table schemas in below diagram:

    PostgreSQL Table Schemas

  • OpenWaiterAI Devlog #1 Instructions

    OpenWaiterAI should deal with customers like a real waiter while using the tools flawlessly in the background. For this, we need to figure out what being a real waiter is and what tools are required.

    Not all human waiters are the same. Some are just teenagers who need money, some are elite waiters serving elite customers. We want OpenWaiterAI to be like a elite waiters. It should be polite and civilized. Overall serving process should be warm and quick. Customers should like OpenWaiterAI more than average human waiters.

    Robot Waiters

  • OpenWaiterAI Devlog #0 Introduction

    Recent advancements in Large Language Models (LLMs) have unlocked new opportunities across various fields. These AI systems are reshaping industries by improving efficiency, creativity, and problem-solving. In particular, the HoReCa sector stands to benefit greatly, as LLMs streamline customer service, optimize operations, and enhance personalized guest experiences.

    LLMs have the potential to transform existing technologies in restaurants. Current self-service kiosks, which function as large tablets for placing orders, could evolve into interactive virtual cashiers powered by LLMs, offering conversational assistance and personalized recommendations. Similarly, service robots, which currently transport food and dirty dishes between the kitchen and tables, could take on more advanced roles. With LLM integration, these robots could greet customers, escort them to their tables, take orders, and even measure customer satisfaction through natural interactions. Lastly, LLMs could revolutionize phone systems, eliminating the need for human operators by seamlessly managing reservations and orders via human-like conversations.


    Honestly, might be an upgrade? Nah!
    byu/Myco_Cube inshittyrobots


  • Pattern Matching on 2D Lidar Data

    Sometimes we need to interact with a specific object in a specific way. To do this, we need to find it first!

    In this post, i will introduce a simple but effective Pattern Matching technique. This technique uses 2D Lidar Data and tries to find a pattern inside of it. You can use it to find chargers, docking stations, pallets etc.

    To process lidar data, i used Point Cloud Library (PCL). PCL is a flexible, strong and time tested point cloud processing library. It already has required capabilities for Pattern Matching. Therefore, we don’t have to re-invent wheel.

    The algoritm is as follows:

    1. Extract clusters. Divide main point cloud into smaller ones. After this step, you will have small point clouds that clustered based on distance. You can see end result below. Each cluster was given a different color.

  • ROS Navigation REST API

    While building autonomous vehicles, we tend to focus heavily on autonomy and forget that these robot are being developed for commercial purposes. Eventually, someone who does not have any robotics background will need to control these robots. And unlike us, they will not have the luxury of Rviz and ROS command line tools.

    We need an interface that will let customers communicate to robots and this interface should be:

    • Fast. Communication should be fast enough that end users can operate easily.
    • Secure. Only authorized users should be able to give commands to robots.
    • Flexible. Same interface should be able to be used for different customers and needs.
    • Scalable. Interface should be (almost) independent of fleet size.
  • Cartographer GRPC

    Cartographer has built in cloud capabilities but it is not well documented. In this post, i will give a basic server and client example.

    To use Cartographer, Cloud you need cartographer_grpc_node. This node is not available with default compile settings. You can check by double tabbing after rosrun cartographer_ros.

    Cartographer GRPC


    Before recompile, you need to install GRPC dependencies. Assuming you already installed basic dependencies, you can use following scripts provided by cartographer:

    ~/catkin_ws/src/cartographer/scripts/install_grpc.sh
    ~/catkin_ws/src/cartographer/scripts/install_async_grpc.sh