Reading the Sparki Sensors For the Arcbotics Sparki Robot, Using MIT App Inventor2

Sensor Reading App • This app is for showing how communication between an Arduino board with sensors and an App Inventor app can be done via Bluetooth. • A Sparki robot is used, because I have it at hand. The communication works similar to an Arduino board with temperature, humidity, or accelerometer sensors. • The robot has 6 sensors: 2 edge sensors, 3 line sensors and a distance sensor. Of course it can also move, but that is not shown in this app.

Screen Design

Blocks for Connecting and Disconnecting

As soon as the Arduino board is connected, the clock will be enabled and the app will start sending ‘r’ requests to the Sparki.

Blocks for Connecting and Disconnecting • The messages are sent in a simplified XML format. • In this way it is possible to precisely delimit complete messages and find the readings for individual sensors. • An example of a message received: r

23

983 992 990 990 982

A screenshot with debug message displayed

The Message Format • As explained, it is necessary to have a strict and structured format for the messages, in order for the app to know when it has received the whole message and to be able to interpret its content. • We could choose to have fixed format or fixed length messages, maybe delimited by brackets or parentheses: [ ] or { } or (). Maybe easy to program a sketch for, but this would make the messages not very flexible or extensible and it would put a burden on the app to interpret them correctly. • As an alternative message format, JSON or XML are possibilities, for which App Inventor has built in evaluation routines. • We choose XML as our format because JSON messages are not so clearly delimited, because there can be nested brackets to keep count of, while XML should always have a single root tag. • To be able to use the XML-parsing routine, drag a Web component from the Connectivity category in the Palette column on the designer screen.

The Clock, How it Functions • A timer is used to control the reading of the sensors. These are sensors for reading distance, line and edge. • The app sends a request for data at regular intervals and the Sparki sends the values upon receipt of this request. • In order not to choke the Sparki with requests or to loose data because not all could be read by the app during the time interval, a protocol is established: • When a timer event occurs, the app reads the available data and determines if a complete message is received. • If yes, display the values received and send a new request to Sparki. • If no, collect the data in a buffer and wait for the next timer event.

• The timer interval is adjustable in the designer, and set to 500 milliseconds currently.

The sketch for the sensors • We show a snippet of the sketch that sends the sensor readings. //Sensor readings: case 'r': serial.println(""); serial.print("

"); serial.print(sparki.ping()); serial.println("

"); serial.print(""); serial.print(sparki.edgeLeft()); serial.println(""); ….. ….. serial.print(""); serial.print(sparki.edgeRight()); serial.println(""); serial.println(""); break;

serial.print(""); serial.print(sparki.lineLeft()); serial.println(""); serial.print(""); serial.print(sparki.lineCenter()); serial.println(""); serial.print(""); serial.print(sparki.lineRight()); serial.println("");

Using the Timer • The event that causes the app to read or send data is the Timer event:

• We leave the complication of receiving data to a procedure with the name receiveText. • Before showing the procedure, we define a global variable that we will use to keep received text, initialized to an empty string, and a global that indicates whether the app is sending or receiving.

Reading data - 1 • The procedure receiveText looks as follows:

• First the available bytes are received and appended to text that may be received earlier. • If there is an end tag present within the received string, we must have a complete message. • In this case we call the procedure readBTSensors to display the values, the global containing the received text buffer is reset, and receiving is set to false.

Reading data - 2 • Below is the procedure readBTSensors. As you can see, we need more global variables and more procedures are called. We will describe each in turn.

Reading data - 3 • The additional globals we need are:

• The startIndex is used to keep the index where can be found. This is not necessarily position 1, because the Sparki could send other things in addition to sensor readings. • The endIndex marks the end of the message, the position of . The end of the total string is at this value + 4, the length of . • The global xmlText receives the complete message including and

Reading data - 4 • The extract global receives the result of calling XMLDecode of the Web component we included earlier.

• This result is a list of key-value pairs as found in the XML. • We use the nifty little procedure getVal to find the values for the various tags:

• For more explanation about how to use XML in App Inventor, look here: http://ai2.appinventor.mit.edu/reference/other/xml.html

Reading data - 5 • We decode our extracted list of key-value pairs, starting with the tag:

• As result we have a list that represents all sensor readings as key-value pairs which we can now extract and show in a label:

The complete set of blocks