BLE HID Mouse with cursor absolute positioning

Hello community, here’s a copy and paste of my message in Expressif ESP32 forum:

I'm new to ESP32 and, more specific, to microcontroller programming. I'm attempting to convert my Arduino Nano ESP32 board into a BLE HID pointing and clicking device (similar to a light-gun).

I've been tirelessly searching for a library that, once connected as a BLE HID device, allows me to move the mouse cursor to absolute coordinates (as opposed to relative coordinates).

The closest approach I've found is this repository by Sobrinho: GitHub - sobrinho/ESP32-BLE-Abs-Mouse: Bluetooth LE Mouse library for the ESP32 (Arduino IDE compatible). Unfortunately, it doesn't work on Windows.

I'm aware that USB absolute mouse positioning will be included in the ESP-IDF v5.1 libraries once they are released. You can see more information here: https://github.com/espressif/arduino-es ... 3ae69d2262

I'm looking for something similar for BLE HID devices.

Thank you in advance.

Hi @xan. The technique I have used is to start by moving the mouse pointer enough in each direction that it is certain that is is now located at one of the corners of the display regardless of the arbitrary starting position of the pointer. You now have a reference point (e.g., 0,0) from which to base all the relative movements that come after.

This is a very primitive technique, but it did work perfectly for my specific application. Obviously a more sophisticated technique where the system is able to communicate specific pointer coordinates directly to the computer is far better, but I did not find such a capability readily available at the time I was working on my project (which was a decade ago and different in nature from yours).

The tricky thing I encountered is that, at least with my system which was using the "Mouse" library on a Windows machine, the mouse pointer position did not reflect the coordinates that were expected from the values passed to Mouse.move for larger values. I believe this is due to the operating system's "mouse acceleration" feature. The workaround I found was to only move small distances at a time (calling Mouse.move multiple times in order to achieve movements of larger distances).

This library provides the "homing", incremental movement, and absolute position tracking code:

If what I wrote above is not clear to you, take a look at the library source code. I think it will be more clear after that.

The library uses the "Mouse" library, so probably won't work out of the box for your use case, but the code is not at all complex so it would probably be easy to adapt it for use with whatever BLE mouse library you are working with.

Hi @ptillisch and thank you for taking the time to read and respond to me.

Initially, I considered positioning the pointer at 0,0 for each cursor movement. However, I quickly dismissed this idea because for a device like the lightgun I want to build, low latency is a highly desirable feature. Moving the pointer to 0,0 on each movement would increase latency and affect the responsive feel of the device. Another potential issue could be the saturation of the BLE channel due to the doubling of the number of reports sent.

Thank you for your example. I will definitely take a closer look at it.

I was afraid of that.

It is possible to "home" the pointer only once, then simply keep track of the pointer position from there on. The only problem with this approach is that if some reason the actual position doesn't match the expected position at some point, then all positions from then on will be thrown off. This is why I chose to "home" the pointer between each movement.

The conditions under which I experienced the pointer position being thrown off was when a human moved the physical mouse while the Arduino was running the program. With the "home before each movement" approach, even though doing that would throw off the current movement, at least the subsequent movements would be accurate.

But if you are in a situation where it is unlikely that there would be any external interference with the mouse positioning, then the repeated pointer "homing" would not be so necessary.