Here at Qi we found a solution that will revolutionize the way conference centres work. We created Infinitables: motorized tables which autonomously organize themselves into desired layouts. Our goal is to help you save time, human resources and money. With the help of our system you will be able to create your own layouts at the touch of a button.
Qi offers more than a solution for making your daily operations more efficient. We designed Infinitables to look just like a well polished, easy on the eye table with the aim of making your company’s switch to our system and replacement of your old tables easier. Infinitables will add more functionality to your space while the minimalistic and sleek personalized design will transform and modernize it even further.
We implemented fully autonomous multi-agent path finding algorithm with conflict-based search and space time A* which allows Infinitables to move simultaneously and effortlessly, thus saving you time and manual labour.
Our easy to use web application allows the user to design new room layouts, remove or reuse old ones, execute them and terminate the operation, all through a visual, user friendly interface.
Market Research
Our product is essential in places that require frequent rearrangement of table layouts, thus suited for events such as business meetings, seminars, conferences, workshops, wedding receptions, dinner parties and more. This use case could easily be extended to classrooms and theatre. Our customer segment would essentially then be business and community centres, event venues, banquet halls, hotels and schools in the UK.
Scope in Industry
The UK’s event industry is evidently massive and blooming, according to the facts gatherered from eventbrite .
The conference and meetings segment is worth £19.9 billion in terms of direct spend to the UK economy.
The 2020 event trends report indicates a period of growth in the industry.
One of the main purposes for an event was to generate revenue, which implies that there is a potential market for technology that could reduce costs and increase efficiency.
Competitors
We do not face much direct competition because there are currently no companies in the UK manufacturing automated table systems for our target segments. Nissan launched its Intelligent Parking Chairs, which parks the chairs in its original position with the sound of a clap. Our niche differs in two major aspects:
They mostly targeted workspaces such as offices and the chairs would tuck themselves back into set positions.
Our target segment is wider, and the user can change the layouts by selecting from an existing menu or designing one on their own.
Our competitors are companies who go out on contract bases to do the set up and rearrange the layout. The venues may also allocate the task to their own team of people. In either case, manual labour, risk assessment and wages will be required.
Value to Customer
To understand why the customer would want our product, let’s assume a scenario illustrated bellow:
Our product would replace these recurring expenses with a one-time purchase. Once the system is in place, there would be no incremental purchases required apart from very occasional maintenance costs, in the case there is any serious damage inflicted on our product.
We would customise our tables according to the customer’s wish, so the price would vary accordingly. The number of tables required also vary according to the capacity of the venue, but economy of scale should reduce the cost per entity. More details are available on the Budget section.
Our team has discussed the health and safety concerns and implemented safeguards. We have emergency system shutdown procedures in place to avoid possible collisions invoked by the vision system or manually through the app.
The large size and growth in the events industry, along with low competition in our niche, paints the target market very attractively to us. The manpower and money saved along with the simple set up; flexibility in the layout designs; easy to use, fire-and-forget nature of our app interface makes Infinitables both cost-effective and appealing to our customer. Considering the above factors in our market research, Infinitables have huge potential for success.
Potential for Future Development
One of the largest planned improvements for the next generation of Infinitables is the inclusion of the multi-wireless charging feature. This would allow multiple tables to charge from the same wireless charging point. The charging times for each individual table would be predicted via learnt usage, pre-booked calendar appointments and the quantity of charge remaining. This means the tables decide themselves when and how to charge!
As Qi grows, we expect to expand beyond the Infinitables product line. The software we created has the potential to be extended and used within wider applications where autonomous movement may be useful: ranging from complimentary chairs for Infinitables and smart, portable storage units to self-moving hospital beds.
The Infinitables system consists of mainly 3 parts:
Physical tables equipped with Arduino-controlled motors.
A web application that users interact with.
A server that receives, processes, and sends user commands to the physical tables.
Below is a system diagram that shows how different parts interact with each other:
Tables
The structure of our current product is built from an extremely low weight, medium-density fibreboard. This allowed our engineering team to size the power of the motor down, which drastically reduces the price of the product. Our high efficiency, low cost motors are controlled by a custom motor controller, which is reverse controlled by an Arduino Uno. This allows our tables to arrange themselves into an almost limitless number of configurations and orientations.
Please find one of our table designs below:
Table’s internal structure allows easy access and maintanance to the user. Table includes 2 motorized wheels and 4 support wheels to keep table in balance, and steer the table in the desired direction. Connection graph of the table with significant components highlighted can be found below.
You can easily charge the tables by using the charging cable provided and the port located right next to the battery ‘drawer’ which can be seen in the above image right under the battery.
Web Application
The users control the system through a web application which allows them to design and edit room layouts (building up a library of reusable setups), execute them and interrupt the operation should any problems arise. It’s web based and hosted on the control server, so it can be used both on mobile and desktop, with no installation required!
The app features a simple interface, built in JavaScript using React, that can be easily used without any previous knowledge of the underlying workings and an intuitive visual editor (using the konva.js library) for layout creation.
Server
Vision
The vision module uses an overhead camera to recognize the tables’ position and orientation.
The position and orientation information is captured continuously which enables:
The path finding sub-system to calculate paths for the tables.
The hardware controller to control the tables’ movement.
The vision module is powered by OpenCV.
Path finding
The path finding module plans collision-free paths for the tables using the position information from the vision module. It enables the tables to form any layout the user wishes. Below is an example where a grid layout is formed from a circular layout.
The path finding module is powered by a robust hierarchical algorithm with a high-level conflict-based search [Sharon et al. 2012] and a low-level space-time A* search. The module is available on GitHub and listed on PyPI.
Hardware Controller
Qi’s “Infinitables” was developed with a proprietary security protocol including a handshake method. At the initial start-up, the tables will initiate a handshake request with the base computer. This results in the secure storage of a table’s identification number in the Electrically Erasable Programmable Read-only Memory, which is safely retained should a power failure occur. The high standard security protocol is merged with each handshake, which ensures a secure communication. To further advance the level of security, the secure keys are regenerated and reassigned periodically.
Qi’s intelligent safety sub-systems makes sure that no accidents or damages occur, with the use of a custom-made vision system and the possibility to request the integration of external systems (e.g.: alarm systems)
Integration
The integration code ties all the software modules together. Below is a common excution flow of the entire system:
You can see that integration module serves as a messenger, calling and returning to other modules.
All the evaluation relating to process makespan were run on a laptop with i7-7700HQ and 16GB of RAM. Vision evaluations were done in a room of size 4m x 3m with a 1080p overhead camera.
Speed and Accuracy of the Vision Module
It is vital that the vision module can run quickly because it can be called several hundred times in a complete usage cycle. We wrapped the exposed function (which other modules call to get position and orientation information) in a timer, recorded the time between the calling and returning of the function with respect to the number of tables present. Five trials were run for each configuration.
# of Tables
Time between Calling and Returning (s)
1
0.057
2
0.056
3
0.056
4
0.058
5
0.061
6
0.070
7
0.087
8
0.092
9
0.094
10
0.094
The results indicate that the vision module is more than fast enough for our system and it will in no way bottleneck our system’s performance.
More vital still is that the vision module be as accurate as possible to avoid any chance of collision. We tested vision’s accuracy by placing 8 AR tags representing tables in a 4-by-2 formation in different positions and orientations within the operation area.
Tags were placed equidistant from each other and facing the same direction. We then recorded the position and orientation information returned by vision. In an ideal system, distances between the tables and orientations of the tables should be equal.
The standard error for each of the tests is presented in the table below. On average the standard error is about 0.2° for table orientations and about 0.08cm for distances.
Test number
Standard error for orientation (°)
Standard error for distance (cm)
1
0.144
0.080
2
0.260
0.061
3
0.168
0.096
4
0.140
0.088
5
0.141
0.061
6
0.313
0.067
7
0.223
0.055
8
0.190
0.124
9
0.322
0.148
10
0.216
0.015
11
0.342
0.101
The results are better than expected as a standard error of 0.2° and 0.08 cm is indistinguishable by eye and small enough to not cause any accidents.
Speed of the Path Finding Module
The path finding module was tested in simulated environments because we do not have access to any large area yet. The simulated environments are obstacle-free maps of different sizes with different numbers of tables present and a randomised goal layout. We are interested in the time taken to calculate the paths to gauge roughly how long a user would need to wait.
Map Size (grids)
# of Tables
Time Taken to Calculate Paths (s)
10x10
4
0.04
10x10
6
0.05
15x15
8
0.05
15x15
10
0.06
20x20
12
0.13
20x20
14
0.18
25x25
16
0.30
25x25
18
0.44
30x30
20
0.80
30x30
22
1.16
35x35
24
2.09
35x35
26
2.20
For perspective, the simulations in the main page have a grid size of 20x30.
We can see that the time it takes increases faster and faster as the number of agent increases and the maps becomes larger. The time is acceptable for our prototype system at the moment but we will improve upon this results.
Motor Tests
The table’s motors were tested to see whether their movement are accurate in linear and rotational motion. Linear movement consistency tests were made by using the vision module where we used the camera to check diversion of the table from the desired finish line. You can find an example of this test in the below picture. During the linear movement consistency tests, it was found that the weight distribution of components created a diversion from the desired finish line. This has been countered by implementing a clibration option to our web app where the powers of the motors are callibrated to travel same distances.
Even if the callibration is correct, a 7% diversion in distance travelled between wheels was observed in the linear movement tests. This means the difference from the desired orientation was on average 7% of the total distance that was supposed to be taken in optimal case. In order to counter this problem, we used the vision module to assist and continoulsy command tables so that they get closer to the target.
Moreover, in the rotational movement test, it has been shown that long movement durations end up causing large variations in the ending orientation of the table. It has been tested that powering periods under 1 second provided an accurate turn with less than 5 degrees difference between desired orientation and actual resultant orientation. However, long powering periods (>5 seconds) end up causing a difference as high as 20 degrees. One main reason for this was found to be rotational momentum. To counter this, central server now sends stop command before table gets to desired rotation.
User Tests
While the current global circumstances have made testing the whole integrated system impossible, presenting the web app to a few testers revealed a number of places for improvement.
Firstly, most users had trouble realising that rotation of tables in the editor was possible or figuring out how to perform it once they had learned about it. This has been alleviated by making the rotation handle appear when tables are dragged around and not just when clicked on, so that users will be more likely to be exposed to it and investigate. The handle was also changed from a square to a circular arrow, similar to ones in slideshow editors, to make its intended functionality more intuitive.
In addition, to allow for very precise alignment of tables a few collision prevention methods (i.e. what happens when a user puts a table on top of another one) were considered, including snapping back to the original location, and not allowing tables to be dragged over one another altogether. The one that users found most intuitive was snapping back to the closest non-overlapping location when dragging is finished, using an implementation of the Separating Axis Theorem. This has the benefit of making close alignment of tables very simple.
Main Areas of Improvement
Improvement for the Path Finding Module
The path finding module needs more work to be viable in much more complex settings. The problems and the solutions are as follows:
The module’s parallelization is currently done by multi-processing only. But we can and should take advantage of threading because some jobs are too small for a new process.
The module is currently written in Python and a part of it is non-optimized native Python. This definitely impacts the performance and we are considering porting the module to a low level language instead.
Future Testing for Motors
In light of the current situation all around the world regarding COVID-19, we were not able to test the hardware to the extent we have desired. If situations allowed it was planned to test the acceleration curve of motors at different weights. Moreover, it was desirable to test the correlation of table weight and oreintation divergence.
Table 1: Cost for each miniaturised prototype table
Item
Quantity
Cost Per Unit
Total
Arduino Uno (built in SRF chip)
1
£19
£19
Motor Board
1
£10
£10
Encoder Board
1
£10
£10
LEGO EV3 Motors
2
£25.99
£51.98
9mm MDF Structure
0.3636 m2
£6 per m2
£2.19
Batteries (AA)
8
£0.32
£2.52
Omni-Wheel
4
£12
£48
TOTAL
£143.69
Table 2: Base setup cost for the prototype. This is a one-off cost that contains the base server and its dependencies.
Item
Quantity
Cost Per Unit
Total
Arduino Nano (built in SRF chip)
1
£5
£5
Camera
1
£20
£20
Base Server (AD/DC adapter, SD card, Pi and Case)
1
£50
£50
TOTAL
£75
Total cost for a complete prototype setup plus 3 tables then is £506.07.
In general, the total cost for a complete setup with n tables is: £75 + n(143.69)
Estimated Cost of Mass Production (Full Sized)
The following costs are only estimates, based on the retail prices of the individual components. This means they factor in the cost of production, research & development, shipping and quality guarantees.
In later iterations of the product, packages containing the base components and a collection of tables could be made available to customers. Small percentage discounts that increase alongside the nubmer of tables in the package would incentivize the consumer to buy more tables and all the necessary pieces from Infinitables.
Table 3: Cost for each consumer table
Item
Quantity
Cost Per Unit
Total
Custom Board
1
£30
£30
nRF24L01+PA+LNA Wireless Transceiver
1
£4.53
£4.53
Motors
2
£30
£60
Material (plastic and wood)
4.108 m2
£10 per m2
£41.08
Wireless Charging Coil
1
£10
£10
Lithium-Ion Battery
1
£10
£10
Wheels
4
£12
£48
TOTAL
£203.61
Table 4: One time cost for consumer table
Item
Quantity
Cost Per Unit
Total
nRF24L01 with USB controller
1
£5
£5
Charging Station
1 per 10 tables**
£12
£12++
Cameras*
1
£20
£20++
Base Server on site
1
£50
£50
TOTAL
£67 + extra camera + extra chargers
We estimate the total cost for a complete setup, a camera and 3 complete table products then would be: £697.83
In general, the total cost of a complete setup, a camera and n complete tables is: £67 + n(203.61)
This may sound like a lot of money, but a quick search reveals that a standard school desk will cost you between £120 - £200.
*Pre-installed cameras may also be used instead of buying new ones. But the coverage, may need to be extended.
**It is recommended to buy one wireless charger per 10 tables, to allow all tables to be able to maintain their charge.
Our team is split into a software team composed of six people and a hardware team with four. While it might seem like there is a clear division between the two teams, our structure is in fact very organic. Each team member carries out the work they are passionate about and have expertise in. It is not uncommon that a software team member contributes to a hardware task, and vice versa.
Throughout the developement process, team members share their updates and findings continuously on Slack. To track progress and to ensure that our work is accessible to everyone, we have used GitHub’s extensively - every individual’s work is accompanied with well written documentation explaining and justifying each new piece of content; this is then carefully reviewed by other team members. On top of the documentation each memeber’s code have to go through a code review process before the pull request to main code repositroy can be accepted. To track progress Kanban boards of GitHUb are utilized where each memeber gets assigned a detailed piece of task. For overall development we have adopted a SCRUM like agile framework. In addition, we have weekly sprint meetings to catch up with other team members and discuss future development.
We have planned our work with the help of the Gantt charts below which has proven to be very successful.
