The authoritative official documentation should be followed to get started with ev3dev. This page provides some additional pointers that may help people set things up for a Windows-based development rig. Use these instructions at your own peril: they may be inappropriate for your situation, they may fail to produce the desired results, or they may even damage your system.
Initializing the MicroSD card
Make sure you get a MicroSD card that satisfies the documented requirements of having a capacity between 2 and 32 Gb, and supporting the MicroSD and/or MicroSDHC formats rather than the MicroSDXC format. My 8Gb Philips card had the correct buzzwords on the packaging and seems to work well enough. Plus it came with an adapter that fits the card reader on my Windows machine.
The official instructions tell you to use Etcher to flash the ev3dev image file onto the MicroSD card. My attempts to do so kept failing until I ran Etcher as an administrator. With administrative privileges, Etcher flashed the card successfully on the first attempt.
Running ev3dev
Turn off your EV3 brick and insert the MicroSD card into the slot. Note that you’ll need some pretty small fingers and/or long fingernails to extract it again, because the EV3 brick does not provide a spring-powered ejection mechanism. I usually have to resort to using tweezers or even pliers, risking damage to the card. Although I haven’t tried it yet, it looks like an added homebrew pull tab would make extraction much easier.
When you turn on the brick with the MicroSD card inserted, the system will boot the ev3dev environment, culminating in the display of a menu driven application on the LCD. This GUI is called Brickman, and it allows you to interact with ev3dev when the system is disconnected from a PC. You’ll probably use it mostly (or even exclusively) to launch programs from the File Browser menu.
USB connectivity
The official instructions for establishing a network connection differentiate between connecting to the Internet or just tethering the EV3 brick to your PC. Since an Internet connection makes it easier to add optional packages to the brick’s Linux environment later, choose that option unless you’re sure the vanilla ev3dev distribution will suffice.
In Windows 10, the Bluetooth & other devices window will list your Remote NDIS Compatible Device but won’t allow you to configure its network settings. Instead you’ll need the Devices and printers app, which can be opened using the hyperlink in the Related settings section near the bottom of the window.
Both the Bluetooth & other devices and Devices and Printers windows may contain a device named EV3, which represents a (Bluetooth) connection you may have established earlier from the Lego EV3 desktop software. As documented, the (USB) connection to the ev3dev environment is listed as a Remote NDIS Compatible Device, so you’ll configure that one.
SSH connectivity
The ev3dev environment comes with a prefab account named robot, whose password is initially set to maker. Security buffs will want to change the password, and perhaps take a look at some other stuff that comes pre-configured. Mere mortals may wish to create a PuTTY shortcut on their PC that automatically passes the credentials when connecting to the brick:
"C:\Program Files\PuTTY\putty.exe" robot@ev3dev -pw maker
Omit the -pw <your-password> clause to enter the password manually when you connect.
File system connectivity
You’ll probably develop applications on your PC, using ev3dev’s command line or on-screen File Browser to run the finished programs. Since SSH connectivity comes preconfigured with ev3dev, file transfer based on SCP should be supported out of the box. But for development a persistent file system connection is more convenient:
- either mounting a PC directory onto ev3dev’s file system (e.g. using NFS),
- or exposing an ev3dev directory as a network share to the PC (e.g. using Samba).
Exposing a PC directory to the brick is preferable, since your PC’s file system is likely to be faster than ev3dev’s. Either way, the idea is that when the PC updates a file, the updated version is available immediately on the brick, without needing to copy it as a separate step.
While this sounds great and I got the NFS option to work as described below, I found the connection to be too unstable for practical use. YMMV, but in the end I resorted to using WinSCP to manually copy files to the brick when they need updating.
NFS sharing from Windows
You can share your Windows development directory (or any other directory) over NFS, so that the files can be accessed directly from the brick. The official documentation on setting this up was perhaps based on the SourceForce project for WinNFSd, which looks like it isn’t being maintained anymore. I opted to use the newer version (2.4.0 at the time of writing) found in a github repository. The download here consists of only the executable, so you won’t need to extract a ZIP file. Just put the .exe anywhere on your system.
The documented command line starts WinNFSd without opening a window, which I found inconvenient since it hides logging from view. Additionally, it wasn’t clear to me how the shared Windows path (C:\Source\ev3dev in my case) should be transcribed as a *nix path into the systemd mount file on the EV3 brick. So I had WinNFSd explicitly expose the directory as /ev3dev to the EV3 brick:
WinNFSd.exe C:\Source\ev3dev /ev3dev
When starting WinNFSd for the first time, Windows Defender will want to know whether the server should be exposed through the firewall. Allow this for “Public networks”, which the USB connection apparently qualifies as. But note that the directory may then be accessible to anyone attempting to connect to your PC over any “Public network”.
NFS mounting on ev3dev
Follow the official documentation to create a systemd mount file on the EV3 brick. Find out your PC’s IP address by inspecting the IPv4 Properties for the network adapter named Remote NDIS Compatible Device. Since mine was 192.168.137.1, I’ve included that value in the sample mount file below.
WinNFSd sadly does not support NFS version 4, so you’ll need to connect to the PC using protocol version 3 or lower. Since the correct version wasn’t automatically negotiated for me and I couldn’t find the /etc/nfsmount.conf file to configure this on a system-wide basis, I added an nfsvers option to the systemd mount file at /etc/systemd/system/home-robot-nfsshare.mount to make things work:
[Unit] Description=Windows nfs share After=network.target [Mount] What=192.168.137.1:/ev3dev Where=/home/robot/nfsshare Type=nfs Options=nfsvers=3 [Install] WantedBy=multi-user.target
Note that you’ll need to sudo or su to root privileges when editing the systemd mount file.
Application deployment and execution
While ev3dev comes with all of Linux’s usual trappings, it provides no prefab robot-controlling programs. You’ll have to write these yourself (after all it’s ev3dev) and make it available on the EV3 filesystem. The application file will also need to have its execute bit set before it can be run. Depending on a multitude of factors, the bit may or may not be set automatically when the file arrives on the ev3dev file system. If it’s not set, add it manually by running e.g.
chmod a+x MyRobot.py
Running from Brickman
If you drop the application file under the /home/robot directory, it will be accessible from Brickman’s File Browser. Use the arrow buttons to find the executable, which will be marked with an asterisk * if its execute bit is properly set. The program can then be run by pressing the central (“confirm”) button on the EV3 brick. You’ll return to the Brickman UI after the program terminates.
Data written to stdout will be displayed on the brick’s LCD, but you’ll need better eyes (or settings) than mine to read it! Output written to stderr will be saved to a file named <your-executable>.err.log. The contents of this file are overwritten for every run.
Running from a shell
Executables can also be invoked from a shell: simply SSH into your brick and type the executable’s (path and) name to run it. Since this is no different from running anything on any (other) Linux environment, the application will behave accordingly. For example, stdout and stderr output will be written to your console by default, but you can use piping and redirection to make it go elsewhere.
Since Brickman will be unaware that you launched an application, it will keep running and trying to display itself in the LCD. If your application also uses the LCD, Brickman will engage it in a resource war and (periodically) overwrite your program’s UI by its own. While there are probably more elegant ways to resolve this, I found the following script convenient:
#!/usr/bin/env bash
pid=$(pidof brickman)
if [[ "$EUID" -ne 0 ]]; then
sudo=sudo
fi
function brickman {
[[ ! -z "$pid" ]] && $sudo kill -$1 $pid
}
brickman STOP
"$@"
result=$?
brickman CONT
exit $result
Save the script on the brick (e.g. in a file named suspend-brickman-during.sh) and mark it executable. You can then prevent Brickman from using the LCD (or doing anything else) by launching your program as ./suspend-brickman-during.sh /path/to/program args . If you do so from a non-root account, the sudo invocation will prompt for your password.