Create high level command set

[theAgingApprentice]

Create simple high level commands for moving the robot: Move forward - move a minimal distance forward (i.e. 1 inch) Move backward - move a minimal distance backward (i.e. 1 inch) Crab left - move a minimal distance left without turning (i.e. 1 inch) Crab right - move a minimal distance right without turning (i.e. 1 inch)

[nerdoug]

current goal is to store some persistent groups of flow commands, which we'll call a sequence. The MQTT flow commands that make up the sequence are sent via MQTT to the robot, and stored for future execution. In the simple case, this execution happens at the end of the sequence definition. We're making the sequence persistent, and allowing it to be executed in another higher level sequence later.

when the robot processes the commands in a sequence, it builds a series of arrays in memory. Each command's information occupies the same index in each array, and they are used sequentially.

We now want to keep the rows associated with a particular sequence around, rather than always restarting from row 1, and associate a name with this group of rows so we can request that it be executed from another sequence.

To support this we need to track the names (single letter for now) of each persistent sequence, and the table indices where it starts and ends. We also need to modify the DO_FLOW command to have an indication that a sequence is to be persistent, and what its name is. For persistence sequences, the start and end indices associated with the name are stored.

For now, this persistence will not survive power cycles, but in the future we can investigate using NVM, external SD cards, or compile time sequence inclusion.

Scribbly notes:

• check for running out of array space
• sequence execution must be queued, but maybe it already is
• collision detection becomes important
• initial set of commands means robot is always facing the same direction. To get more generality, we could add a "turn 45 degrees (right, left)" command
• need an abort sequence capability, maybe including capacitance sensor checked in frame processing
• have initially expanded sequence data storage from 200 to 500 rows
• need to allow using a named sequence within a named sequence

Work list:

• do_flow MQTT command stays as is, with the sequence being overwritten
• do_flow routine in flows.cpp (which should be renamed, say run_flow) needs to check for end of macro on every line, and handle:
  • tracking iteration count, and rerouting execution to start of macro
  • popping of previous context and iteration count when macro's done
• new command save_flow preserves the sequence that has been defined -- specifies a one letter name for the sequence -- saves a pointer in an array indexed by name, to the first row. similarly, the last row is stored. similarly, the sequence name is remembered. -- updates the NEXT_SEQ pointer that shows where the next sequence's data should start
• initialization -- NEXT_SEQ = 0 so first sequence starts at beginning of arrays -- clear sequence control tables
• new command DO_SEQ to execute a named sequence: DO_SEQ -- similar to CYCLE command processing
• abort processing -- maybe an MQTT command ABORT -- panic button on robot -- check to happen quickly - at frame level at least
• FLUSH_SEQ to clear out accumulated persistent sequences & data structures?
• handle a new mnemonic for doMacro sequence operand

[nerdoug]

Pondering what toe positions start and end each of the macro movements(MM). One simple approach is to require that each MM start and end in the neutral stance where all servos are centred. We'll implement this approach initially. Another approach is to have start and end positions that are convenient for the MM, and facilitate it being repeated, which will often be the case. To support having an arbitrary start position, the code for each MM will have to analyse the current position of the toes (as recorded by software, since we can't sense it) and generate appropriate leg movements to get to the planned starting point of the MM. It might be better to go to a position part way through the MM if the legs are already there, or close to there. Hmm - that gets complicated quickly. For now, all MM's start and end at the neutral stance.

For standard naming, I'll use the names as the commands within a sequence (NOT MQTT commands, well, we need both. see below) that execute the macros: MMF - macro movement forward MMB - backward MMR - right MML - Left

These commands will need parameters such as:

• step height - NOPE - it's built into the flow command in the macro definition & unchangeable.
• elapsed time per MM (equivalent to speed) - NOPE - again, built into the macro definition & unchangeable
• repeat count - this one we can do

[nerdoug]

created SAVE_MACRO MQTT command, working on DO_MACRO command. Oops, DO_MACRO isn't an MQTT command, it's a script command, like FLOW. Actually we need both. see below.

It would be nice to have variations on macros, like go forward vs. go forward at twice normal speed. Right now, the timing control is embedded in the FLOW commands in the macro sequence, and can't be altered by a macro.

There's a bunch of implied compiler work needed as well

[nerdoug]

Addressed this need by implementing macros - the ability to define named macros, or high level commands, consisting of an arbitrary number of regular FLOW commands. This can be forward, backward, left and right or any other functions that can be implemented as a group of flow commands. These are defined in a script, and can be called later in that script, or in subsequent downloaded MQTT scripts, up until a reset. (To be extended later.)

Four new operations are available for the FLOW command to support macros:

BOM - Beginning of Macros. Indicates the portion of the MQTT script, usualy right at the beginning, where macro definitions start. This is necessary so the robot does not execute the commands that are part of the definition while the macro is being defined.

EOM - End Of Macros. Indicates that macro definitions have ended, and normal FLOW command execution should resume

SM - Save Macro. Tells robot to save the accumulated FLOW commands as a macro with the given name. These are the commands that have been given since the robot started, or since that last macro SM command, whichever happened latest.

DM - Do Macro. Tells robot to execute the commands that were previously saveed as the named macro.

A MQTT script using macros has a form like this:

1) NEW_FLOW 2) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 3) flow,1,bom 4) Flow,0,SM,h 5) Flow, 1000,MLRH,10,0,0,0, 5.9,10,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 6) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 7) Flow,0,SM,a 8) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 5.9,10,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 9) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 10) Flow,0,SM,b 11) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 0,0,0, 5.9,10,0, 0,0,0, 0,0,0, 0,0,0 12) Flow, 1000,MLRH,10,0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0, 0,0,0 13) Flow,0,SM,c 14) flow,1,eom 15) flow,1,dm,a 16) flow,1,dm,b 17) flow,1,dm,c 18) flow,1,dm,b 19) flow,1,dm,a 20) DO_FLOW,1,25

...where the lines in the script have these functions:

1) normal start of script flag. This will not cause previously defined macros to be overwritten 2) a"go to home position" command to get us to a known starting point 3) a command to flag the beginning of macro definitions. This is needed so the robot knows that it shouldn't actually execute the commands that are part of macro definitions while the definition is taking place. 4) a dummy macro definition, so we have a clean start on the next one. probably unnecessary 5) a regular command that is part of a macro definition - raises leg 1 6) a regular command that is part of a macro definition- lowers leg 1 7) Save Macro command. Tells robot to save the accumulated commands into the named macro - A 8) a regular command that is part of a macro definition - raises leg 2 9) a regular command that is part of a macro definition- lowers leg 2 10) Save Macro command. Tells robot to save the accumulated commands (since last SM) into the named macro - B 11) a regular command that is part of a macro definition - raises leg 3 12) a regular command that is part of a macro definition- lowers leg 3 13) Save Macro command. Tells robot to save the accumulated commands (since last SM) into the named macro - C 14) End Of Macros - robot resumes executing commands as it encounters them 15) a call to execute Macro A, which raises and lowers leg 1 16) a call to execute Macro B, which raises and lowers leg 2 17) a call to execute Macro C, which raises and lowers leg 3 18) a call to execute Macro B, which raises and lowers leg 2 19) a call to execute Macro A, which raises and lowers leg 1 20) normal DO_FLOW command which ends script definition, and starts its execution

The script above can be found in ..../performance/mqttScripts/01__hb-macro-demo.js

I'll define other issues for:

• defining real time commands to executed macros that are already defined. This would be similar to how the Quick Go Home (QGH) command runs immediately, not requiring a script to trigger its execution
• creating & using persistent macros, which are stored in NVRAM, a micro-SD card, or compiled cource code