Some quick thoughts on how we might use python on the Lego ev3 brick
The residential school set-up will need to support up to 12 student groups, each with their own ev3 brick and programming environment (desktop/laptop/tablet computer). Programming environments will be connected to bricks via a wireless network connection.
The residential school robotics activity is run in a convivial way with students participating in a range of ‘show and tell’ challenges through the day. One problem with the current set-up is that students must return to their group desktop computer to reprogramme the robot.
With the possibility of executing programme fragments in an interactive way using an iPython interpreter on the brick, it would be interesting if the RobotLab interface could run on a tablet computer so that we could do away with the formal layout of desktop computers all together.
The easiest way of connecting a brick to a network is for it to obtain a dynamically allocated IP address issued by the network router when a brick connects to the router. This approach is problematic because we want groups work just with their brick, from just their computer. Bricks may be switched off and on throughout the day.
Each brick will run an operating system (ev3dev) that boots from a microSD card. The card could include information unique to each card. Could such information be used to uniquely identify and name machines when obtaining IP addresses?
The ev3dev environment is a Debian Linux o/s that the ev3 brick can boot into from a microSD card.
The o/s can drive a USB wifi dongle. Remote ssh connections are supported into the ev3dev environment on the brick.
ssh connections can be opened to the brick over the network.
One way of running Python programmes on the brick is to copy an executable python script onto the brick and then run it from a file selector on the brick provided by the ev3dev UI.
The ev3dev o/s can run IPython processes (IPython kernels) to which a remote IPython client can connect.
Remote clients include the IPython console and iPython QT console. Several Python editors (with integrated IPython consoles) claim to be able to connect to remote iPython kernels. It seems that Jupyter notebooks cannot connect to remote iPython kernels.
When an iPython kernel is started, it generates a connection file that other clients can use to connect to the kernel. Several clients can connect to the same kernel at the same time.
For connections from an IPython console or IPython QT console connected to the brick over the network, performance seems to be reasonably good.
ev3dev can run an IPython notebook server, with the notebook accessed via a browser on a remotely connected machine, but performance is sluggish.
The IPython kernel – which provides things like tab completion as well as simple error reporting – communicates with a client via zeromq. A session config file created by the client that starts up an iPython kernel, identifies how additional clients can connect to the kernel.
Some Python editors, such as Spyder, claim to support connections to remote/pre-existing IPython kernels via an integrated IPython console.
One way of using RobotLab would be to generate Python code that is passed to an iPython client that then communicates with an IPython kernel running on the brick.
Example of the layout of a traditional IDE with an integrated IPython console.
If the application runs as a desktop application, it should be easy enough to integrate an IPython console.
However, this approach goes against the HTML / browser based or electron app UI requirement.
Jupyter notebooks provide an example of a browser based UI. The Jupyter server manages zeromq connections to IPython kernels and runs a tornado webserver that manages the HTML UI via http.
However, the Jupyter security model seems to suggest that the Jupyter server will only connect to kernels it has created locally, and will not connect to remote kernels otherwise created?
An IPython notebook server can be run on ev3dev on the brick, but performance is sluggish.
One benefit of developing RobotLab as an IPython client is that it plugs in to the Jupyter/IPython kernel ecosystem.
As such, custom language packs defined for the editor could be used to generate scripts that could be executed on other Jupyter/IPython kernels which are available for an increasing number of languages ( https://github.com/ipython/ipython/wiki/IPython-kernels-for-other-languages ).
The Jupyter/IPython project is an active one with participants working in both research and education. The RobotLab style interface would provide a valuable addition to the suite of possible IPython clients, particularly for introductory / elementary programming.
Residential School Setup – Networking
Up to 12 student
groups, each with their
own ev3 brick.
Bricks are networked
via a wireless card and
programmed from a PC
Residential School Setup – Networking
• ev3 bricks should ideally have static
IP addresses or domain names so
they can be associated with
• a touch screen / tablet computer
interface would allow us to run the
activity in an even more interactive
and social way
• Debian Linux based o/s
• Can run py/ipy
executable script files
using on-board controls
Executable file transfer
ssh connections are possible between “host” and ev3 “client”
IPython kernel access via ssh
An iPython session running on the ev3 client can be accessed
from an iPython client running on the host, e.g. via ssh
Screenshot of the Spyder editor showing an integrated IPython console
and remote IPython kernel connection dialogue
Crude sketch of how we might add an IPython console
The Jupyter ecosystem
RobotLab IPython client
Plug in to the Jupyter kernel ecosystem?
zero mq interface
EV3 - N
EV3 - 2