Differences

This shows you the differences between two versions of the page.

--- turtlebot:adventures:sensing101_hints [2015/10/06 18:02] – [Gyro-Based Turning] pvela
+++ turtlebot:adventures:sensing101_hints [2024/08/20 21:38] (current) – external edit 127.0.0.1
@@ Line 29: / Line 29: @@
 ==== Gyro-Based Square Drawing ====
-This one combines the above two and uses a finite state machine to alternate between them.  The finite state machine should have four states it seems.  One state is for forward driving and uses the ''gostraight'' feedback control algorithm above.  Another is for pure turning and uses the ''turninplace'' feedback control algorithm.  What about the other two?
+This one combines the above two and uses a finite state machine to alternate between them.  The finite state machine should have four states it seems.  One state is for forward driving and uses the ''gostraight'' feedback control algorithm above modified to [[Turtlebot:Adventures:Sensing101_ForwardError|regulate the forward velocity]].  Another is for pure turning and uses the ''turninplace'' feedback control algorithm.  What about the other two?
 Well, I think they should be to transition from forward driving state to the turning (and vice-versa).  that means the system would really be state 1, prepare for straight driving and identify goal; state 2, perform straight driving to a specified goal; state 3, prepare for turning by identifying goal; state 4, perform turning to a specified orientation.  When state 4 terminates, then it goes back to state 1.  A combination of a while loop with a finite state machine (operating at a certain rate) and a series of odometry subscribers with different callbacks should be employed.
-  Prior to the drive straight, one needs to grab the current robot position, figure out the relative forward location that it needs to go to, then define all the proper variables for use in the callback.  Once defined, the system can transition to the drive straight. Here, there needs to be a feedback controller to do that.  In addition to ensuring straight progress via turn feedback control, the forward velocity should also have some feedback based on how close it is to the goal.  Once it is "close enough" to the goal then it should transition to the next state (which should be turn in place preparation).
+Prior to the drive straight, one needs to grab the current robot position, figure out the relative forward location that it needs to go to, then define all the proper variables for use in the callback.  Once defined, the system can transition to the drive straight. Here, there needs to be a feedback controller to do that.  In addition to ensuring straight progress via turn feedback control, the forward velocity should also have some feedback based on how close it is to the goal.  Once it is "close enough" to the goal then it should transition to the next state (which should be turn in place preparation).
-  Likewise, prior to the turn in place, one needs to grab the current robot pose, figure out the relative orientation that it needs to go to in absolute odometry terms, then define the proper variables for use in the callback.  Here, nothing special beyond what was already done in the ''turninplace'' adventure is needed except to recognize when to terminate this finite state and move to the next one.
+Likewise, prior to the turn in place, one needs to grab the current robot pose, figure out the relative orientation that it needs to go to in absolute odometry terms, then define the proper variables for use in the callback.  Here, nothing special beyond what was already done in the ''turninplace'' adventure is needed except to recognize when to terminate this finite state and move to the next one.
-  If you do the above, the Turtlebot may drive in a square forever unless you keep track of the amount of times you've driven forward and turned.  If you do so, then you can figure out an additional terminating condition that could be triggered to end the square maneuver.  This would be extra, but good to figure out.
+If you do the above, the Turtlebot may drive in a square forever unless you keep track of the amount of times you've driven forward and turned.  If you do so, then you can figure out an additional terminating condition that could be triggered to end the square maneuver.  This would be extra, but good to figure out.
+When you want to grab the current state (pose) of the Turtlebot but don't want to have to create a subscriber, then it is possible to simply request the information using ''wait_for_message'':
+<code>
+  msg = rospy.wait_for_message("my_topic", MyType)
+</code>
+The ''msg'' variable (or whatever you call it) will have the data associated to the topic.  Mind you it may wait a bit for the latest data to be made available (depending on the message and its publication frequency).
+Also, when you want to stop subscribing to something, there is a function called ''unregister'' that will do the trick.  You need to have the subscriber object available to you though.  The way to do that is to save the subscriber when you start it.  As an example, for ''kobuki_button'' code one would do:
+<code>
+  subButtons = rospy.Subscriber("/mobile_base/events/button",ButtonEvent,self.ButtonEventCallback)
+  ... some code here ...
+  subButtons.unregister()
+</code>
+Once the topic has been unregistered, the callback will no longer be called.  More generaly the subscriber will have been killed.  To start appears to require re-instantiating a new subscriber and overwriting the subButtons object with the newly created one.
 ---------
 ;#;
 [[turtlebot:adventures:Sensing101 | Sensing 101]]
 ;#;