Drone Parts Builder
Authors: Shibo Ai, Kevin Huang
What is the problem?
We want to help users navigate a database of drone parts and allow them to interact and query the system using natural language processing. In addition to querying, the database should allow for adding drone components to the database, which could be used to combine into a build. A possible query based on our convention is: "add a battery called <insert-battery-name> with weight 100 grams and 100 wh."
Our program should allow a user to do the following:
- Query for a specific hardware (drone parts: motor, battery, camera, control unit, and frame)
- Query for a hardware by range (e.g. weight > 100 g)
- Can specify multiple hardware constraints
- Can add a hardware, will fail if not specific enough
- Can query for a build according to the hardware constraints
- Can add a build
What is the something extra?
In the in-class examples we found it’s inconvenient to add data to the database using prolog predicates. It is enough for only querying data. We decided we will add support for modifying data too, so we used an actual MySQL database instead, and built an interface to interact with the query program. Furthermore, to show the power of prolog, we did all the data filtering using only prolog. In other words, the only data query SQL we used is “SELECT * FROM table”.
What did we learn from doing this?
What we learnt and answer to questions:
Question: The “user friendliness” of the system. During class we learnt that one of the major applications of prolog is to build NLP programs. However, when I tried the example program myself at home, I found that although the language I wrote sounds like natural language, when synthesizing that sentence, I must strictly follow the program’s string parsing procedures, rather than speaking normally. Therefore, one of the goals (or question to ask) is to get some feedback on the user friendliness of our system from others. After completing the project, I asked one of my friends to use the system. We went through the system’s design, and we tried about 30 queries. The result is not optimistic, He got none of the complex queries right and many times I could not tell the reason either and must go back to the system’s design to find out what the correct syntax could be. After the survey we concluded: although the syntax that can be parsed by this system is fluent natural language, our humans tend to be very flexible on the sentence’s structure and wordings. Therefore, a slight, even not noticeable change in the sentence could break the system. To improve this, aside from trying completely different fields such as machine learning, the only way I can think of is to have as many tokens as possible.
Observation: the performance.
One thing brought to our attention is the program will slow down quickly as we add more constraints to the query. In a query about existing builds with three different part constraints, it could take seconds to synthesis the result (this does not count the extra overhead querying MySQL database). We investigated this further and found the program wastes most of its time resolving queries that are obviously wrong. In the trace, we saw the interpreter asked about “is a battery a motor” and so on. This process continues until the interpreter finds the correct match. We strongly suspect this is due to the way to formulate the preposition clauses. In those clauses, instead of doing a pattern matching on string first, we first evaluate the constraint and then do the string pattern matching. This might lead to the interpreter wasting many cycles to evaluate the constraint for all the possible cases, and then failing the string pattern matching, which invalidates all the work done by the interpreter. However, as the program is tested, we decide to not swap the order because prolog is hard to debug (and deadline is approaching).
Work division
Work was divided evenly;
Shibo: Mostly woking on the biuld system Kevin: Mostly working on the part system
Links to code etc.
https://github.com/AiShibo/DronePartBuilder