feature/31 implement start conditions for PosTable entry (step 2)

[yeu-degroot]

This implements step 2 of #31.

In step 1, the start condition mechanism always scheduled a standstill (and transition in the waiting state), even if conditions were already satisfied. For many use cases, that is ugly as conditions are often satisfied in time but the robot motion will still have a short standstill.

This step 2 adds the functionality to prevent such short standstills. It will continuously monitor the conditions of the entry which would be next in line to send.

If those conditions change to positive (not ok -> ok), the QA will be recalculated, causing the next motion to be sent. A later change back to negative (ok -> not ok) has no effect.

For an entry with start conditions, if the corresponding condition changes back to negative (ok -> not ok) while the LoadIndex is greater than the entry index, it does not result in a stop. Already queued motions cannot be removed by PosTable.

Code changes

Update McePosTable function

• Recalculate QA if conditions change to positive
• Recalculate QA if conditions change to negative and changed conditions are not used in entries between index and loadIndex (included)
• Recalculate QA when leaving state 5 (wait for conditions)

Update McePosTableRecalcQA and McePosTableRemainingEntries

• Add a conditions input
• Consider an entry as a waitEntry if this entry has conditions that are not satisfied. To do so, replace stConditionResult.bHasConditions by NOT stConditionResult.bConditionsOk

Update McePosTableUpdateIndex function

• Add a conditions input
• Do not update QA if waitBeforeNextEntry is True

Update McePosTableUpdateLoadIndex function

• Add a conditions input