KBot Robot Control Program

Inspiration

If the only tool you have is a hammer, you will start treating all your problems like a nail. In my case, i had begun working on Android apps. When a saw a robot built by a friend of mine, Bob Smith, owner of Demand Peripherals, i knew i had to create an app to control it.

Hardware

Turns out the first thing i had to do was build a robot of my own, KBot. I built it from a design provided by Bob which used Demand Peripheral peripheral and interface cards to control the robot components. One of Demand Peripheral's competitive advantages is that it provides a Field Programmable Gate Array board, FPGA, to tie all of the logic parts together. Felt great to use my EE background to put it all together in a very compact form factor.

The brain for the robot is provided by a Raspberry Pi 3 sitting on top.

System Software

We have installed a Raspian Linux OS distibution on the SD card that initializes KBot to use Raspian Linux. We have also initialized the OS image to automatically configure wifi to set up a hot spot and enable it. Since KBot has no other connectivity, we can also make a reservation for a known ip address on behalf of KBot.

Most importantly, we have installed DPServer software that is the driver to control the Demand Peripherals components. DPServer software is provided as source code which allows you to compile it for the specific set of Demand Peripheral components you have designed your robot to use. It also establishes the valid vocabulary that the driver will recognize. This is because DPServer also includes a BASH wrapper that allows you to log in to your device and issue ASCII commands directly from the command line. Normal programmatic control is provided by setting the driver to use a known socket and port number which can be accessed by any TCP library. (Note: Dpdaemon which is the working heart of DPServer is written in C and uses standard C libraries so it can easily be ported to an RTOS, iOS, or Windows.)

Operation

The first step in operating the Android RoboController application is to use System Preferences to log on the the robot's wifi hot spot. Then start up the application. As soon as it is launched, it begins to handle the events generated by tilting your Android device by caching the accelerometer readings to a small buffer.

the main UI is the start button. When it is pressed, we establish a new TCP connection with the robot at the default ip address, port, and socket numbers. (The interface allows you to update these addresses if changes are necessary.) At the same time the app begins to send DPServer command packets at regular intervals. The command packets are mainly settings for the motor controls that are set to a value determined by a running average of the buffer values. In response, the robot accelerates smoothly in the direction the Android device is tilted. Zones of values have been established to make it easy to get to a position that reliably stops the robot.

Future

Google made an "improvement" to the open TCP call where it now checks that there is access to the full internet when the port and socket are opened. Unfortunately the entirety of our internet is the robot and the app from the Android device. Neither of these provide access to the rest of the internet, so our app now fails on the open TCP call. In order to fix this, we will have to take part in some good, honest, hacking.