PoC – App Inventor 2 to Control our RPi Robot

Controlling MrBit will require a user device and we’ve taken a look at using my Android phone for this. We have a bluetooth connection set up on the pi in anticipation for needing to control our robot and we need a user interface (UI) on the phone. Here’s how we made our proof of concept Android app using MIT’s App Inventor 2.

Android App Client

In App Inventor 2 we created a simple menu for connecting and disconnecting to the phone. Once connected the UI changes to display basic controls: forward, backward, right, left, stop and a slider for speed. We did this using a single screen app that change hidden contents when connected or not (there’s no way we’ve found to persist a bluetooth connection/client between multiple screens).

screenshot of app inventor screen builder

Firstly we created the screens with the relevant buttons and text/labels for messages.

The logic behind the UI on the application is developed using blocks similar to Scratch. We’ve got a label in the UI that we update to display messages, blocks then use a global varible to set the relevant message. When the screen loads the program checks to see if bluetooth is available, if it is then a list is generated of the paired bluetooth devices the phone knows about and we can select our robot from the list.

functional blocks in App inventor

Global var to set messages and function to update the display

These blocks check for Bluetooth when the screen initialises and lists available devices to select from

On selecting a device to connect to the application then tries to connect to the device, if it is successful it updates the screen to show the hidden controller buttons and sliders – otherwise it will display an error message.

Bluetooth client blocks connects to the chosen device from the list

Any time there’s an error the message is displayed – this block configures how.

Each button and the slider are bound to a block of code to send data to the Pi. We repeated the same button click block 5 times, one for each button and each having different command (the prototype isn’t optimised in anyway otherwise we would have created a procedure for this). The slider sends PWM values to change the speed of the motors.

Example block for button control, others include Backwards (B), Right (R), Left (L) and Stop (S)

The slider sends values 0-255 to set the speed (PWM) of motors

The final block simply disconnects the bluetooth connection when the “disconnect” button is clicked.

Once finished, the disconnect button will end the bluetooth client connection

Pi Bluetooth Server

To receive commands our bluetooth client on the app needed to connect to a bluetooth server on the Pi and send data over an SDP (service discovery protocol) serial connection. We did this via Python and a configured serial rfcomm port.

Firstly, make sure there’s a bluetooth serial channel set up on the Pi:

We can check the channel is set up using the following command:
(note output snippet will be amongst others)

If you get an error such as: Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory This can be fixed by altering the configuration of the bluetooth (bluez) service, this is a known issue (also now known to us!) at time of writing in bluez5. To resolve this we need to edit the config for the service:

and add the –compat flag in the file to make the service backward compatible on the line

Then save and restart the service with the new config setting:

We also need to change permissions on the following $ chmod 777 /var/run/sdp

Our Python script is simple, it receives a command, checks it for validity and sends it to our motor driver script to control the robot’s movement.

We based this code on other MIT code examples for Bluetooth rfomm serial using python, if you’re doing this then there may be other examples there to help.

Proof of Concept Outcome

I hope to post a video of us using this but of course my phone is also my camera!

We aren’t sure we want to create a UI for controlling Mr. Bit especially for some of the challenges such as the obstacle course and Pi noon, it’s not as responsive as we’d like and our prototype limited in how it controls the robot – we may have to invest quite a bit of time to get the right UI. We would like joysticks but the only option is to create these through drawing onto a canvas and then manipulating through touch – it doesn’t sound straight forward. We might try to use sliders to control speed across left and right motors but the slider orientation can only be horizontal and we’d prefer that type of control to be vertical.

We do like the implementation though and the ease of using App Inventor, we’ve certainly learnt a lot from this prototype! We will think about using an app as a menu to put Mr. Bit into different modes and/or to send telemetry data to the phone from Mr Bit whilst in use. Next we all look at using a PS3 dualshock and compare.

Leave a Reply

Your email address will not be published. Required fields are marked *