enki-community / enki Goto Github PK

Introduced in 673f995, enki/Geometry.cpp#L158.

The current camera and object controls are problematic:

• they are complex
• they require a middle mouse button, sometimes not available

Taking inspiration from existing work available elsewhere on the net would be good, for instance trackball_turntable_pan.js (demo):

The TurnTable Pan trackball is an extension of the TurnTable trackball just presented, that also allow the user to pan across the object, changing the center of rotation. Still very simple to use, it gives more freedom to explore the objects, especially when zooming close to the surface. Left mouse button + horizontal mouse movement rotates the object around its vertical axis, and left mouse button + vertical mouse movement tilts the view direction up or down; mouse wheel zooms in and out; CTRL + left mouse button + mouse movements (or middle mouse button + mouse movements) pans across the object. Double-click on a 3D model, and 3DHOP will re-center the trackball on the clicked point and zoom in a little (using a smooth animation).
This trackball is controlled by a "phi" angle of rotation around the vertical axis, a "theta" angle of view tilt, a view "distance" acting like a zoom, plus the "panX" "panY" "panZ" panning parameters.

In our case, we have in addition the interaction with robots, but the effect of actions could depend on whether the cursor is on a robot or outside.

The pyenki module fails to build due to missing enki includes:

python/CMakeLists.txt:

20c20
<               include_directories(${PYTHON_INCLUDE_DIRS})

---
>               include_directories(${PYTHON_INCLUDE_DIRS} ${enki_SOURCE_DIR})

hello,

As part of the programming project which consists in distributing the enki display, we use dashel.
We encounter a problem with the Windows platform.

Client::Client(const string& ip, const int port) :
		init(true),
		inputStream(0)
	{
		string remoteTarget = "tcp:" + ip + ";port=" + to_string(port);
		inputStream = connect("stdin:");    <———————  ERREUR sous windows
		remoteStream = connect(remoteTarget);
		sendString(remoteStream, "I want to connect!\n");
	}

It fails during the connect(stdin).

Error:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
terminate called without an active exception

As the client code is similar to the example "chat.c" contained in dashel, I try to make it run it turns out that it does not either:

ci@INRIACI-OT9HJCJ MINGW32 /c/msys32/home/ci/src/dashel/build
$ ./chat.exe &
[1] 3844

ci@INRIACI-OT9HJCJ MINGW32 /c/msys32/home/ci/src/dashel/build
$ ./chat.exe tcp:localhost toto
Cannot change standard input mode to immediate.

I'm open to any idea about how I could fix this.

Thanks.

There are magic numbers at different places in the code: walk through it and remove them.

Apply patch in pyenki-thymio2.patch.zip

As a first step, this can be done by embedding raw GL commands as examplified here:
http://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html

This should be available as an alternative viewer for Enki, in parallel to the one based on QGLWidget.

Invoking

make 
make install

fails with

Install the project...
-- Install configuration: ""
CMake Error at cmake_install.cmake:36 (file):
  file INSTALL cannot find "/home/damjan/devel/enki/build-release/html".

Makefile:61: recipe for target 'install' failed

Running make doc after make enables a successful make install.

Observed on Ubuntu 16.04.

Does anyone have the idea of how to visualize the robots in enki simulator?

Hello!

I am currently trying to incorporate some friction into the world to simulate realistic robot-wall collisions. In order to I do this, I simply set the dryFrictionCoefficient to 1 for all wall objects and the e-puck. However, this doesn't seem to impede the robot dragging along the wall so far as I can see.

I also thought to make the collisions perfectly inelastic (collisionElasticity = 0) such that the robot gets stuck on the wall if it collides with it. Again, I had no luck observing a real inelastic collision.

I was just curious if there is something I am missing. Any advice on how to overcome this problem is much welcome.

Here is a fix to compile/build for python3 and add support for Thymio2 in pyenki: rcr-enki.patch.zip

roberto@debian:~/.../enki$  git apply rcr-enki.patch

or

C:\...>  git apply rcr-enki.patch

Linux

roberto@debian:~/.../enki$ cmake -DCMAKE_BUILD_TYPE=Release -DOpenGL_GL_PREFERENCE=GLVND .

Windows (with Visual Studio Tools 2019, boost 1.7.6 and Qt5)

Build Boos 1.7.6

C:\...> bootstrap.bat vc142
C:\...> b2 --clean
C:\...> b2 --build . --with-python --prefix=C:\Users\titos\Documents\Software\boost176 ^
        address-model=64 variant=release link=shared threading=multi runtime-link=shared install

Build Enki

C:\...> cmake ^
        -DQt5_DIR=C:\Qt\Qt5.12.10\5.12.10\msvc2017_64\lib\cmake\Qt5 ^
        -DBoost_INCLUDE_DIR=C:\Users\titos\Documents\Software\boost176\include\boost-1_76 ^
        -DBoost_LIBRARY_DIR_RELEASE=C:\Users\titos\Documents\Software\boost176\lib ^
        -DBoost_PYTHON39_LIBRARY_RELEASE=C:\Users\titos\Documents\Software\boost176\lib\boost_python39-vc142-mt-x64-1_76.lib .
C:\...> cmake --build . --config Release

I use this structure of directories

Hello,
for me it's easier when I now witch version of enki is used by the current Aseba release.
Maybe add a version tag like aseba-1.5.x or own versioning.

Kind regards,
THS-on

Enki knows about different kinds of robots but does not provide a way for a client program to discover them. Since every VM must provide a node description, there is already a mechanism for reflection, so in some cases isn't strictly necessary to know the concrete robot classes in advance. A client program could be linked with different versions of Enki that provide different sets of robots.

Aseba Playground provides a complicate mechanism for doing this, with glue for Aseba and Dashel, in playground.cpp. It might be cleaner to handle this in Enki.

Hello,
I'm trying to package the new version of enki for Arch, but the build is crashing always.

[ 95%] Linking CXX executable enkiplayground
[ 95%] Built target enkiplayground
Scanning dependencies of target pyenki
[ 97%] Building CXX object python/CMakeFiles/pyenki.dir/enki.cpp.o
/home/user/aseba/aseba-tmp/src/enki/python/enki.cpp: In Funktion »void init_module_pyenki()«:
/home/user/aseba/aseba-tmp/src/enki/python/enki.cpp:399:9: Fehler: ungültige Verwendung des nicht-statischen Datenelementes »Enki::World::takeObjectOwnership«
  World::takeObjectOwnership(false);
         ^~~~~~~~~~~~~~~~~~~
In file included from /home/user/aseba/aseba-tmp/src/enki/python/enki.cpp:40:0:
/home/user/aseba/aseba-tmp/src/enki/python/../enki/PhysicalEngine.h:459:8: Anmerkung: hier deklariert
   bool takeObjectOwnership;
        ^~~~~~~~~~~~~~~~~~~
make[2]: *** [python/CMakeFiles/pyenki.dir/build.make:63: python/CMakeFiles/pyenki.dir/enki.cpp.o] Fehler 1
make[1]: *** [CMakeFiles/Makefile2:292: python/CMakeFiles/pyenki.dir/all] Fehler 2
make: *** [Makefile:128: all] Fehler 2

Is this a compiler or a program issue?

THS-on

Hi, there,
I'm wondering if there is any more examples for some more details on api? And also if you can distribute a python branch for convenient?

The class for a polygon is spelled Polygone, using the French wording rather than the English wording.

Enki provides a FastRandom class in Random.h, as well as distributions such as gaussianRand(). However, the latter does not use the former. This is very confusing for users.

Apply this patch to support LEDs in EPuck and Thymio2 robots inside pyenki rcr-pyenki-leds.patch.zip

All the interactions with the robots must be done in controlStep()?

Could a thread call the robot's methods?

Gracias

"Fix buffer overflows (#59)" (5d36c42) break the IR sensors

Clicking on close window button finished the app with a Segmentation fault error

Tested on enkiplaygorund and pyenki

Enki has reached its complexity limit with its current design. After a discussion with @dmiklic, we think it should be refactored into an Entity Component System (https://en.wikipedia.org/wiki/Entity_component_system), as this approach has proved successful in the game industry.

Currently, Bluetooth is simulated through a hack with a BluetoothBase object in World. This should be generalized by defining a WorldInteraction base class.

If Python 3 is the default Python version, Enki does not compile properly its Python bindings (see http://paste2.org/U13UWgna)

It would be helpful to have enkiConfig.cmake, generated by enkiConfig.cmake.in, like in dashel (see https://github.com/aseba-community/dashel/blob/master/dashelConfig.cmake.in)

Hello everyone,

I was wondering how to add a new model to Enki. I'm currently working on a simulator project for the robotics department of my university, using Enki as physics engine. A spin-off from the same university has created a robot called Robobo, and I would like to add it to the program for future simulations. In fact It would be nice to add the characterization of the sensors and actuators to the engine ( I guess there won't be a problem in case it is interesting to add it later to the main repository).

I have seen the texture map of the robots within the folder viewer, I observed that the models are defined by the "face_indicies" matrix, but I'm not sure about its structure.

I have access to different formats of the model of the Robobo, but I would rather prefer not to mess with OpenGL in the renderScene method by adding it on a different way than the one already implemented.

Could you tell me how exactly did you create the vertex matrix? Is there any converter to translate .obj or alike to that format? I guess that you didn't make every robot by hand.

Thanks in advance!

When using the viewer, if you select an object by left clicking on it, and then, you hold right click and left-click again, this time outside the robot, the object disappears.

...leading to problems such as resources being not available.

Hello,

I'm building (successfully) enki at my OS X 10.11 and there are few warnings. I beleave you can get rid of them easily to deliver more smooth building process :)

[ 58%] Building CXX object viewer/CMakeFiles/enkiviewer.dir/Viewer.cpp.o
/Users/tomaskrejci/aseba/enki/viewer/Viewer.cpp:563:29: warning: 'gluNewQuadric' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations]
                        GLUquadric * quadratic = gluNewQuadric();
                                                 ^
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:267:20: note: 'gluNewQuadric' has been explicitly marked deprecated here
extern GLUquadric* gluNewQuadric (void) OPENGL_DEPRECATED(10_0, 10_9);
                   ^
/Users/tomaskrejci/aseba/enki/viewer/Viewer.cpp:567:4: warning: 'gluCylinder' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations]
                        gluCylinder(quadratic, object->getRadius(), object->getRadius(), object->getHeight(), 32, 1);
                        ^
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:251:13: note: 'gluCylinder' has been explicitly marked deprecated here
extern void gluCylinder (GLUquadric* quad, GLdouble base, GLdouble top, GLdouble height, GLint slices, GLint stacks) OPENGL_DEPRECATED(10_0, 10_9);
            ^
/Users/tomaskrejci/aseba/enki/viewer/Viewer.cpp:571:4: warning: 'gluDisk' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations]
                        gluDisk(quadratic, 0, object->getRadius(), 32, 1);
                        ^
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:255:13: note: 'gluDisk' has been explicitly marked deprecated here
extern void gluDisk (GLUquadric* quad, GLdouble inner, GLdouble outer, GLint slices, GLint loops) OPENGL_DEPRECATED(10_0, 10_9);
            ^
/Users/tomaskrejci/aseba/enki/viewer/Viewer.cpp:573:4: warning: 'gluDeleteQuadric' is deprecated: first deprecated in OS X 10.9 [-Wdeprecated-declarations]
                        gluDeleteQuadric(quadratic);
                        ^
/System/Library/Frameworks/OpenGL.framework/Headers/glu.h:253:13: note: 'gluDeleteQuadric' has been explicitly marked deprecated here
extern void gluDeleteQuadric (GLUquadric* quad) OPENGL_DEPRECATED(10_0, 10_9);
            ^
/Users/tomaskrejci/aseba/enki/viewer/Viewer.cpp:702:50: warning: expression with side effects will be evaluated despite being used as an operand to 'typeid' [-Wpotentially-evaluated-expression]
                                const std::type_info* typeToSearch = &typeid(**it);

On a clean system (enki not previously installed), make fails with the following error:

In file included from /home/damjan/devel/enki/enki/interactions/IRSensor.cpp:34:0:
/home/damjan/devel/enki/enki/interactions/IRSensor.h:37:33: fatal error: enki/PhysicalEngine.h: No such file or directory
compilation terminated.

Changing the capitalization on line 3 of the top-level CMakeLists.txt file from project(Enki) to project(enki) fixes the issue.

Hello,
I could upload a new package to Debian repositories, based o today's export of the master branch.

As this package closes an important bug, https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=enki-aseba&archive=no&pend-exc=pending-fixed&pend-exc=fixed&pend-exc=done&sev-inc=critical&sev-inc=grave&sev-inc=serious
whose title was « enki-aseba: Python2 removal in sid/bullseye », I dared to give a version number 1.6.99

Please can you add some new Tag like "enki-1.7.0" in the repository as soon as you feel that the current version is
distributable? So I shall add this repository to the debian/watch automaton, and be notified when the debian package must
be upgraded in the future.

The new package should reach https://packages.debian.org/source/sid/enki-aseba in a few hours.

Best regards, Georges.

Remote the magic 7% noise from the IRSensors class

Commit lead to compilation failure on my setup:

/usr/bin/ld: ../enki/libenki.a(Types.cpp.o): réadressage de R_X86_64_32S en vertu de « .rodata.cst8 » ne peut être utilisé lors de la création d'un objet partagé; recompilez avec -fPIC
../enki/libenki.a : erreur lors de l'ajout de symboles : Mauvaise valeur

Hello, is there the _librlcom_ library implemented in the functionality of the E-puck model in ENKI. If yes, how can one make use of it.

If i isn't implemented, does any body know how to adapt the model so that it enables this functionality ?