Tethered Haptics Using Morse Pulses

This project page will no longer be updated, and any future updates will take place on the main TrillSat site at http://greatfractal.com/TrillSat.html.  I created this page specifically for the Human-Computer Interface Challenge, but this marks the 4th loss for my #TrillSat project in a row, without any recognition whatsoever, except for a single like from a user named AKA.  Thank you @AKA for being the brave lone voice that recognized this project.

TRILLSAT-1, signing off.

I just published new updates to the source code over at the #TrillSat project which show how the tethered haptic system was implemented.  About two weeks ago, I had published the SimtheoDecoder module, which performs the Morse decoding (and does most of the work), but now I've released the remaining code (and a small update to the decoder) to show exactly how THUMP was implemented on the prototype itself, the working cablebot known as TRILLSAT-1, to control the motor, perform the EEPROM haptic code validation, and process actual commands.

Ok, I just posted 4 new videos of the TRILLSAT-1 prototype over at my #TrillSat project page, and one of them demonstrates this tethered haptic Morse code system in operation (shown below).  In the demonstration, I set the haptic passcode lock, unlocked it, and then sent a command to turn on the wireless Qi charger via the two-way haptic system.  I also show the effect of acceleration due to gravity when the craft tilts for its solar tracking function.  I hope these videos give you a better feel for the project.

I thought I had the five most important variables taken into account for practical tethered haptic detection on my oblique cablebot, but the force of gravity itself, not just the weight of the craft, added a sixth.  I didn't notice this when testing my craft horizontally or even at a slight X-axis tilt, but when I was testing the motor yesterday, at extreme tilts to the side, the threshold for X-axis detection seemed to increase, making recognition more difficult, even if I struck the tether along that same tilted axis.

This shouldn't be an issue for typical, vertical hoistbots that remain level, as you're always going to have the same constant level of acceleration due to gravity which can be subtracted by the accelerometer, but my prototype is an oblique cablebot which is designed to tilt throughout the day for accurate solar alignment.

Gravity does two additional things in my case: it presents a changing source of acceleration to the X-axis accelerometer when tilted at different angles (of which I already took advantage for pitch/roll detection for the craft), and it seems to limit the amplitude of the wave pulse along the same axis, reducing the detection sensitivity.

If the craft is plucked along a leveled X-axis, it can oscillate horizontally fairly easily, but if the craft is tilted sharply, like an airplane banking with its ailerons, gravity acts like a spring pushing against one side, and the taut tether acts like a spring pushing back (confining the pulse between a rock and a hard place, so to speak.)  Imagine placing a small wooden board on a lake and pushing it sideways, which only takes slight effort, versus turning the board sideways and trying to push it underwater or lift it out of the water, which takes more force to move the same distance.

So I turned on the LIS3DH high-pass filter using CTRL_REG2 to allow me to cancel out the DC component (gravity) for click detection, which allows the pulse to be more easily seen by the accelerometer.  This helps, but the reference needs to be adjusted, by using the REFERENCE register, for each tilt angle.  I've been experimenting with the Autoreset feature, as well.  So I plan to add more code to my prototype to set the reference a minute or so after each motor tilt operation (to allow the craft to swing to a halt).  And then I may also read the tilt angle and increase or decrease the threshold, CLICK_THS, dynamically, which should counter any remaining effect.

Again, the #TrillSat project prototype is a more complicated use of the THUMP haptic system.  I described some the particular difficulties in it's log entry here.

Because I'm already capturing a sequence of two Morse code characters (the A-Z letter and the F1 or F2 confirmation character) for each haptic command, I decided to tack on a secondary system that checks for invalid confirmation characters to unlock a 2-letter passcode.  As I mentioned previously, a "Q" followed by "F1" within 5 seconds, for example, will send a command to turn on the Qi charger to charge the smartphone.  But with this new system, a "Q" followed by an "A" within 5 seconds, will not activate that command, but could instead match a passcode that was previously set by the user, called "QA".

There are 676 two-capital-letter combinations, which is sufficient for a simple passcode that is easy to set, easy to haptically enter, secure enough to keep a random person from casually entering codes, and makes it more difficult for natural phenomena (wind, rain, hail, etc.) to spontaneously enter commands.  For example, for rain to activate the Qi charger if a "QA" passcode was set, it would have to send a SIMTHEO SHH Morse Q (. . ...), then within 5 seconds, send a SIMTHEO SHH Morse A (..          .), which unlocks the device, then send another SIMTHEO SHH Morse Q (. . ...), then within 5 seconds, send a SIMTHEO SHH Morse F1 or F2 (. . . .) or (. . . ..).

That's not impossible, but it's improbable during the length of time of an intense rainstorm in my area, which would have to trigger the X-axis interrupt.  Wind, rain, hail (or an animal) would have to hit the tether sideways in such a way to trigger the accelerometer at just the right amplitudes and pauses, the Infinite Monkey Theorem.

But it could happen, and if I find that it's a problem, I may later add additional timeout delays, such as a 1-minute delay if an incorrect unlock code is entered (which would also extend any brute force attempt to an average of several hours of tether plucking to find the unlock code).  But the system is hanging on a tether anchored to the ground--it's not physically secure, so this is mainly to keep out nature not human beings.  Or maybe I'll also add a timeout delay to reset the lock after it has been unlocked for a certain period (like the sudo password timeouts in Linux).  I don't want to increase the complexity of the passcode, as that just makes it harder to enter the haptic input.  And I'm also trying to keep my haptic commands rather benign, that if they are activated in error (or if I activate them in error) that their interaction with the craft's operation isn't that big of a deal.

But the way it currently works now is that, on boot, the system is unlocked and haptic commands can be entered normally.  I added a new XMPP command on the #TrillSat project prototype called code [A-Z][A-Z].  If the user sets the code to a two-capital-letter sequence (such as QA, XZ, UV, etc.), it will set the haptic lock and write the code to the EEPROMs on both ATtiny 1634 microcontrollers running in parallel.

Once the user unlocks the code, a global flag is set, and the system remains unlocked until it loses power or resets.  Then on boot, the ATtinys read the EEPROM and put the lock back into effect.  This ensures that at nighttime, if the system loses battery power and goes completely dead, once it boots up after the sun hits the solar panel in the morning, the lock remains in place.

If the user sets the code to an invalid two-captial-letter sequence (such as 5Z, yt, 00, etc.), it simply clears any haptic lock and writes it to the EEPROM so it will remain cleared.

Another one of the benefits of using a haptic Morse code system over, say, a flashlight pulsed onto the photocells at night, is that it is more difficult to perform a passcode replay attack.  Without using OTPs (one-time passwords), at night, a person could pay attention to the flashlight pattern and then shine a light from far away to replay the codes.  But the haptic vibrations are too fast for the naked eye, yet too slow for the ear (at sub-audible frequencies).  So as long as one's hand is not readily visible to distant onlookers, it would be difficult for them to observe the codes.

I've also decided to leave the haptic communication system enabled at all times, even when the Pi and ESP8266 are online, since the user will not be able to send commands to recharge their smartphone if the smartphone experiences complete battery failure and loses the ability to send XMPP commands to lower the craft and turn on the Qi charger.  Because of this, I've decided to turn off replay_mode temporarily to disable any haptic motor feedback until the correct passcode is received (which allows the craft to save power in a rainstorm, for example).  When the correct code is entered, the motor then vibrates back a response and accepts normal haptic commands as long as it has uninterruped power.

Even though THUMP is now installed and working in the #TrillSat project, I need it to actually do something useful, and so I'm adding more commands to my TRILLSAT-1 prototype.  On trillsat_bot.py, I've created a series of XMPP commands that I can issue to the ESP8266 (which is sent to the Pi over the UART).

The Pi then sends I2C commands to the LIS3DH so that I can change its parameters on-the-fly for testing:

cfg [0-255]     Set CLICK_CFG register to set click direction (1 is x, 4 is y, 16 is z, add for combos)
ths [0-255]     Set CLICK_THS register to change threshold (for changing the sensitivity)
limit [0-255]   Set TIME_LIMIT register
latency [0-255] Set TIME_LATENCY register (for changing the pulse width)
window [0-255]  Set TIME_WINDOW register

It also sends some I2C commands to the two ATtinys (Sawyer and Huckleberry) which run THUMP and SIMTHEO:

pulse            Instruct Sawyer to send a short haptic motor pulse for testing
pulsemode [1|0]  Set the morse_echo and morse_replay variables differently on the two ATtinys to enable haptic mode (1) or LED mode (0)
thump [1|0]      Turn the THUMP interrupt on or off

And on trillsat.c, I am now assigning commands to the various letters A-Z.  Hopefully 26 letters (plus an optional binary confirmation which allows 52 combinations) will be enough for me, and I won't need to add a second letter.  I can always add a second letter, which will take more time for the user to enter, to raise the number of combinations to 26^2 = 676 (plus that binary confirmation).  This is why Unix-like systems can get away with using so many two-letter commands--there are over 600 from which to choose.

Here are the haptic commands so far (but are tentative until I see how I like it):

X   Disable all power to the craft, including power to the ATtiny itself (if it is night, the craft will then be completely dead)
L   Turn on the ESP8266 (via its LDO regulator)
B   Turn on the 5v boost converter on Batt 2
Q   Turn on the Qi charger (important if the smartphone is dead and needs to charge to regain XMPP control)

I will add more commands later (and experiment with OFF or toggle commands) and release the updates to the TrillSat source code, showing how THUMP is actually working on the prototype.