I've done a few more tests and found a couple more details that are worth reporting.

Stopping the execution of a sequence before its completion: 

When using the "coding mode", which I described in my last two updates, the Android app sends a sequence of movement commands delimited by two special commands ("1100" start-of-sequence, "1101" end-of-sequence). Once the robot receives the "1101" end-of-sequence command, it starts executing the movements in the sequence one by one without requiring any further command from the Android app. It will run through the whole sequence unless two things happen: 

1- a "1000" (STOP) command is sent by the Android app 

or

2- the BLE connection between the phone and the robot is terminated.

Procedures are simple loop sections and their full definition is sent every time they are called:

The Android app allows the user to define sequences of up to 8 movement commands called "procedures" that can be executed multiple repeated times. In my last update I explained that the Android app instructs the robot to run a procedure multiple times by delimiting its sequence of movements using two special commands (start-of-an-XX-times-loop message "0700 00XX" and end-of-loop "0701"). I was wondering if separate "procedures" in the Android app would be defined using different special commands and the definition of these procedures would be reused if the same procedure was called again within the sequence.  This would enable us to save a lot of space if we had to alternate different loops. Unfortunately, I found out that each time a procedure is used, their full definition is sent using the same special delimiters. I also found out that the Android app is clever enough to not send the special delimiters if the procedure is executed only once.

Procedures can't be nested

I was wondering if it would be possible to include a "procedure" within another "procedure" to create nested loops. Unfortunately, I tried it and found out that the robot would discard any previous start-of-loop commands and any redundant end-of-loop commands.

The robot can handle loops of more than 8 operations.

The Android app limits the number of commands in a procedure to be less than 8. Arguably there are many simple shapes that can be drawn using loops with less than 8 commands; however, now that we know that we can't use procedures as functions and call them from within other procedures and we can't nest loops, it would be useful to be able to define longer loops. The good news is that the robot can handle loops of quite many commands. I tried using one with 34 commands and saw no issues. This enabled me to draw a "reverse 3rd order" Koch snowflake (made up name) by repeating the sequence of drawing one of its smaller sides 6 times:

The robot can handle sequences of more than 34 commands (at least >46)

I noticed that when executing drawings from the "free-hand drawing mode" that involved many steps, the robot would pause at times and the Android app would show a "sending data" window for a couple of seconds. I check the communications log and found out that the Android app split the sequence in chunks of 34 commands and executed it as separate sequences running one after the other. Something like this:

1100

command 1

command 2

...

command 34

1101

1100

command 35

command 36

...

command 68

1101

I checked if the robot would be able to handle sequences of more commands and tried a sequence of 46 commands without problem. I haven't ran any further tests to find out what the actual limit is but in any case it seems to be greater than the limit the Android app imposes to itself.

There's a small catch though:

Timing

I'm not sure yet if the Android app has any way to tell if the robot has completed executing a sequence. This would be important if we had to start sending a new sequence when multiple sequences were chained to created a longer equivalent sequence as described above. It is also important if the BLE connection has to be kept alive while the sequence is being executed. In my scripts in Python I had to include a time time delay before closing the BLE connection to give the robot enough time to complete the drawing. I will check the communication logs in greater detail to see if the robot sends any signal to the Android app to acknowledge that it has finished executing a sequence. If it doesn't, there's a chance that the Android app simply estimates the approximate time that it takes to complete a sequence by adding up the approximate time of each movement command in the sequence. Still, I guess this would be quite imprecise given how long it takes for a sequence containing loops to be completed.

Finding "secret" commands not used by the Android app

In my previous update I explained that I started guessing the commands the Android app used to make the robot play different audio samples. This was the only time where I've sent commands to the robot that I haven't seen in the communication logs. Given the way the commands are encoded using plain text, it would be fairly easy to guess other commands that may exist even if the Android app doesn't use them. I don't feel adventurous enough to give that a try because somehow I'm afraid I'll trigger some calibration routine that will break the robot but I may start playing with this idea at some point.

Once again, stay tuned for more updates!