So continuing on from the last post about the Zumo robot and controlling it from a phone I started looking into the other functions that the MIT app inventor package provided.
One of the sensors that the app interfaces with on the phone (depending on the model) turns out to be the accelerometer. Three numbers are returned, the pitch and roll of the device along with the compass direction in degrees as a number so I figured if it was possible to capture these numbers in a usable format then they could then be passed over Bluetooth to the robot to be used as a method of control.
The pitch and roll data turned out to be the most useful, when lying flat they return a floating point number that increases and decreases to -90 and +90 as the phone is pitched up and down and rolled left and right. This then needed to be converted to a signed integer before having any applicable leading zeros added. A string identifying the X and Y data as well as the direction of pitch and roll is then combined with these two numbers to make up a 10 digit string that is passed over Bluetooth every 150ms to the Pololu Zumo.
On the Zumo side of things the start of the string is identified by the character “Y”. The 9 successive characters are then read into an array for processing. 4 IF statements then set a couple of variables to represent the direction of travel in the Y direction (Forward and Reverse now) and the X direction (Left and Right).
As the data is stored in an array as Chars the 6 positions holding the roll and pitch values are then multiplied by the appropriate factor (after having 48 subtracted from them to compensate for the fact that the decimal value for the ASCII character 0 for example is 38) to break back out an integer.
Values between 0 and 50 degrees of pitch and roll are considered to be valid, anything over 50 degrees is ignored and the variable is set to 50 instead. A deadzone of 10 degrees in the middle is then added. After that the values between 0 and 50 are mapped to values between 0 and 400 to be more compatible with the values that the Zumo Motors library works with.
From there the Y direction of travel determines whether the motors drive backwards or forwards by the Y speed value mapped above whilst the X direction of travel determines which motor should slow or accelerate depending on the X speed value. If one of the X or Y motor speeds exceeds 400 or -400 (the max and min supported by the motor driver chip) then the that motor is set to that limit and the other motor is slowed in the opposite direction to create the desired turning force.
Kind of convoluted but it seems to work at the moment 😛
The code is up on Github, https://github.com/JCT250/Zumo_remote I’d love comments on the way things are structured, how to do it better etc, especially the section that deals with the scaling and calculation of the motor speeds based upon the values and direction information coming in from the phone. If you’d like a copy of the APK file to try on an android phone leave a comment below.
Next time… is the I3 finished?