The last post covered how the video signal is transmitted. However, a communication channel back to the robot is also necessary. Over this channel the signals for the gimbal and the robot are sent. The smartest solution would have been to transmit the USB of the Oculus Rift and the gamepad directly to the onboard computer. In fact, there are a few Wireless USB systems out there, but all have high latency. That’s why I decided to do the processing of these inputs on a stationary computer and only send the control commands to a microcontroller on the robot. But what wireless technology has low latency and a reasonable range?
Bluetooth
A bit of internet research shows that the latency of WiFi and Zigbee is too high. I asked an electrical engineer at my university and he recommended using Bluetooth modules by the company
u-blox. These are optimized for short latency and as well as a long range. I took his advice and bought two
connectBlue OBS421I-26-0 and one
connectBlue ACC-34. The ACC-34 is just a serial-to-USB adapter to connect the Bluetooth module with the stationary PC.
Maestro Mini
To drive the servos of the gimbal and robot motors, I used the fantastic
Pololu Mini Maestro 12-Channel board. It has many setting options, simple serial protocol and is able to output the servo (PWM) signal with up to 333Hz.
Code
The application on the stationary computer is written in C++. With DirectX’s XInput interface it reads the analog stick of the gamepad and converts it to command controls for the robot.
[crayon-5da3b62d810dc302211812/]
The Oculus Rift SDK is used to get the head orientation. It returns a quaternion, which easily can be converted to Euler angles. After some correction and tuning these are used to control the gimbal.
You will find the whole code on
GitHub. The control system's code is in the project IREController.
Goodie: Commander Control
Because we also wanted to use the system with a broad audience, I needed a handy control to pause the system before someone damages it. Because I didn’t want be bound to a keyboard, I used a standard wireless presenter. The presenter just sends normal key commands, which I only had to map to the functions.
The
next article will be the last one. It contains my conclusion of the Open Day and the project.
If you have any suggestions or questions, please use the comment form. I am always happy to learn something new.
The last post covered how the video signal is transmitted. However, a communication channel back to the robot is also necessary. Over this channel the signals for the gimbal and the robot are sent. The smartest solution would have been to transmit the USB of the Oculus Rift and the gamepad directly to the onboard computer. In fact, there are a few Wireless USB systems out there, but all have high latency. That’s why I decided to do the processing of these inputs on a stationary computer and only send the control commands to a microcontroller on the robot. But what wireless technology has low latency and a reasonable range?
Because we also wanted to use the system with a broad audience, I needed a handy control to pause the system before someone damages it. Because I didn’t want be bound to a keyboard, I used a standard wireless presenter. The presenter just sends normal key commands, which I only had to map to the functions.
The next article will be the last one. It contains my conclusion of the Open Day and the project.
If you have any suggestions or questions, please use the comment form. I am always happy to learn something new.