Simulator for ev3dev or ev3dev-python

[DJuego]

Hi!

I have ten hours of experience with ev3dev-python and I am pretty pleased. In fact I am considering seriously to use python-ev3dev in a educational environment.

The only weakness that I find is lacking of a simulator for learning/experimenting/working without robot.

Of course, to develop an accurate emulator is a HUMONGOUS project (!!!). However a toy simulator , similar to Open Roberta simulator would be a fantastic addition: A 2D top-down view of a two drive wheels mobile robot offers potential for learning and it is an inmediate visual feedback

Any related projects (robotic simulators in python): here, here and here

Any thought, suggestion, hint, idea or link in this direction? 👍

DJuego

P.S V-Rep seems promising. Would it be adapted?

[WasabiFan]

This is a very interesting concept. Firstly, I think that something like this would need to be implemented at the language binding/user program level, as both emulating the OS and drivers in situ would be a lot of work to do efficiently without a bunch of installation work. However, I think it would be relatively easy to modify the existing Python library so that file I/O could be replaced with proper calls to a simulated environment (preferably something that could be re-used by others as well). However, such an environment would need a "mock" implementation of the ev3dev motor and sensor drivers; this presents the challenge of keeping them in sync with changes to the real ones, because nuances can make a large difference. Optimally, you'd want a way to compile the existing drivers standalone for userspace so that you could both feed them your own input and intercept writes to PWM for motors. @dlech am I correct in assuming that there is no means of doing this that wouldn't cause difficulties in core driver maintenance? Do you have any ideas in this area?

In the end, I think that all the wrapper logic around the motor drivers would be easy, assuming any physics would be limited to 2D and an simple robot model. It's just a matter of getting the realistic logic working that translates ev3dev driver inputs to motor power outputs.

[ensonic]

@DJuego did you try the OpenRoberta system (https://lab.open-roberta.org). This has a built-inb simulator for the ev3/nxt. It is a bit higher level (we're using this in classrooms with kids staring 3rd grade).

[DJuego]

Thank you for your comments, @WasabiFan, Yes, yes. That is the idea. In the same vein of what i was thinking. Perhaps it is more easy to use the remote API of V-Rep. See this example.

@ensonic: Yes, yes. I know OpenRoberta System. :-) It is a powerful tool (intuitive, free, online but it is possible to work offline,...). In fact, I request to translate that simulator concept to ev3dev-python.

P.S:@ensonic, Do you use ev3dev with OpenRoberta? Does it work well? Or is it better to use the operating system for Open Roberta? What is your experience?

[ensonic]

@DJuego are you sometimes in IRC or the gitter chat? Don't want to hijack this bug report for discussion. Anyway, as quick pointers:

• works offline: run the openroberta server on a raspberry pi 3 (I am doing this for events)
• using ev3dev: you need a custom firmware for the ev3 anyway, if you use lejos, openroberta generates java, if you use ev3dev then openroberta generates python. I wrote the ev3dev connector for openroberta (https://github.com/OpenRoberta/robertalab-ev3dev) and I've been using it for quite a few events.

[dlech]

@dlech am I correct in assuming that there is no means of doing this that wouldn't cause difficulties in core driver maintenance? Do you have any ideas in this area?

I would not recommend using Linux drivers as part of the simulation stack. It would limit you to running simulations on Linux only and add unnecessary complexity.

However, I think it would be relatively easy to modify the existing Python library so that file I/O could be replaced with proper calls to a simulated environment

I think this is the "right way" to go about doing something like this.

[WasabiFan]

The main issue that I see here is the ev3dev simulation logic itself: This type of virtual environment would need to have an implementation of the motor drivers available to translate driver input to duty cycle. Do you have any suggestions there? Or is it simple enough that an alternate implementation could be written and parity maintained without issue?

[dlech]

This type of virtual environment would need to have an implementation of the motor drivers available to translate driver input to duty cycle

Not necessarily. If you are telling the motor to run at a fixed speed, then just have the simulation run the motors at that speed. If you are making a simple OpenRoberta-style simulator, there is no need to model the actual physics of the motor. For example, if speed_sp=400 and the simulation has a wheel diameter of 20 pixels, then the robot should be moving across the screen at 400 tacho counts per second / 360 tacho counts per rotation * (3.14 * 20) pixels per rotation = 69.8 pixels / second. Duty cycle does not come in to this equation at all.

If you want a simulator that is fancier than that, then you are beyond my expertise. 😃

[WasabiFan]

The problem is that you need to expose something resembling the interface of the real drivers. That means that commands, polarity, position, input constraints, PID dynamics (for positional control), ramping, state and stop actions would all need to be operational as they are in the real environment for consistent results. You could, of course, decide that it would only support the speed-control mode, immediate breaking, "running" state, etc., but at that point the simulation would probably not actually simulate real circumstances and would fail when you tried to use more than just the bare essentials of functionality.

I'll have to think over how this could work. There isn't an obvious answer that I can come up with but maybe I'll think of something.

[dwalton76]

Of the simulators linked above do we know if any them support a plugin architecture where we could swap out them emulating say EVG-3 for a block of Python code?

[dwalton76]

I started playing around with making a very basic simulator. The init goal is just to have a single large motor appear as connected, will worry about simulating functionality later.

The problem is that we need to write to /sys/ which you cannot do from user space, even as root. What if we could trick the kernel into thinking a motor is connected...that would get us past the inability to write to /sys/.

@dlech when a motor is connected how does the kernel detect that it is connected?

[dlech]

You could write a dummy kernel driver to simulate the sysfs structure, but I think it would be much easier to just replace the functions that wrap calls to sysfs with something else. If this simulator is going to run on non-Linux systems, then that is also your only choice. FWIW, you can find the EV3 output port device connection manager here.

[WasabiFan]

In my mind, I think the ideal structure would be to intercept calls one level up: make an abstraction layer between the core library code and file I/O, then have an implementation of that layer which calls a separate Python module which operates the simulator. That avoids the file I/O and works cross-platform. Preferably the simulator code would expose an interface which is also usable by other languages.

[ensonic]

Can we mount an overlayfs to sysfs to shadow the real files? Or we have a fusefs replicating the relevant sysfs structure and the language bindings try two locations (first the fusefs one, then the sysfs one). We could even use some API to set the prefix and thus select between real and emulated.