More details on scripting commands

A project log for S.O.A.R. (Scriptable Online Androidino Robot)

This is a small two wheel drive robot which is based on the Arduino and Android platforms and is Scriptable via googlescript (javascript)

eric-livesayEric Livesay 07/29/2014 at 04:310 Comments

Scripting with s.o.a.r.:

Controlling the robot is done via basic commands that can be strung together and interwoven with sensory input and the appropriate response command. As well, this can be combined with code that lives in the cloud via javascript to offload processing or just to allow remote control. One command can encapsulate several commands. Here are the basic commands I am thinking of to start with:

1 go forward

2 go backward

3 turn left

4 turn right

5 say a word

6 listen for a response

7 take a picture

Some of these commands would be done on the android phone and some would be done with the robot and it's microcontroller.

With allowing responses to be part of offline script, the robot can be programmed to respond to things autonomously.

For example:

Command: "spin in circle"

Turn right

Turn right

Turn right

Turn right

Command: "introduce"

Go forward

Say "hello"

Response audio: "hello" - say "friendly" say "huh?"

"Spin in circle"

End response

Response audio: null- say "not" say "friendly"

Turn right

Turn right

Go forward

go forward

End response

These types of things can be ant to be stored on the robot. They can also be stored in a google spreadsheet or other server based storage to be retrieved by others for sharing purposes. In this way a library of behaviors could be created.

The android phone will need a command interpreter. Commands are received from the google script/ spreadsheet (at first this would probably be via polling the google spreadsheet). This architecture could be changed to interact in a more direct manner in the future but using a googlespreadsheet and googlescript that is polled by the android phone is easy and will allow for it to be easily shared.

The command interpreter:

The commands should come in as "immediate" or "program". This allows the command interpreter to not have to look and update any commands it can just overwrite if it has one of the same name. Possibly a linked list would be a good structure to start with when programming the interpretation of the commands because it allows for chaining the commands together. Some pseudo code for the android command interpreter is:

For programming commands:

    //sample command previously received:
string command="program,spin in circle,turn right, turn right, turn right";
//load our existing linked list of commands:
ObjectInputStream oi =newObjectInputStream(newFileInputStream("save.ser"));Object listIn = oi.readObject();
//create linked list from serialized linked list
LinkedList ll = (Linked List) listIn;// add new elements to the linked list

ArrayList<String> commandList=Arrays.asList(command.split(","));

//to do: convert array list into linked list and search through existing list.// If command is the same overwrite existing list otherwise add commands to the list

//the trick is some commands may be existing linked lists and if so we will need to overwrite then
//serialize linked list again:		
ObjectOutputStream oo =newObjectOutputStream(newFileOutputStream("save.ser"));
                oo.close();//this is all pseudo code and not complete or working 
// will spawn many questions I'm sure and I haven't written the actual interpreter that sends commands to arduino or to android routines just idea of serializing and deserializing a linked list with commands badicakky