For ‘teleoperation’ purposes, a ‘Bluetooth’-based ‘Wii Remote’ can be used. ‘Bluetooth’, a wireless communication can be achieved between the ‘Wii Remote’ and computer and finally to the micro controller. The computer here acts as an intermediary interfacing medium. Then the ‘GlovePIE’ (Glove Programmable Input Emulator) software on the computer. ‘GlovePIE’ provides scripts that allow the ‘Wii Remote’ to control certain Microsoft Windows games and applications. A driver should be installed (windows application), that allows the Wii Remote’ to act as a mouse.
Microsoft Visual Studio 8 can be used to write and compile C++ codes for interfacing. A separate class functions is defined to be used in ‘Matlab7’. Finally, another separate code is to be written to prepare for useful functions in ‘Matlab7’. 8bit data from the 3-axis accelerometers of the ‘Wii Remote’ is read to ‘Matlab’ (integers of -127 to +128). Interfacing the two C++ based programs to work hand in hand was achieved.
The strength of the wireless ‘Wii Remote’ compared to wired communication, ‘Wii Nunchuck’ is its 1 to 100 meters range. Wireless communications proved to be very useful for aeronautics applications. Unlike a wired communication, its range limited to its wiring length. The greater range which makes it more susceptible to attacks is one of its disadvantages. Fast I2C (Inter-Integrated Circuit) communication requires wired communication as a norm. Although there are wireless ‘I2C’ applications, an ‘I2C’ adapter is needed and can increase cost.
For power supply, a 7.5V ‘AC-to-DC’ wall adapter is not advisable. Power supply of this manner often produces ripple voltage (although being smoothed by capacitor), contrary to a pure DC voltage (constant 5V that gives straight line if measured across time). Most adapters also do not provide sufficient current, 1 to 6A that is needed for a robotic arm with 4 to 6 motors.
There are two control approaches for ‘teleoperation’ control. The inverse and forward kinematics control. For inverse kinematics, operator controls the ‘end-effector’ in a given 3D work space. This is an intuitive process, and does not depend on the robotic arm mechanical structure. Therefore, inverse kinematics solutions were calculated. The ‘end-effector’ position is calculated and produces corresponding joint angles. In forward kinematics, individual joint angles are controlled. This gave a more accurate positioning despite having to plan the ‘end-effector’ position at the end.