Xbox Wireless Controller connected to the PINE64 running Ubuntu Linux using bluetooth

Although the goal of the autonomous robot project is to have a robot that can navigate without human input, it’s not a bad idea to be able to manually override and control the robot one way or another which could come in useful in cases where it gets stuck due to being trapped in between large physical obstacles, or perhaps a bug in the code. My PINE64 order came with the stock WiFi / Bluetooth 4.0 module which is still available from the PINE store, and I also got the Xbox Wireless Controller with bluetooth support ($39.99). Any bluetooth controller should be able to get the job done, but I particularly like the look of the Xbox Wireless controller. However, it was a little difficult getting the controller to actually pair due to certain quirks with the controller implementation. I finally got it to work after spending almost an entire day on the issue and accidentally wiping my primary Ubuntu install with dd (which shouldn’t have happened, but I suppose someone shouldn’t do dangerous things when they’re tired).

In this post, I will cover how to setup the PINE64’s stock Bluetooth module, how I got the XBox Wireless controller to successfully connect via bluetooth, and run some input tests using the evtest tool. I am currently running the longsleep xenial image with kernel version 3.10.105. In a future post, we’ll write C# code to handle system-wide input events for Ghost Mainframe (which is what I’ll be calling the autonomous robot project going forward until I can think of a better name).

How to setup the stock Bluetooth module on the PINE A64+

The first thing we need to do is install the firmware which will enable the bluetooth module to work properly and load the necessary drivers. This is fairly straightforward and can be done using these steps.

After make install completes, copy rtk_hciattach to your preferred bin path, either /usr/bin or /usr/local/bin.

You will also need to install the bluetooth service and the bluez stack by running sudo apt install bluetooth bluez. Once this is complete, you can test to make sure it works using the following comamnds:

Run sudo rfkill list and you should get output similar to what’s shown below.

If Soft blocked under Bluetooth is yes, unblock it using sudo rfkill unblock 3. This only needs to be done once. You can run the list command again to make sure that it actually got unblocked.

You can bring up the Bluetooth interface using sudo hciconfig hci0 up. Note that the hciconfig command is not available in BlueZ 5.47. Since the BlueZ version available from the xenial repository is 5.37, this is not a problem. If you don’t have hciconfig in your path, you will need to turn on the bluetooth module using bluetoothctl. Simply run power on in the bluetoothctl prompt.

Finally, you can add the following lines to /etc/rc.local if you wish to automatically power on the PINE Bluetooth module on every boot.

bluetoothctl

bluetoothctl is a command line tool that you can use to power on/off the bluetooth module, scan, discover and connect to nearby bluetooth devices. Simply run sudo bluetoothctl to get the to the bluetooth control prompt. If you are at the prompt and it’s not accepting your keyboard input, that could indicate that the bluetooth service is not running. Exit (using Ctrl+C if input is not being accepted) and then run sudo service start bluetooth.

Pairing the XBox Wireless Controller with the PINE64

This is where things got hairy. You can skip to the solution if you don’t want to read about how I arrived there.

The Story
I had been following the xpad kernel driver project for a while which is how I had initially found out that there was a new version of the Xbox controller that could be connected using bluetooth. Following the instructions in this issue and this comment didn’t seem to work. Instead, I ended up with an AuthenticationCancelled error.

My initial foray into finding solutions for the problem led me to build BlueZ 5.47 from source and install, but that didn’t change anything. There were also some posts about having to update the controller’s firmware which can only be done with a Windows 10 (Why, Microsoft?!) store app called Xbox Accessories. I created a VirtualBox VM running Windows 10 Fall Creator’s edition but the app did not recognise the controller when connected over USB. This led me into a deep hole where I was trying to obtain various older Windows drivers in order to get the controller to work. None of them worked so I eventually decided to just boot Windows on my notebook, as opposed to within the VM since I guessed that the VirtualBox USB implementation was probably causing detection problems (spoiler: I was right).

I tried to boot Windows from a preinstalled SSD, which resulted in a blue screen, then I tried to burn the VM’s VHD file to a different drive connected over USB, which somehow ended up destroying all the partitions on my internal SSD (I am very sure I used /dev/sdb as the of parameter for dd, not /dev/sda, but I don’t even care anymore). Finally, I created a Windows bootable flash drive and attempted to install on the external SSD only to discover that Windows cannot be installed to a drive connected over USB or Firewire. RAGE! Since my internal SSD was wiped anyway, I finally got Windows installed with the Xbox Accessories app up and running only to discover that the controller already had the latest firmware installed. That was pointless!

I almost gave up until I decided to re-read the btmon logs which led to me noticing the error, Result: Failure - unknown options (0x0003). This finally led me in the right direction as I found this mailing list thread which points to a couple of patches I had to apply to the kernel source. After rebuilding the kernel from source and modules, the bluetoothctl connect command works, although the pair command still fails. The connect command however forces the controller to pair, and that’s what’s important.

The Solution
Apply the changes in this commit (you may need to change the USB device ID – obtained using lsusb – to match your controller; mine is 0x02ea) to the kernel source and then rebuild and deploy the kernel, headers and modules following these instructions. You can also make use of the helper scripts in that repository. Following redeployment, you can reboot the board so that the new kernel and modules are loaded. You can also add the disable_ertm line to your /etc/rc.local so that it is done at boot time. Your /etc/rc.local file should have lines like so (including changes applied above):

Finally, you should get output like what’s showing using bluetoothctl (input commands are preceded with the bluetooth prompt). You will notice that although the pair command still fails with Failed to pair: org.bluez.Error.AuthenticationCanceled, the connect command actually works.

evtest: Testing the Xbox Wireless Controller input

You can exit from bluetoothctl after the connection has been successfully established. Install evtest using sudo apt install evtest and then run it using sudo evtest. With the output like so, enter the number corresponding to your controller.

I got the following output after I entered 5:

Here’s the output when I press a few buttons and move the analog sticks.

Conclusion

While it wasn’t a pleasant experience, I’m glad I was able to get the XBox Wireless Controller to actually work with the PINE64. In my followup post, I will write out (or probably create a diagram) of the controller button mappings through evtest and then write C# code to handle the input directly from the /dev/input/event* file and generate input events accordingly.

Building MonoDevelop for the PINE64

MonoDevelop running on the PINE64 using SSH X11 forwarding

4 Dec 2017 Update
These instructions will not work with the latest versions of Mono and MonoDevelop from github. I tried compiling from scratch on a new image, and they will work with the following versions listed below. You can checkout the specific tags immediately after cloning the corresponding repositories before you start building.
Mono 4.8.1.0 – git checkout tags/mono-4.8.1.0
MonoDevelop 6.1.0.5441 – git checkout tags/monodevelop-6.1.0.5441

My PINE64 is here and the first thing I decided to do was build MonoDevelop which I’ll use to manage C# projects, since most of the code I’ll be writing for my autonomous project will be in C#. I’m using the longsleep Ubuntu Xenial image as a base, so these instructions assume that this is what you have installed. You can adapt as required based on your distro.

Of course, the easiest way to get MonoDevelop installed is by using the package manager. The version is also fairly recent (4.2.1.102), so you can choose skip the rest of this post if you prefer. Simply run the apt-get install command and all required dependencies will also be automatically installed.

Most of the steps will be similar to the MonoDevelop for Raspberry Pi build post, but we’ll be skipping fsharp altogether. I cloned the fsharp repository but the make process failed due to the following error:

F# is only required for the fsharpbindings extension and I don’t plan on using that. There appears to be an fsharp package which you can install using apt, but this will also install the mono 4.2.1 dependencies. If you’re fine with using an older version of mono and would still like to build MonoDevelop, then you can also skip the steps up till Build MonoDevelop.

So let’s get started!

Install all prerequisites
Git is required to clone the source repositories for Mono, MonoDevelop and dependencies. The other packages are required for building MonoDevelop dependencies from source.

 

Pre-build: NuGet certificates
The MonoDevelop build process makes use of NuGet at certain points. You will need to import certificates into your certificate store using the following commands.

 

Build Mono
This step is fairly straightforward. Clone the mono source repository and run the build process.

This build will take a while. If you wish to run the mono and mcs test suites, you can do a make check before make install.
 

Build MonoDevelop dependencies
MonoDevelop requires gtk-sharp and gnome-sharp to be installed on the system. To build gtk-sharp.

gnome-sharp follows a similar process.

Some reference PCL Assemblies are required for the build to complete. You will need to build a deb package and install following the instructions below.

Remove mono-xbuild from the list of dependencies in the control file, save and close. Then proceed with the following commands.

 

Build MonoDevelop
First, we clone the monodevelop repository and initialise the submodules using git.

Next, we remove references to fsharp. The assumed working directory for these steps is the top-level monodevelop source directory.

Remove the external/fsharpbinding/MonoDevelop.FSharpBinding/FSharpBinding.addin.xml \ line, save the file and close.

Comment out or remove the following lines in the file and save your changes. To comment out the lines, simply prefix each line with the # character.

Then we can go on to build the IDE.

You can run mono main/.nuget/NuGet.exe update -self if you get the following error after running make.

Once the build is successfully completed, you can run the application using monodevelop. If you have X11 forwarding enabled for your SSH session, you should see the MonoDevelop IDE on your screen after a couple of seconds.

MonoDevelop running on the PINE64 using SSH X11 forwarding

MonoDevelop running on the PINE64 using SSH X11 forwarding

The PINE64 is finally here

1GB PINE64 with the WiFi module and RTC battery module installed. It's huge!

I received my PINE64 yesterday and I was pretty excited after such a long wait. The following items were in the package:

  • PINE64 1GB board
  • Camera module
  • RTC battery module (which is actually bigger than I expected)
  • WiFi/Bluetooth module

They were all in good shape, and the board was not bent nor warped which I was afraid would happen after reading a few horror stories. The Pine64 is most definitely a huge board (compared to the Raspberry Pi), and the build quality also seems solid. I was able to burn the longsleep Ubuntu Xenial image to a 32GB microSD card, and since I wanted to run the board as a headless device, I mounted the microSD on my Linux box and updated the /etc/network/interfaces file to connect to my wireless network. The connection to the network was established a few seconds after providing power to the board and I was able to SSH into the device after the boot process was successfully completed.

I’ll update this post with a few pictures once I get a decent camera.

Update

1GB PINE64 with the WiFi module and RTC battery module installed. It's huge!

1GB PINE64 with the WiFi module and RTC battery module installed. It’s huge!

PINE64 side-by-side with a Raspberry Pi 3 and the Keyestudio Mega clone

PINE64 side-by-side with a Raspberry Pi 3 and the Keyestudio Mega clone