Giter VIP home page Giter VIP logo

knowrob's Introduction

KnowRob

CI

The purpose of KnowRob is to equip robots with explicit knowledge about the world. Originally, it was implemented using the Prolog programming language. In its second iteration, KnowRob is implemented in C++, but still supports Prolog for rule-based reasoning.

The core of KnowRob is a shared library that implements a hybrid knowledge base. With hybrid, we mean that different reasoning engines can be combined in KowRob's query evaluation process. To this end, KnowRob defines a querying language and manages which parts of a query are evaluated by which reasoner or storage backend. Both reasoners and storage backends are configurable, and can be extended by plugins either in written in C++ or Python. There are a few applications shipped with this repository including a terminal application that allows to interact with KnowRob using a command line interface, and a ROS node that exposes KnowRob's querying interface to the ROS ecosystem.

Getting Started

These instructions will get you a copy of KnowRob up and running on your local machine.

Dependencies

The following list of software is required to build KnowRob:

Optional Dependencies

Some features will only be conditionally compiled if the following dependencies are found:

  • ROS1 >= Melodic, ROS2 is not supported yet

Installation

KnowRob uses CMake as build system. The following steps will guide you through the installation process. Assuming you have cloned the repository to ~/knowrob:

cd ~/knowrob
mkdir build
cd build
cmake ..
make
sudo make install

You may further need to set the SWI_HOME_DIR environment variable to the installation location of swipl:

export SWI_HOME_DIR=/usr/lib/swi-prolog

Alternatively, you may clone the KnowRob repository into a ROS workspace and build it using catkin. Please refer to the ROS documentation for further information.

Development

Any IDE with proper CMake and C++ language support should be able to load the project. For example, you can use CLion or Visual Studio Code. But support for Prolog code is usually quite limited or not existent.

Configuration

KnowRob uses a configuration file to set up the knowledge base. Internally, boost's property tree is used to parse the configuration file. Hence, JSON is one of the supported formats. The configuration file specifies the storage backends, the reasoner, and the ontologies that are loaded into the knowledge base.

An example configuration file is provided in settings/default.json:

  "data-sources": [
    {
      "path": "owl/test/swrl.owl",
      "language": "owl",
      "format": "xml"
    }
  ],
  "data-backends": [
    {
      "type": "MongoDB",
      "name": "mongodb",
      "host": "localhost",
      "port": 27017,
      "db": "mongolog1",
      "read-only": false
    }
  ],
  "reasoner": [
    {
      "type": "Mongolog",
      "name": "mongolog",
      "data-backend": "mongodb"
    }
  ]

For more information about storage backends, please refer to the Backends documentation, and for more information about reasoners, please refer to the Reasoner documentation.

Launching

Being a shared library, KnowRob cannot be launched directly but only in the context of a program that uses it.

One such program is the terminal application that allows to interact with KnowRob using a command line interface. It can be launched as follows:

knowrob-terminal --config-file ~/knowrob/settings/default.json

The configuration file is a required argument, there is no fallback configuration file.

Once the terminal is up and running, you should see a greeting message and a prompt which looks like this:

Welcome to KnowRob.
For online help and background, visit http://knowrob.org/

?- 

Please refer to the CLI for documentation about the syntax of queries that can be typed into the terminal. Limited auto-completion is available. exit/0 will terminate the terminal.

Alternatively, you can expose the KnowRob querying interface as a ROS service. Please refer to the ROS documentation for further information.

Getting Familiar

Here we provide an overview about functionality of KnowRob.

Querying

The core of KnowRob is a querying interface that is built around a custom querying language. Its syntax is similar to Prolog, but it is more simplified and not Turing-complete like Prolog is.

For more information on querying in KnowRob, please have a look here.

Ontologies

KnowRob structures knowledge using ontologies. Ontologies are formal models of a domain that are used to describe the concepts in the domain and the relationships between them. In KnowRob, ontologies are generally represented as RDF graphs using the RDFS and OWL vocabularies.

Ontologies are organized in a hierarchy where each ontology is a specialization of another ontology. A common distinction is made between foundational (or top-level) ontologies, domain ontologies, and application ontologies. A foundational ontology fixes the basic concepts and relationships that are used across different domains. In KnowRob, we define a domain ontology for the robotics domain, and align it with a common foundational ontology. Applications can then import the domain ontology and extend it with application-specific concepts to cover the specific requirements of the application.

For more information on ontologies in KnowRob, please have a look here.

Triple Store and Data Access

Knowledge is represented in form of contextualized triples -- each subject-predicate-object triple has additional fields that contextualize the triple. A configurable storage backend is used to store and retrieve triples -- currently, triple stores based on Prolog, MongoDB and Redland are supported.

One important aspect in knowledge representation for robots is that a lot of knowledge is implicitly encoded in the control structures of the robot. Hence, one goal is to make this implicit knowledge explicit. This is done by mapping data to symbols in an ontology. In case of querying, this is often referred to as Ontology-based Data Access (OBDA).

For more information on storages in KnowRob, please have a look here.

Reasoning

KnowRob uses an ensemble of reasoners approach where inferences of different reasoners are combined into correlated knowledge pieces. The reason for choosing this approach is that there is no single formalism that is suited for every reasoning tasks. Instead, given a problem, one should decide what the most suitable formalism is to tackle it. Consequently, KnowRob can be configured to solve specific problems by loading corresponding reasoning modules that implement a common interface.

For more information on reasoning in KnowRob, please have a look here.

Further Information

More documentation can be found in the following pages:

In addition, the following resources are available:

knowrob's People

Contributors

abhijitvyas avatar airballking avatar alexeyreshetnyak avatar andreihaidu avatar artnie avatar asilx avatar bbferka avatar bbrieber avatar benjaminalt avatar daniel86 avatar furushchev avatar hatguy avatar ichumuh avatar joserochh avatar jspricke avatar jworch avatar karinne-ics-tum avatar kaviyachandran avatar mcmodknower avatar metaluks avatar mh0rst avatar mmrrqq avatar mpomarlan avatar mtenorth avatar rstoica avatar sasjonge avatar seba90 avatar so-cool avatar thordreck avatar zyfang avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

knowrob's Issues

Test with Prolog 6.x and 7.x

There have been significant changes in SWI Prolog 6.x and 7.x -- test if they affect the parts used in KnowRob

Catkinize KnowRob

Switch the buildsystem from rosbuild to catkin in order to be compatible with the newer versions of ROS.

  • Convert rosjava_jni packages to rosjava
  • get_ld_lib_path -> pkg-config
  • get_pkg_classpath -> rosjava
  • tf client for rosjava?

Travis build server

Build server is not working since some time.
Might be related to git sub modules.

Fix documentation generation

The generation of the API docs is currently broken because it has not yet been ported from the ias.cs.tum.edu domain. Either
a) manually install API docs on knowrob.org, or
b) set up automated doc generation and deployment (preferred)

json_prolog python library always calls the main namespace

The json_prolog python library calls the prolog services using addresses of the form /json_prolog/*.

If the node using the library and the json_prolog node are launched inside a specific namespace (i.e. if multiple robots are launched in their own namespaces) the code will still invoke the service in the main namespace, thus failing. At the moment it seems impossible to have different reasoners connected through json_prolog at the same moment.

Changing the address to json_prolog/* would make the call local solving this problem. I did the change locally because needed to run json_prolog inside my robot's namespace. If the same result can be achieved in any other way, I'd be happy to listen.

Update KnowRob for indigo

  • Add rosdep definitions for Ubuntu Trusty to rosdistro
  • Test with new Prolog version in Ubuntu Trusty
  • Update installation instructions

Separate code and data packages

Mixing code and data as for instance in the semantic map packages has already caused problems when trying to re-use the code in another setting. These two aspects should therefore be separated into different packages as much as possible, leaving only code and ontologies in the one, and maps/object knowledge/action instances/recipes/... in the other package.

  • Do not auto-load data files like the semantic map any more
  • Create data packages in knowrob_addons and load using package://foo/bar.owl
  • Do not depend from code packages on data packages

Remove "default" capabilities in SRDL

Capabilities that do not have any dependencies are always returned, also for non-existing robots. A check for the existence of a robot instance should be added.

In addition, several __description instances are returned, and it's not clear why that is the case.

Switch to default semweb and jpl packages

Use upstream versions whenever possible to profit from updates and further development. The current setup with copied fixed versions was only due to issues with the JPL and semweb versions in old Ubuntu packages.

  • Test if they work fine in 12.04 -- 14.04
  • Remove proprietary versions
  • Check if changes need to be ported?
  • Move owl.pl to knowrob_common

Java classpath construction does not work properly with catkin 'install' space

The current procedure of constructing the Java classpath by finding and concatenating classpath.txt files in the dependent ROS packages does not scale to catkin install spaces. The classpath.txt contains global paths and references to the src and devel spaces that should not be in there.

Possibly there is a new way of discovering rosjava projects in dependent catkin packages in the Indigo release of rosjava?

Update jar files

  • Use up-to-date versions
  • Put into subfolders with license texts

Clean up: Merge and move packages

  • ---Merge basic packages: ias_prolog_addons, ias_knowledge_base, knowrob_common,
    semweb---
  • What to do with the old weka/mallet jar files?
  • ---Merge comp_semantic_map---
  • Move mod_probcog, srldb, knowrob_omics to knowrob_addons
  • ---Move knowrob_vis, knowrob_mongo into the core stack---
  • Also motion_constraints, mesh_reasoning, knowrob_cram?

assertion of facts through json-prolog relatively slow

Abstract:
It seems assertion of facts into knowrob through the json-prolog interface takes about 0.2s per fact. I need to speed this up. @daniel86 @knowrob @fairlight1337 Could you please help me make with this?

Details:
I am trying to assert new facts into a running knowrob instance runtime to later query for those facts through the json-prolog interface. I have the impression that these assertions are relatively slow.

For example, I am logging a perception instance with query and result designators from CRAM through the knowrob-plugin of semrec. The actual call to the perception, and asynchronous logging calls to semrec in the repl feel like they are instantaneous. However, the info printouts of the knowrob-plugin asserting into the live knowrob take several seconds. I can literally watch the facts going into the knowledge base.

I want to use the knowrob logging for maintaining my belief state outside of CRAM. Hence, I'm afraid several seconds to remember one perception event might be too slow for my requirements.

In order to verify that it is not the knowrob-plugin of semrec that takes so long, I ran a naive benchmark from the repl asserting the same fact 100 times through json-prolog and measuring the execution time. It turns out, one assertion tasks almost always 0.2s. This fits to my feeling of several seconds for logging one perception events because that should be around one or two dozen assertions.

Do you guys have any idea how to speed up this process?

Appendix:
For future reference, I am putting the lisp code I used for my naive benchmarking below:

Naive benchmarking:

(let ((before nil)
       (after nil))
  (loop for i from 1 to 100 do
      (setf before (cons (ros-time) before))
      ;; here comes the actual call to json-prolog
      (prolog-simple
        "cram_start_action(knowrob:'WithFailureHandling', 'WITH-FAILURE-HANDLING', 1445243660.613, '_', ACTIONINSTANCE)")
      (setf after (cons (ros-time) after)))
  (defparameter *benchmarks* (mapcar #'- after before)))

Analysis of naive benchmarking:

(let ((min (reduce #'min *benchmarks*))
       (max (reduce #'max *benchmarks*))
       (avg (/ (reduce #'+ *benchmarks*) (length *benchmarks*))))
  (format t "~%min: ~a, max: ~a, avg: ~a~%" min max avg))

min: 0.20276284217834473d0, max: 0.2043600082397461d0, avg: 0.20356736898422242d0

Unable to load existing OWL in Semantic Map Editor

When I tried to load and existing OWL file in Semantic Map Editor, the console output the following messages and just stuck there :

Feb 14, 2014 2:03:01 PM controlP5.ControlBroadcaster printMethodError
SEVERE: An error occured while forwarding a Controller event, please check your code at controlEvent
java.lang.reflect.InvocationTargetException
    at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at controlP5.ControlBroadcaster.invokeMethod(Unknown Source)
    at controlP5.ControlBroadcaster.broadcast(Unknown Source)
    at controlP5.Controller.broadcast(Unknown Source)
    at controlP5.Button.setValue(Unknown Source)
    at controlP5.Button.activate(Unknown Source)
    at controlP5.Button.mouseReleased(Unknown Source)
    at controlP5.Controller.setMousePressed(Unknown Source)
    at controlP5.ControllerGroup.setMousePressed(Unknown Source)
    at controlP5.ControlWindow.mouseReleasedEvent(Unknown Source)
    at controlP5.ControlWindow.mouseEvent(Unknown Source)
    at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:606)
    at processing.core.PApplet$RegisteredMethods.handle(Unknown Source)
    at processing.core.PApplet.handleMouseEvent(Unknown Source)
    at processing.core.PApplet.dequeueMouseEvents(Unknown Source)
    at processing.core.PApplet.handleDraw(Unknown Source)
    at processing.core.PApplet.run(Unknown Source)
    at java.lang.Thread.run(Thread.java:744)
Caused by: jpl.PrologException: PrologException: error(existence_error(procedure, /(rdf_has, 3)), context(:(system, /('<meta-call>', 1)), _27))
    at jpl.Query.get1(Query.java:336)
    at jpl.Query.hasMoreSolutions(Query.java:258)
    at jpl.Query.oneSolution(Query.java:688)
    at jpl.Query.hasSolution(Query.java:759)
    at edu.tum.cs.ias.knowrob.prolog.PrologInterface.executeQuery(PrologInterface.java:99)
    at edu.tum.cs.ias.knowrob.vis.applets.SemanticMapVisApplet.getItem(SemanticMapVisApplet.java:903)
    at edu.tum.cs.ias.knowrob.vis.applets.SemanticMapVisApplet.addObject(SemanticMapVisApplet.java:364)
    at edu.tum.cs.ias.knowrob.map.SemanticMapEditorForms.controlEvent(SemanticMapEditorForms.java:521)
    ... 22 more

What might be the cause and how to solve it? Thanks~

This is a same post as this:
http://answers.ros.org/question/132411/unable-to-load-existing-owl-in-semantic-map-editor/

Deadlock in json_prolog

Hello KnowRob-Team,

I am using KnowRob in combination with the CRAM2 bullet reasoining environment for an evaluation. I have a scenario similar to the spatial_relations_demo. The only difference is that I try to achieve the "object-in-hand" goal for an object which does not exist in the simulation. During the tries to grasp the object KnowRob (probably json_prolog) encounters a deadlock. If I close and reopen LISP the kitchen environment is not spawned anymore. This can only fixed by restarting the json prolog node.
When I attached a debugger to json_prolog I saw some threads hanging at ThreadQuery:130 and one at ThreadQuery:81.
To get my evaluation done, I first tried an old KnowRob-Version (9551075) and the deadlock still occured. Afterwards, I tried an older version (35faec3) and the deadlock did not appear anymore. I tried to revert the commits between 35faec3 and HEAD making changes to ThreadedQuery.java and JSONPrologNode.java but the deadlock was still there...

Kind Regards,

Marc Niehaus

Edit: The deadlock still occurs is still there in 35faec3. However, it occurs less frequent...

Classpath of KnowRob packages that are loaded after JPL has been initialized is ignored

KnowRob constructs the CLASSPATH environment variable by collecting entries stored in the classpath.txt files in each rosjava package in the dependencies. Usually, this is done at startup by the rosprolog script, but can also be done by the register_ros_package() predicate.

The problem is that Java only considers the CLASSPATH variable once when the JVM is initialized, i.e. changes of this variable will have no effect once Java has been started. This may result in missing entries in the following startup sequence:

  • rosprolog
  • <start some Java component, e.g. visualization>
  • register_ros_package()
  • call Java code in

Workaround:
Set up a 'demo package' that, for a given scenario, contains all required dependencies and loads them using its init.pl. Do not start Java code from the init.pl, but only after KnowRob has been loaded.

KnowRob OWL export

Story: code-iai/knowrob_backlog#19
Make sure OWL export works.
Allow exporting the complete ontology as well as only parts of it.

Knowrob installation stops at "rosdep install knowrob" phase.

Good Afternoon.

I tried to install knowrob on brand-new 32bit trusty kubuntu.
After installing of the ros-indigo-desktop-full, I have created a
separate user knowrob.
I have used the following procedure within the knowrob account.

export ROS_WORKSPACE=$HOME/catkin_ws/src
mkdir -p $ROS_WORKSPACE
cd $ROS_WORKSPACE
~/catkin_ws/src$ catkin_init_workspace
~/catkin_ws/src$ cd ..
~/catkin_ws$ catkin_make

Result OK

Base path: /home/knowrob/catkin_ws
Source space: /home/knowrob/catkin_ws/src
Build space: /home/knowrob/catkin_ws/build
Devel space: /home/knowrob/catkin_ws/devel
Install space: /home/knowrob/catkin_ws/install

...

echo "" > $ROS_WORKSPACE/.rosinstall

Without the above step rosws merge has not worked

rosws merge
https://raw.github.com/knowrob/knowrob/indigo-devel/rosinstall/knowrob-all.rosinstall

OK

rosws update

Fetching files - OK

rosdep install knowrob

I HAVE GOT THE ERROR

ERROR: the following packages/stacks could not have their rosdep keys
resolved to system dependencies:
knowrob: Cannot locate rosdep definition for [tf_prolog]

I have noticed that last week manifest.xml have been replaced by
package.xml, so I cannot proceed with catkin_make.

Below are my environment variables:
knowrob@andrzej-virtual-machine:~$ env | grep ROS
ROS_ROOT=/opt/ros/indigo/share/ros
ROS_PACKAGE_PATH=/home/knowrob/catkin_ws/src:/opt/ros/indigo/share:/opt/ros/indigo/stacks
ROS_MASTER_URI=http://localhost:11311
ROS_WORKSPACE=/home/knowrob/catkin_ws/src
ROS_TEST_RESULTS_DIR=/home/knowrob/catkin_ws/build/test_results
ROSLISP_PACKAGE_DIRECTORIES=/home/knowrob/catkin_ws/devel/share/common-lisp
ROS_DISTRO=indigo
ROS_ETC_DIR=/opt/ros/indigo/etc/ros

I have no idea how to go on.

Regards
Andrzej Mazurkiewicz

knowrob_cad_parser seems to auto-center meshes

This can be an issue if the origin of the mesh (i.e. the point that the object's pose refers to) is not in the center of the bounding box. Instead, objects should be drawn as indicated in the mesh file (relative to the origin of the mesh file that has been moved to the object's position)

Reconsider handling of end time for object perceptions

In plan logs, the end time of a perception event is normally just after its start, while the belief about the object location should persist until the object has been detected again. Therefore, the current setup of checking whether a time point is during the duration of a perception event does not seem to make sense any more.

OWL paths broken in .deb packages

When starting KnowRob from the .deb binary version, the following error message appears, which indicates that several OWL files are not parsed correctly.

Warning: /opt/ros/fuerte/stacks/knowrob/knowrob_objects/prolog/knowrob_objects.pl:84:
Goal (directive) failed: knowrob_objects:owl_parser:owl_parse(../owl/knowrob_objects.owl,false,false,true)

catkinized json_prolog issues

missing INCLUDE_DIRS and LIBRARIES in the declaration catkin_package. It should look something like this:

catkin_package(INCLUDE_DIRS include
LIBRARIES json_prolog
CATKIN_DEPENDS json_prolog_msgs #not sure if this is needed
DEPENDS rosprolog
)

This way packages that depend on json_prolog can find the includes and libraries.

Also the code from the tutorial for the java client for json_prolog needs an update for the imports:

import org.knowrob.json_prolog.Prolog;
import org.knowrob.json_prolog.PrologBindings;
import org.knowrob.json_prolog.PrologQueryProx;

Issues with knowrob_srdl:compile when instrucctions for knowrob installation

I've been trying install the CRAM language, when I process catkin_make in ros to install knowrob from stacks, there is a failure with some depencencies, the error is show below, some body could provide any guide to install it,

Thanks.

Gradling tasks for knowrob_srdl
Catkin generate tree: replacing older version of gencpp[0.5.2->0.5.3]

FAILURE: Build failed with an exception.

  • What went wrong:
    Could not resolve all dependencies for configuration ':knowrob_srdl:compile'.

    Could not find any version that matches org.knowrob.knowrob_common:knowrob_common:[0.1,).
    Required by:
    org.knowrob.knowrob_srdl:knowrob_srdl:0.1.0

  • Try:
    Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
    make[2]: *** [stacks/knowrob/knowrob_srdl/CMakeFiles/gradle-knowrob_srdl] Error 1
    make[1]: *** [stacks/knowrob/knowrob_srdl/CMakeFiles/gradle-knowrob_srdl.dir/all] Error 2
    make[1]: *** Waiting for unfinished jobs....
    warning: [options] bootstrap class path not set in conjunction with -source 1.6
    1 warning

FAILURE: Build failed with an exception.

install instructions on website outdated?

The install instructions on knowrob.org point at the rosinstall-file of the indigo-branch. Those, in turn, point at the indigo-branch. However, that branch has not seen much activity, and the repository has the master-branch as default. Should the install instruction on the websites be changed to point at the master-branch?

@daniel86 @asilx could you please clarify?

Web Interface query visits all solutions

When a query is called inside of the web interface, all solutions seems to be checked at the backend even though only one solution is shown. This is an issue for visualizing trajectories, because it causes all trajectories that fulfil the query to be visualized at the same time, rather than only one.

For example, if I call

simact_contact(Exp, Event, knowrob:'Cup', Obj), simact_start(Exp, Event,Start).

I get this correct result, which is the first contactEvent involving a cup:

Event = http://ias.cs.tum.edu/kb/cram_log.owl#TouchingSituation_EvO7fYw7
Obj = http://knowrob.org/kb/knowrob.owl#Cup_object_yYXWRWQpelZIFK
Start = http://ias.cs.tum.edu/kb/cram_log.owl#timepoint_11.414
Exp = PancakeEpisode1

If I write out the starting time using "writeln(Start)" at the end of the predicate, I see this in the shell when the query above is called:

http://ias.cs.tum.edu/kb/cram_log.owl#timepoint_11.414
http://ias.cs.tum.edu/kb/cram_log.owl#timepoint_21.590

http://ias.cs.tum.edu/kb/cram_log.owl#timepoint_21.590 is the starting time of the second contactEvent involving a cup. When I press "ctrl ;", this solution is shown in the browser as well, while at the backend nothing additional is written out. It seems to suggest that all solutions to a query are looked up when the query is called, and "ctrl ;" only shows the next solution without actual backtracking.

This behavior is not present if the same query is called in a knowrob shell rather than through the web interface.

New Features for the RoboHow Web Console

Hey there,

@hatguy and me just discussed some open topics that could be tackled in the near future within the RoboHow Web Console interface:

  • Dynamic listing (and loading) of experiments (contrary to having fixed a list of experiments in the query library)
  • Create default statistics/information blocks from experiment data (for a quick analysis/glance on what the experiment consists of/includes/resulted in)
  • Having tabs in the main display (e.g. switching between the 3D canvas and the plan tree, as both are pretty big and are displaying kind of "main information")
  • Make "play" control slider work, introduce a play/stop button, allow mouse interaction with it
  • Create personal query libraries (personalized in terms of creating own queries, and maintaining them for future container runs - strongly related to @knowrob's Docker integration)
  • General bug fixes (left-over glitches from the first implementation)

For a general idea of how this could look like in conjunction with what's already there, see here:
Web Console Sketch

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.