I wrote a quick test program to play with R.O.B. It was my first ever NES program, and it was horrible. However, it let me experiment with sending him every possible command pattern.
From this experiment I learned that the timing seems to be very difficult to get right. I tried polling the PPUSTATUS for the v-blank bit toggling, and I also tried using the V-Blank NMI, but each way I did it, R.O.B. would only respond some times to the commands.
Gyromite flashes the screen by changing all the palette colors to the same (either black or green).
I found the following list of commands, and I'm pretty sure it's every command he will accept. They are written as 8 bit hex values, if you expand them to 8 bit binary, the most significant bit gets flashed first (0 for black, 1 for green).
Also note that you always need to flash 00010 (5 flashes) immediately before the 8 flash command.
AB - Calibrate (causes R.O.B. to open arms, go all the way right and all the way up, and then return to center - as when you first turn him on)
AE - Down 1 Notch
BA - Left 1 Notch
BB - Up 2 Notches
BE - Close
EA - Right 1 Notch
EB - Test (this just causes the red LED on his head to turn on if it was previously off)
EE - Open
FA - Up 1 Notch
FB - Down 2 Notches
If you look at these commands, you may realize that only the hex digits A, B, E and F are used. If you break these into their binary equivalents 1010, 1011, 1110 and 1111 respectively, you should see that there is never a sequence that contains two adjacent 0s (black screens) except in the 5 flash start sequence. More specifically only the even numbered bits [if numbered from 0(lsb)..7(msb)] can be a 0, which further enforces the no adjacent 0 "rule." Consequently, every 8 flash command starts with a 1 (green flash). Maybe this observation could lead to more efficient code, or a better understanding of R.O.B.s capabilities/limitations for more compatible code.