Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

execution of smach monitor states interrupted when receiving msgs sent frequently

Hi Everyone,

Recently, I've been trying to build a state machine that consists of monitor states. They all subscribe to the same topic and the transitions will be triggered according to the msg that has been published to that topic. I started with the following code and tried to manipulate it with rqt. The code looks like the following: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/monitor_example.py.

Basically, I tried to define 2 callback function for the monitor states that examine whether the input has been 2 (the Data.msg contains an int32 crutch_request), if so, then the calculation will be executed. After the calculation is finished, it returns false and the state machine will transit to the next monitor state that does pretty much the same thing. Since I am returning the result of the calc function, I expect the monitor state to finish the calc() after it received the correct number, regardless of further messages published to the same topic.

In practice, however, I tried to publish with the rqt with a rate of 1 and the following happened: At the beginning, the machine behaves normally as expected, starting from the first or the second transition, it sometimes randomly jumps back to the previous state without transitioning. Sometimes the calc() will be executed twice, resulting in two repeated lines of the same printed numbers. Both situations are shown in this screenshot: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/ros_answer_monitor.JPG

Obviously, I have some misunderstanding in the concepts of smach monitors. Could someone please explain to me the reason for the strange behavior of the state machine? Many thanks in advance!

execution of smach monitor states interrupted when receiving msgs sent frequently

Hi Everyone,

Recently, I've been trying to build a state machine that consists of monitor states. They all subscribe to the same topic and the transitions will be triggered according to the msg that has been published to that topic. I started with the following code and tried to manipulate it with rqt. The code looks like the following: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/monitor_example.py.

Basically, I tried to define 2 callback function for the monitor states that examine whether the input has been 2 (the Data.msg contains an int32 crutch_request), if so, then the calculation will be executed. After the calculation is finished, it returns false and the state machine will transit to the next monitor state that does pretty much the same thing. Since I am returning the result of the calc function, I expect the monitor state to finish the calc() after it received the correct number, regardless of further messages published to the same topic.

In practice, however, I tried to publish with the rqt with a rate of 1 and the following happened: At the beginning, the machine behaves normally as expected, starting from the first or the second transition, it sometimes randomly jumps back to the previous state without transitioning. Sometimes the calc() will be executed twice, resulting in two repeated lines of the same printed numbers. Both situations are shown in this screenshot: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/ros_answer_monitor.JPG

Obviously, I have some misunderstanding in the concepts of smach monitors. Could someone please explain to me the reason for the strange behavior of the state machine? Many thanks in advance!

Update: The log of my state machine looks like the following:

qi@ubuntu:~$ rosrun varileg_enhanced_state_machine monitor_example.py [] Working in step 0 Working in step 1 Working in step 2 Working in step 3 Working in step 4 Working in step 5 Working in step 0 Working in step 1 Working in step 2 Working in step 3 Working in step 4 Working in step 5 Working in step 0 Working in step 0 Working in step 1 Working in step 1 Working in step 2 Working in step 2 Working in step 3 Working in step 3 Working in step 4 Working in step 4 Working in step 5 Working in step 5 Working in step 0 Working in step 0 Working in step 1 Working in step 0 Working in step 1 Working in step 2 Working in step 1 Working in step 2 Working in step 3 Working in step 2 Working in step 3 Working in step 4 Working in step 3 Working in step 4 Working in step 5 Working in step 4 Working in step 5 Working in step 0 Working in step 0 Working in step 5 Working in step 0 Working in step 1 Working in step 0 Working in step 1 Working in step 1 Working in step 2 Working in step Working in step 0 1 Working in step 2 Working in step 2 Working in step 3 Working in step 1 Working in step 2 Working in step 3 Working in step 3 Working in step 4 Working in step Working in step 2 3 Working in step 4 Working in step 4 Working in step 5 Working in step Working in step 43

Working in step 5 Working in step 5 Working in step 0 Working in step 5 Working in step 4

execution of smach monitor states interrupted when receiving msgs sent frequently

Hi Everyone,

Recently, I've been trying to build a state machine that consists of monitor states. They all subscribe to the same topic and the transitions will be triggered according to the msg that has been published to that topic. I started with the following code and tried to manipulate it with rqt. The code looks like the following: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/monitor_example.py.

Basically, I tried to define 2 callback function for the monitor states that examine whether the input has been 2 (the Data.msg contains an int32 crutch_request), if so, then the calculation will be executed. After the calculation is finished, it returns false and the state machine will transit to the next monitor state that does pretty much the same thing. Since I am returning the result of the calc function, I expect the monitor state to finish the calc() after it received the correct number, regardless of further messages published to the same topic.

In practice, however, I tried to publish with the rqt with a rate of 1 and the following happened: At the beginning, the machine behaves normally as expected, starting from the first or the second transition, it sometimes randomly jumps back to the previous state without transitioning. Sometimes the calc() will be executed twice, resulting in two repeated lines of the same printed numbers. Both situations are shown in this screenshot: https://github.com/Mrkeyiiii/ROS_Learning/blob/master/ros_answer_monitor.JPG

Obviously, I have some misunderstanding in the concepts of smach monitors. Could someone please explain to me the reason for the strange behavior of the state machine? Many thanks in advance!

Update: The log of my state machine looks like the following:

qi@ubuntu:~$ rosrun varileg_enhanced_state_machine monitor_example.py 
[INFO] [1554317719.497561]: State machine starting in initial state 'Input1' with userdata: 
    []
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
5
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
5
Working in step 
0
Working in step 
0
Working in step 
1
Working in step 
1
Working in step 
2
Working in step 
2
Working in step 
3
Working in step 
3
Working in step 
4
Working in step 
4
Working in step 
5
Working in step 
5
Working in step 
0
Working in step 
0
Working in step 
1
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
3
Working in step 
4
Working in step 
5
Working in step 
4
Working in step 
5
Working in step 
0
Working in step 
0
Working in step 
5
Working in step 
0
Working in step 
1
Working in step 
0
Working in step 
1
Working in step 
1
Working in step 
[INFO] [1554317721.399003]: Input 1 Triggered
[INFO] [1554317721.399351]: 2
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
5
[INFO] [1554317727.409443]: State machine transitioning 'Input1':'invalid'-->'Input2'
[INFO] [1554317728.310187]: Input 2 Triggered
[INFO] [1554317728.310522]: 2
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
5
[INFO] [1554317734.320002]: Input 2 Triggered
[INFO] [1554317734.321256]: 2
Working in step 
0
[INFO] [1554317734.322496]: State machine transitioning 'Input2':'invalid'-->'Input1'
[INFO] [1554317735.310056]: Input 1 Triggered
[INFO] [1554317735.310512]: 2
Working in step 
0
Working in step 
1
Working in step 
1
Working in step 
2
Working in step 
2
Working in step 
3
Working in step 
3
Working in step 
4
Working in step 
4
Working in step 
5
Working in step 
5
[INFO] [1554317740.327827]: Input 2 Triggered
[INFO] [1554317740.328057]: 2
Working in step 
0
[INFO] [1554317741.319390]: Input 1 Triggered
[INFO] [1554317741.319712]: 2
Working in step 
0
[INFO] [1554317741.320334]: State machine transitioning 'Input1':'invalid'-->'Input2'
Working in step 
1
[INFO] [1554317742.311086]: Input 2 Triggered
[INFO] [1554317742.311495]: 2
Working in step 
0
Working in step 
1
Working in step 
2
Working in step 
1
Working in step 
2
Working in step 
3
Working in step 
2
Working in step 
3
Working in step 
4
Working in step 
3
Working in step 
4
Working in step 
5
Working in step 
4
Working in step 
5
[INFO] [1554317746.334654]: Input 2 Triggered
[INFO] [1554317746.335292]: 2
Working in step 
0
[INFO] [1554317746.337144]: State machine transitioning 'Input2':'invalid'-->'Input1'
[INFO] [1554317747.310481]: Input 1 Triggered
[INFO] [1554317747.310848]: 2
Working in step 
0
Working in step 
5
[INFO] [1554317747.329162]: Input 1 Triggered
[INFO] [1554317747.330325]: 2
Working in step 
0
[INFO] [1554317747.331416]: State machine transitioning 'Input1':'invalid'-->'Input2'
Working in step 
1
[INFO] [1554317748.310556]: Input 2 Triggered
[INFO] [1554317748.310950]: 2
Working in step 
0
Working in step 
1
[INFO] [1554317748.323225]: State machine transitioning 'Input2':'invalid'-->'Input1'
Working in step 
1
Working in step 
2
[INFO] [1554317749.311333]: Input 1 Triggered
[INFO] [1554317749.311786]: 2
Working in step 
 Working in step 
0
1
Working in step 
2
Working in step 
2
Working in step 
3
Working in step 
1
 Working in step 
2
Working in step 
3
Working in step 
3
Working in step 
4
Working in step 
 Working in step 
2
3
Working in step 
4
Working in step 
4
Working in step 
5
Working in step 
 Working in step 
43

Working in step 5 Working in step 5 Working in step 0 Working in step 5 Working in step 4

43 Working in step 5 Working in step 5 [INFO] [1554317752.344246]: Input 2 Triggered [INFO] [1554317752.344642]: 2 Working in step 0 Working in step 5 Working in step 4