Can we simplify time-based transitions? about ya_fsm

[mrisher]

P.S. Here's the line where I get compiler errors (https://github.com/mrisher/alien_escape/blob/refactor-pulsarFSM/src/matrixPulsarFsm.cpp#L13)

/home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp: In lambda function:
matrixPulsarFsm.cpp:13:63: error: 'this' was not captured for this lambda function
                                 { return YA_FSM::CurrentState()->timeout; });
                                                               ^
matrixPulsarFsm.cpp:13:63: error: cannot call member function 'FSM_State* YA_FSM::CurrentState()' without object
/home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp: In member function 'void MatrixPulsarFSM::Setup()':
/home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp:13:76: warning: invalid user-defined conversion from 'MatrixPulsarFSM::Setup()::<lambda()>' to 'condition_cb {aka bool (*)()}' [-fpermissive]
                                 { return YA_FSM::CurrentState()->timeout; });
                                                                            ^
/home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp:12:43: note: candidate is: MatrixPulsarFSM::Setup()::<lambda()>::operator void (*)()() const <near match>
   AddTransition(PULSAR_ON, PULSAR_OFF, []()
                                           ^
/home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp:12:43: note:   no known conversion from 'void (*)()' to 'condition_cb {aka bool (*)()}'
In file included from /home/mrisher/src/alien_escape/src/matrixPulsarFsm.h:4:0,
                 from /home/mrisher/src/alien_escape/src/matrixPulsarFsm.cpp:1:
/home/mrisher/src/libraries/YA_FSM/src/YA_FSM.h:73:11: note:   initializing argument 3 of 'uint8_t YA_FSM::AddTransition(uint8_t, uint8_t, condition_cb)'
  uint8_t  AddTransition(uint8_t inputState, uint8_t outputState, condition_cb condition);
           ^~~~~~~~~~~~~

[mrisher]

Created a pull request: #5 #5

[cotestatnt]

Hi @mrisher
I'm sorry for late reply, I was on vacation last week.

I am glad you are satisfied with this library, I have developed it mainly for my benefit and for this reason it is unfortunately not very well documented.

Regarding your request, it actually makes sense that if I define a maximum timeout time for the state, this then automatically go to the next one (according to the defined transitions) without the need to add a callback function or a dedicated variable.

However, I am not entirely convinced of the way in which you have implemented the functionality because I don't think there was a need to add dedicated property and method to the YA_FSM class.

Take a look at how I implemented the functionality. It's only in testing for now, but I think I'll officially add it to the repository soon

[mrisher]

Thank you for your response! I agree, I wasn't super happy adding an additional variable, but I wasn't sure whether we can treat the MAXTIME as the highest priority. If so, then I could simply check whether the time has expired before looking at `Condition` and avoid adding the additional member variable. Do you like that implementation?

…

On Mon, Jul 25, 2022, 7:40 AM Tolentino Cotesta ***@***.***> wrote: Hi @mrisher <https://github.com/mrisher> I'm sorry for late reply, I was on vacation last week. I am glad you are satisfied with this library, I have developed it mainly for my benefit and for this reason it is unfortunately not very well documented. Regarding your request, it actually makes sense that if I define a maximum timeout time for the state, this then automatically go to the next one (according to the defined transitions) without the need to add a callback function or a dedicated variable. However, I am not entirely convinced of the way in which you have implemented the functionality because I do not think there was a need to add dedicated property and method to the YA_FSM class. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABVHNXA357S5SMAPV22OT3VV2RMXANCNFSM54GDZLMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[cotestatnt]

I could simply check whether the time has expired

That's more or less what I did in the wokwi example I linked you to.

If a trigger variable or callback function is not defined, the transition will be triggered on timeout, but this condition is the "weakest" because it is evaluated first.

By default, now both the callback pointer and the variable pointer are == nullptr so, when they are assigned, the local _trigger bool variable will be overwritten regardless of the timeout state.

     bool _trigger = false;

     // If a max time was defined check if current state is on timeout      
     if (_currentState->maxTime) {        
       _currentState->timeout = millis() - _currentState->enterTime > _currentState->maxTime;              
       // Trigger transition on timeout
       if (_currentState->timeout)    
         _trigger = true;        
     }  
   
     // Trigger transition on callback function result if defined
     if (actualtr->Condition != nullptr)
       _trigger = actualtr->Condition();    

     // Trigger transition on bool variable value == true
     if (actualtr->ConditionVar != nullptr) 
       _trigger =  *(actualtr->ConditionVar);   

[cotestatnt]

Thinking about it, maybe it would be the case that instead the timeout is a priority by putting the relative if statement as last position...
I'm not sure about it: after all, if I decide that a state must last for a maximum of XXX milliseconds, what is the point of binding the transition to an external condition if it arrives late? What's your opinion?

[mrisher]

> state must last for a maximum of XXX milliseconds, what is the point of

binding the transition to an external condition Agreed, that's how I was interpreting "Maximum" as well, so then the sequence you have here makes sense to me (but if timeout sets `_trigger=true` then we'd skip the condition checks). In pseudocode because I'm on email if (maxTime is set && timeout has occurred) then trigger; else if (Condition callback returns true) then trigger; else if (ConditionVar is true) then trigger; /* else don't trigger */ I hadn't noticed the Wokwi link you shared, thank you for pointing it out.

…

Message ID: ***@***.***>

[cotestatnt]

I've updated the library as you suggest (if, else if). I'm going to close this issue if you agree.
I've modified also the examples.

[mrisher]

Awesome, thanks! Really appreciate your work here.

…

On Wed, Aug 10, 2022, 6:55 AM Tolentino Cotesta ***@***.***> wrote: Closed #4 <#4> as completed. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABVHNULDE6QSRR3KIYHNR3VYOYELANCNFSM54GDZLMA> . You are receiving this because you were mentioned.Message ID: ***@***.***>