Questions: ev3dev2 and gears

[DJuego]

Hey! After a long time I have been missing, here I am again. :-)

We want to dedicate this edition of our educational project to the simulator/real world comparison. For the first time, we will work with Gears and EV3 units in parallel. This is something we have already done with Open Roberta.

At the moment I have run for the first time the code base generated by Gears on an EV3 brick. In fact, this code:

#!/usr/bin/env python3

# Import the necessary libraries
import time
import math
from ev3dev2.motor import *
from ev3dev2.sound import Sound
from ev3dev2.sensor import *
from ev3dev2.sensor.lego import *
from ev3dev2.sensor.virtual import *

# Create the sensors and motors objects
motorA = LargeMotor(OUTPUT_A)
motorB = LargeMotor(OUTPUT_B)
left_motor = motorA
right_motor = motorB
tank_drive = MoveTank(OUTPUT_A, OUTPUT_B)
steering_drive = MoveSteering(OUTPUT_A, OUTPUT_B)

spkr = Sound()
radio = Radio()

color_sensor_in1 = ColorSensor(INPUT_1)
ultrasonic_sensor_in2 = UltrasonicSensor(INPUT_2)
gyro_sensor_in3 = GyroSensor(INPUT_3)
touch_sensor_in4 = TouchSensor(INPUT_4)
# Here is where your code starts

Apparently it works! but i need comment the lines:

from ev3dev2.sensor.virtual import *

and

radio = Radio()

My question is:

What is the best way to work with gears and the ev3dev brick? Is there a modified version of the ev3dev2 API (see link) that should be installed? Or is there an option to generate only compatible code?

Thank you very much for Gears!

DJuego

PS: About this; Is there a clever way to upload Gears files to ev3dev with minimal user assistance? :-) (My environment is Windows 10 x64)

[QuirkyCort]

The "Radio" used in Gears is a virtual component that doesn't exists in the real EV3. Well, the EV3 does have a bluetooth radio, but it is...

1. Not available in the ev3dev Python library
2. Has a completely different API from the one in Gears
3. Is a real pain to use

Besides the Radio, the GPS, Pen, and Object Tracker are also virtual sensors that cannot be used on a real ev3.

Other than that, everything should work the same on an ev3 running ev3dev. Gears implements a subset of the ev3dev python API, so if anything works differently, it's a bug on Gear's end.

The inclusion of the "from ev3dev2.sensor.virtual import *" and "radio = Radio()" by default was bad planning on my part. Not sure why I didn't make it a component that can be excluded from the robot. I think the cleanest approach is to change the Radio into a component (...but a special one without a port number?), and clearly document it as a virtual sensor that's not available on a real ev3. But I'm open to other suggestions.

For uploading, I believe vscode has a ev3dev plugin that makes it rather simple.

[DJuego]

Yes, yes. I knew what Radio and Sensor.virtual was. And I fully understand their reason for being, and that they don't work. I simply wanted the slight clarification you have provided with your response. Thank you!

Yes. It seems to me a quite natural idea to include the radio as a (plug/unplug) component, even if it has no associated port. It would also be interesting that if the robot does not have "virtual sensors installed", the virtual import is not done (it it is possible).

By the way; this brings me to another question about "static" (not mobile) robots that I will ask you in another issue later.

Thank you for your careful answer, @QuirkyCort!

[sgmurray]

@QuirkyCort How about checkbox options for the Radio and Object Tracker on the main robot body?

@DJuego I am interested in whatever you would be willing to share about how you plan to use GEARS and EV3 parallel.

1. Are you planning on programming in Blockly or Python?
2. What kinds of robots and worlds were you planning on building? Are there any robots you would like to build, but can't because of limitations in GEARS.
3. How is using both in parallel better than just using one or the other?

[QuirkyCort]

Checkboxes is a simple option, but a drawback is that it won't be obvious to the user whether these components are present.

[DJuego]

Are you planning on programming in Blockly or Python?

Good point! Just tomorrow our teaching team will have a meeting to decide how we will respond to that question, among other things. There are arguments on both sides.

In the last editions for high school (not elementary school) we have always used Python with ev3dev. However we used a custom API that functioned as a thick wrapper for the ev3dev2 API. In addition, we included facilities tailored for the challenge we were facing that year. Every year is a different challenge...

What kinds of robots and worlds were you planning on building? Are there any robots you would like to build, but can't because of limitations in GEARS.

Definitely ,most of the robots we have used in our challenges are not implementable in Gears. :-) Our robots are adapted to the challenges of each edition. Challenges that we design ourselves. Some are based on designs we found on the net, and other times we design them from scratch. We try to make the challenges different from each other, each one with a "spark" that makes it special.

If you are curious, and @QuirkyCort gives his permission I can create a topic that, with a gallery of images, will hopefully illustrate this point.

However, for this new edition, we plan to adapt to the current capabilities of Gears. We can do this because we have full freedom to design workshops and challenges. Gears is part of the spark of this edition!

How is using both in parallel better than just using one or the other?

Well. On this occasion we want to focus on the simulator vs. real world topic. We want to show the indisputable advantages of working with a simulator. For example; to debug programs before running them on the real robot. But also to show (and explain), in a practical way, the limitations of a simulation. Not only in the field of robotics but also in other domains. Good. That's the concept. We'll see how it all turns out. ;-}

DJuego

[sgmurray]

@DJuego I am very interested in seeing the kinds of robots you have used in past challenges and discussing whether it would be worth improving GEARS to be able to simulate such robots.

We want to show the indisputable advantages of working with a simulator. For example; to debug programs before running them on the real robot. But also to show (and explain), in a practical way, the limitations of a simulation.

Here is an unsolicited suggestion. How about a line maze solving challenge? https://www.youtube.com/watch?v=WutS7l4mxbg

The programming required is complicated enough (especially if you only use one color sensor) that being able to debug in the simulator will be useful. However, once you get the robot working in the simulator, some tuning will be needed to make it work on the real robot.

[QuirkyCort]

If you are curious, and @QuirkyCort gives his permission I can create a topic that, with a gallery of images, will hopefully illustrate this point.

Please do. I'm curious as well.

Here is an unsolicited suggestion. How about a line maze solving challenge?

I've seen this before, but it didn't occur to me to make this challenge in Gears. Maybe put this as an option in the maze world. The algorithm to generate the maze is the same, only difference is the use of lines instead of walls. In the video, how did the robot figure out it's at the end zone?

[sgmurray]

This is my guess at how they do it. They tell the robot the position of the end zone relative to the start. The robot knows where it needs to go, it just doesn't know the path to take to get there. As the robot explores the maze, it uses its rotation sensors to continuously update its estimate of its position. If the estimated position is close enough to the end zone position, the robot assumes it is at the end zone.