Coding styles within FB eco system

[mvillion]

I am curious about how people have approached making FB ‘dance’.

My background is cyber security, electronics, system design and a bit of coding. Out of interest, I watch aircraft disaster documentaries as I enjoy the reverse engineering that takes place so the investigators understand exactly what happened and why, thus preventing a repeat. Think has given me a view that all code should be coded ‘safely’ thus leaving nothing to chance when entering code segments of checking parameters for validity etc.

I think because of my background, my coding style is extremely modular.

In the FB ecosystem, I use 3 levels of sequence

1 - Launchers - (LAUNCHER)
These are the user-facing sequences (for me). These are sequences generally of long duration set things up for level 2 sequences to run.

Example
‘Water All plants - Launcher’
This changes the tools in the head and get the FB ready for the main watering process.

2 - Sequences (SEQ)
These are the main heavy coding takes place. The ‘Dismount the tool safely’ is a sequence I have written that lives at a level 2. This checks with an IF statement, if a tool needs to be offloaded, dismounts the head, then verifies that the sequence was successful. If not it parks FB in the naughty corner of the bed and report an error so I know something went wrong. My rule is not to run level 2 sequences directly when in ‘user mode’

3 - Sub sequences (This is the low-level interfacing) (SUB)
I never directly code things like waits or peripheral controls in my code. I place them in sub-sequences with plain English descriptions, so I never have to think about how to do it again. So ‘Turn water on for 3 seconds’ is a sub-sequence. The Dismount tool head’ (which is the code from the sequence import) lives here and is called from the ‘Dismount tool head safely’ (which is at level 2). ‘Wait 5 seconds’ is also a sub sequence.

4 - LED control (LED)
Used only to control the LED 3 and 4 on the control panels to provide user feedback, such as sequence starts and stops, waits etc

For feedback, I also have a ‘sequence start’ [Level 2] (turns LED 3 on for 1 second) ‘Sequence end’ (flashes LED 3 twice for 250 ms) and ‘Sub sequence start’ [Level 3] (turn LED 4 on for 1 second) and ‘subsequence end’ (flashed LED 4 twice for 250 ms). All ‘waits’ turn LED 3 and 4 on for the duration.
It looks pretty complex and over-engineered, but it is great for debugging as I can watch what the FB is ‘thinking’ [executing] (entering and exiting sequences and sub-sequences) from the FB itself. I can also tell when the machine is ‘waiting’.

Has anyone else taken a modular approach or do you just code in one big sequence?

[jturbett]

2&3) I multiple sequences work for my, I use Python from a sidecar but one can do this in LUA with the custom pins assertion from out put of each Lua code in the sequence and the next one checking if the key is what one is looking for ( one sequence checks for rain today and puts a value in that key, next does an if if value is “xxx” then continue to next sequence. This was a pain in the but before and triggered the need for a side car as LUA character limit to ensure smooth running of the Farmbot eco system. now we can string together scripts with checking the out put of the previous one.
4) Just get another LED string(s) and control it with the extra unised peripheral pins, I have used the servo before but that was a bit combersome mechanically but it did work as a poor mans relay