Download to read offline
Uploaded byTony Hirst
Robotlab jupyter
This document discusses setting up a residential robotics school with multiple EV3 bricks connected over a wireless network. The bricks would each have an SD card and WiFi card to allow them to be programmed from PCs running RobotLab software. Considerations include giving each brick a static IP or domain name for easy identification. An interactive tablet interface is suggested. The EV3 bricks run a Debian-based ev3dev operating system and support running Python/IPython scripts from the on-board controls or via SSH from a host PC. Connecting an IPython kernel on the EV3 to clients like Jupyter notebooks on a host PC is described. Integrating RobotLab with the Jupyter/IPython ecosystem to allow programming robots from a web browser
More Related Content
Robotlab jupyter
- 1.
- 2. Residential School Setup– Networking ev3 brick SD Card wifi Card ev3 brick SD Card wifi Card ev3 brick SD Card wifi Card PC_A RobotLab PC_B RobotLab PC_C RobotLab Wifi Router Up to 12 student groups, each with their own ev3 brick. Bricks are networked via a wireless card and programmed from a PC
- 3. Residential School Setup– Networking Considerations: • ev3 bricks should ideally have static IP addresses or domain names so they can be associated with particular PCs • a touch screen / tablet computer interface would allow us to run the activity in an even more interactive and social way
- 4. ev3dev ev3 brick SD card Wificard ev3dev (linux) ev3dev • Debian Linux based o/s • Can run py/ipy executable script files using on-board controls
- 5. Executable file transfer PC RobotLab ev3dev (I)Python .py/.ipy file .py/.ipy file Filetransfer PCev3 ev3dev ssh connections are possible between “host” and ev3 “client” terminal ssh connection
- 6. IPython kernel accessvia ssh PC iPython client ev3 iPython kernel Connection details Session config iPython session An iPython session running on the ev3 client can be accessed from an iPython client running on the host, e.g. via ssh Python
- 7. Accessing IPython kernelprocesses iPython Kernel zeroMQ (JSON) IPython Client Example clients supporting remote connection include: • Terminal Console (IPython console) • Qt Console (IPython qtconsole) Python Session config
- 8. ev3 RobotLab Jupyterclient Hook RobotLab into iPython zmq? RobotLab editor IPython client Python IPython Kernel zeromq
- 9. Screenshot of theSpyder editor showing an integrated IPython console and remote IPython kernel connection dialogue
- 10. Crude sketch ofhow we might add an IPython console to RobotLab
- 11. Web browser The Jupyterecosystem iPython Kernel Jupyter server R Kernel Javascript Kernel Jupyter notebook zeromq zeromq zeromq tornado http
- 12. RobotLab IPython client Plugin to the Jupyter kernel ecosystem? iPython Kernel Javascript Kernel zeromq zeromq zero mq interface RobotLab editor Python Javascript
- 13. EV3 -1 IPython Jupyterhub EV3 -N IPython User 1 Notebook User N Notebook Jupyter Server 1 Jupyter Server N EV3 - 2 IPython User 2 NotebookJupyter Server 2 User Passwordless ssh Passwordless ssh Passwordless ssh HTTP HTTP HTTP
Editor's Notes
- #2 Some quick thoughts on how we might use python on the Lego ev3 brick
- #3 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.
- #4 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?
- #5 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.
- #6 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.
- #7 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.
- #8 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.
- #9 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.
- #10 Example of the layout of a traditional IDE with an integrated IPython console.
- #11 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.
- #12 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.
- #13 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.