Реалізація VR-контролерів через Bluetooth у мобільному додатку
Mobile VR з Bluetooth-контролерами — це Cardboard/Daydream-ера або сучасні рішення типу Pico G3 з 3DoF-трекінгом. В обох випадках задача одна: отримувати дані IMU (акселерометр, гіроскоп, магнітометр) та кнопки з контролера по BLE з мінімальною латентністю, переводити в позицію/орієнтацію в 3D-просторі та передавати в рендеринг двигуна. Ми беремо такі проекти під ключ: від реверс-інжинірингу GATT до інтеграції в Unity або Godot.
Як зменшити затримку BLE-контролера?
Стандартний connection interval BLE — 45 мс, що для VR критично: затримка відчувається та викликає дискомфорт. Рішення — переключити контролер на високу швидкість через requestConnectionPriority(CONNECTION_PRIORITY_HIGH), скорочуючи інтервал до 7,5 мс. Додатково використовуємо notify-характеристики замість read, виключаючи поллінг. На практиці при правильному налаштуванні різниця між 45 мс та 7.5 мс стає непомітною для користувача. Крім того, рекомендується вимкнути сканування інших BLE-пристроїв під час сесії, щоб не завантажувати радіочастотний канал.
GATT-профіль BLE-контролера
Більшість VR-контролерів реалізують стандартний HID over GATT профіль або кастомний GATT-сервіс для IMU-даних. Для кастомних — потрібна документація виробника з UUID характеристик. Типова структура GATT для VR-контролера:
-
Service UUID
00001812-0000-1000-8000-00805f9b34fb(HID Service) або кастомний - Report Characteristic — вхідні дані: кнопки + IMU (notify)
-
Battery Service
0000180f-0000-1000-8000-00805f9b34fb— рівень заряду (read/notify)
Параметри BLE для VR
| Параметр | Значення | Вплив на VR |
|---|---|---|
| Connection interval | 7,5 мс (HIGH) | Мінімальна затримка |
| Connection interval | 45 мс (DEFAULT) | Помітна затримка, дискомфорт |
| Notify | Увімкнено | Зниження навантаження на CPU |
| Read | Не рекомендується | Збільшує latency |
class VRControllerGattClient(private val context: Context) {
private var bluetoothGatt: BluetoothGatt? = null
private val CONTROLLER_SERVICE_UUID = UUID.fromString("YOUR-CONTROLLER-UUID")
private val IMU_CHARACTERISTIC_UUID = UUID.fromString("YOUR-IMU-CHAR-UUID")
fun connect(device: BluetoothDevice) {
// TRANSPORT_LE — явно вказуємо BLE, не класичний BT
bluetoothGatt = device.connectGatt(context, false, gattCallback, BluetoothDevice.TRANSPORT_LE)
}
private val gattCallback = object : BluetoothGattCallback() {
override fun onConnectionStateChange(gatt: BluetoothGatt, status: Int, newState: Int) {
if (newState == BluetoothProfile.STATE_CONNECTED) {
gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH)
gatt.discoverServices()
}
}
override fun onServicesDiscovered(gatt: BluetoothGatt, status: Int) {
val service = gatt.getService(CONTROLLER_SERVICE_UUID) ?: return
val imuChar = service.getCharacteristic(IMU_CHARACTERISTIC_UUID) ?: return
gatt.setCharacteristicNotification(imuChar, true)
// Вмикаємо Client Characteristic Configuration Descriptor
val descriptor = imuChar.getDescriptor(
UUID.fromString("00002902-0000-1000-8000-00805f9b34fb")
)
descriptor.value = BluetoothGattDescriptor.ENABLE_NOTIFICATION_VALUE
gatt.writeDescriptor(descriptor)
}
override fun onCharacteristicChanged(
gatt: BluetoothGatt,
characteristic: BluetoothGattCharacteristic,
value: ByteArray
) {
parseControllerData(value)
}
}
}
requestConnectionPriority(CONNECTION_PRIORITY_HIGH) — переводить BLE connection interval з default 45ms на 7.5ms. Критично для VR: при 45ms затримка вводу відчувається як дискомфорт, при 7.5ms — непомітна.
Чому важливий sensor fusion?
Сирі дані з MEMS-гіроскопа дрейфують, акселерометр шумить. Без комбінування орієнтація йде за кілька секунд. Ми використовуємо Madgwick або Mahony AHRS-алгоритми, які дають стабільний кватерніон. Madgwick при β=0.1f відфільтровує шум, але при швидких рухах (β=0.3f) точність у 2 рази вища за complementary filter. Значення β — компроміс між швидкістю реакції та фільтрацією шуму; для динамічних сцен обирають 0.3, для статичних — 0.01.
Парсинг IMU-даних та sensor fusion
Дані з MEMS-гіроскопа та акселерометра — сирі покази в одиницях виробника. Потрібна калібровка та sensor fusion для отримання стабільної кватерніонної орієнтації.
data class ControllerState(
val gyroX: Float, val gyroY: Float, val gyroZ: Float, // рад/с
val accelX: Float, val accelY: Float, val accelZ: Float, // м/с²
val buttons: Int, // бітмаска кнопок
val trigger: Float, // аналоговий тригер 0..1
val timestamp: Long
)
fun parseControllerData(raw: ByteArray): ControllerState {
val buffer = ByteBuffer.wrap(raw).order(ByteOrder.LITTLE_ENDIAN)
return ControllerState(
gyroX = buffer.short.toFloat() / 32768f * GYRO_SCALE, // GYRO_SCALE в рад/с
gyroY = buffer.short.toFloat() / 32768f * GYRO_SCALE,
gyroZ = buffer.short.toFloat() / 32768f * GYRO_SCALE,
accelX = buffer.short.toFloat() / 32768f * ACCEL_SCALE,
accelY = buffer.short.toFloat() / 32768f * ACCEL_SCALE,
accelZ = buffer.short.toFloat() / 32768f * ACCEL_SCALE,
buttons = buffer.short.toInt(),
trigger = (buffer.byte.toInt() and 0xFF) / 255f,
timestamp = SystemClock.elapsedRealtimeNanos()
)
}
Для орієнтації — complementary filter (швидко) або Madgwick/Mahony AHRS (точніше):
| Алгоритм | Точність орієнтації | Продуктивність | Рекомендація |
|---|---|---|---|
| Complementary filter | Середня | Висока (50 мкс) | Для статичних сцен |
| Madgwick AHRS | Висока (2x краще) | Середня (200 мкс) | Для динаміки |
| Mahony AHRS | Висока | Середня (180 мкс) | Альтернатива |
class MadgwickFilter(private val beta: Float = 0.1f) {
private var q = floatArrayOf(1f, 0f, 0f, 0f) // кватерніон орієнтації
fun update(gx: Float, gy: Float, gz: Float,
ax: Float, ay: Float, az: Float, dt: Float) {
// Madgwick AHRS algorithm
// Нормалізуємо акселерометр
val norm = sqrt(ax * ax + ay * ay + az * az)
if (norm == 0f) return
// ... повна реалізація алгоритму
// Результат: q[0..3] — кватерніон поточної орієнтації
}
fun getQuaternion() = Quaternion(q[0], q[1], q[2], q[3])
}
beta = 0.1f — компроміс між швидкістю реакції та фільтрацією шуму. При швидких рухах збільшувати до 0.3, при статиці — зменшувати до 0.01. Після обробки алгоритмом важливо виконати калібрування гіроскопа для компенсації зміщення нуля.
Інтеграція з VR-рендерингом
На Android — передача даних контролера в Unity через AndroidJavaClass або напряму в OpenXR через XR_EXT_hand_tracking-сумісний плагін. Для Godot — GodotAndroidPlugin з exposed методами. Типова помилка: передавати дані контролера прямо з BLE callback-треду в рендер-тред. Потрібен thread-safe буфер:
// Atomic reference для останнього стану контролера
private val latestState = AtomicReference<ControllerState?>()
override fun onCharacteristicChanged(..., value: ByteArray) {
latestState.set(parseControllerData(value))
}
// З рендер-треду (кожен кадр)
fun pollControllerState(): ControllerState? = latestState.getAndSet(null)
Як ми налаштовуємо BLE для VR: покроково
- Отримуємо GATT-документацію від виробника або реверсимо протокол.
- Підключаємо контролер з пріоритетом HIGH та вмикаємо нотифікації.
- Парсимо IMU-дані та застосовуємо sensor fusion (Madgwick або Mahony).
- Калібруємо сенсори та перевіряємо латентність на реальному пристрої.
- Інтегруємо в двигун: Unity, Godot або Unreal.
Що входить у роботу
- Документація GATT-профілю (UUID та формат даних)
- Код підключення та парсингу під Android/iOS
- Sensor fusion з налаштуванням під контролер
- Інтеграція в Unity/Godot/Unreal
- Калібрування сенсорів та тестування латентності
- Підтримка після деплою 1 місяць
Наша команда має досвід у mobile VR та реалізувала проекти з BLE-контролерами. Гарантуємо низьку латентність та точний трекінг. Оцінимо ваш проект безкоштовно — зв'яжіться з нами для консультації.
Строки
BLE-підключення до існуючого VR-контролера з готовою GATT-документацією, парсинг IMU, інтеграція в Unity/Godot: 3–5 днів. Розробка з реверс-інжинірингом GATT-протоколу невідомого контролера + кастомний sensor fusion: 1–2 тижні. Замовте роботи — отримайте рішення під ключ.