Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tutorial #271

Closed
gitcandies opened this issue Jan 20, 2021 · 9 comments
Closed

tutorial #271

gitcandies opened this issue Jan 20, 2021 · 9 comments

Comments

@gitcandies
Copy link

gitcandies commented Jan 20, 2021

This Looks like an interesting package!!
I can see that you can set up states (say MONITOR, FIRE, FLOOD, PUMPING, NOTIFY)
I also see you can name transitions (say: see_smoke=monitor.to(fire)
However, the package traffic light example only shows transitions being manually activated (typed in), not reacting to various inputs (triggers?)

Programmatically, how/where do you do this checking of inputs or conditions (such as change state when time=12:45?) What triggers this transition? Say a GPIO pin was going high to show smoke detected, where is that placed in the code? (if smoke detected, in monitor state, transition to fire state)
Are the transitions automatically checked & actions taken for the particular current state? Can actions be added when entering or leaving states? Say I had the typical vending machine example & had some switches to read coins, hit the dispense button, etc...are there any more examples?

@brunolnetto
Copy link

It might be a misconception. The definition you are biased to is probably from eletronics. The most recurrent state machine on eletronics are those created by Mealy and Moore. These requires input, memory and output. The ideas given here are rather permissive than reactive. The developer mindset was not focused on developing an automatic connected net, although it might be implemented with such.

@fgmacedo fgmacedo changed the title tuorial tutorial Mar 12, 2021
@gitcandies
Copy link
Author

So can you easily add some condition to change state? For example states: start, fill, wash, drain
when temperature>50Celsius go from start to fill, when level sensor=True, set time=0 & go from FILL to WASH , when time>10 minutes go from WASH to DRAIN. If during WASH, level sensor=False go back to FILL....can you use this package with some modification to create such a FSM? Perhaps by adding a condition class?

@taliesin
Copy link

I seem to be equally biased, could you please elaborate a bit on

The ideas given here are rather permissive than reactive.

The syntactic sugar supplied by the package is tempting, but even looking at the tests in the package I can't see how to use it in a real-world application. Is anyone using this in a relatively simple context.

Any pointers would be greatly appreciated.

@slowrunner
Copy link

I too am struggling with figuring out how to use the python-statemachine package to implement a load conscious, event driven FSM architecture.

I have figured out to put transition tests in "on_entry_stateA()" and transition actions in "on_transitionA2B()" and a "cycle transition" which is a null event (transition to itself) for every state. This design allows yielding the processor when no event is present, and testing for events when given the processor, BUT the processing is not limited when events are actually present - the states "run away" - continuing to transition until a state cannot transition.

Fragments from my current design: drive.py which simulates an FSM to drive a robot until an obstacle appears.

    # transitions perform actions:
    def on_w2d(self):     # waiting to drive transition
        logging.info("transition accepted drive_request: {}".format(drive_request))
        motor_speed = drive_request

    def on_d2o(self):    # drive to obstacle transition
        logging.info("transition stopping")
        motor_speed = 0

    # loop will use "cycle = every state to itself" 
    cycle = startup.to.itself() | waiting.to.itself() | driving.to.itself() | obstacle.to.itself() | exit.to.itself()

    # event detectors in on_entering_<state> 
    def on_enter_waiting(self):
        logging.info("checking events - ef:{} dist:{} req:{}".format(exit_flag, distance_reading, drive_request))
        if exit_flag:
            self.quit()
        elif distance_reading <= OBSTACLE:    # should not drive?
            self.w2o()
        elif drive_request > 0:    # drive wanted?
            self.w2d()

...  

main():
    while True:
        drive_behavior.cycle()
        sleep(1/states_per_second)

If there are no events to be processed, the loop executes only the null transition and the event check of the current state.
BUT, if there are events the cycle will proceed from state to state until a state with no events is hit.

# only one state executed when no events trigger a transition
2022-05-29 14:10:09,886 main: cycle: 4
2022-05-29 14:10:09,887 on_cycle: null transition
2022-05-29 14:10:09,888 on_enter_waiting: checking events - ef:False dist:3000 req:0

# if events do trigger a transition then multiple states are executed, possibly unlimited
2022-05-29 14:10:10,889 main: cycle: 5
2022-05-29 14:10:10,890 on_cycle: null transition
2022-05-29 14:10:10,891 on_enter_waiting: checking events - ef:False dist:3000 req:10
2022-05-29 14:10:10,891 on_w2d: transition accepted drive_request: 10
2022-05-29 14:10:10,892 on_enter_driving: checking events - ef:False dist:3000 req:10

(In one try, I had two states transition to each other until the stack overflowed.)

@brunolnetto
Copy link

brunolnetto commented May 31, 2022

I may be completely wrong, but It will serve to hold back expectations until the specialist @fgmacedo Is here to clear architecture design out. From my perspective, this library inspires itself in the concept of a static state-machine, which means it is driven by intended interface transition trigger actions. My understanding about your interpretation regards a dynamic interaction between output entries and inner states, which classifies as a finite automata (nomination is sensitive at this point, I got myself confusing it while discussing with this library's author). You might reach this complexity type with this library, but it will require some creativity at transitions activation.

@brunolnetto
Copy link

@slowrunner It has been a while since you gave a thumbs-up on this issue. Have you accomplished any progress on your demands, with or without these library features?

@slowrunner
Copy link

@slowrunner It has been a while since you gave a thumbs-up on this issue. Have you accomplished any progress on your demands, with or without these library features?

I was able to determine the strengths of the package and what adaptations would be needed to form the basis for autonomous mobile robot control, but my focus moved to ROS2 and intend to learn behavior trees as a control structure. Many folks are suggesting behavior trees are more expressive for the complex resource constrained decisions needed in mobile robots.

@brunolnetto
Copy link

I am glad you solved your curiosity issues. ROS is popular. I am not familiar with ROS2. Decision-making is environment dependent on robotics. However, it is off-topic here.

@fgmacedo
Copy link
Owner

fgmacedo commented Jan 2, 2023

Took a while, but for now, some of your questions are better documented:

Please let me know if you have any other issues.

@fgmacedo fgmacedo closed this as completed Jan 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants