Patricio Vela: Course Wiki

The button callback code should be pretty self-explanatory. The main thing is to create your own subscriber, then to use rostopic echo and rostopic type to understand the structure of the bumper events enough to create a properly modified version of the button callback function. This code should then be re-used and modified for the next learning task.

What this requires is two variables to be added to your goforward class. One for the safety state in the finite machine, and one to keep track of the bumpers that are hit. Call the first one safety and the second one bhit.

Use the bits in bhit to keep track of which bumpers were hit. The first bit can be the left bumper, the second bit the middle bumper, and the third bit the right bumper. The bits toggle based on the event message for the bumpers.

The safety state then should have three states, let's order them as 0, 1, and 2. In state 0, the robot should be moving forward so long as (bhit is equal to 0). Having any bumper be hit (so that bhit > 0) should immediately trigger state 1. If the bumpers cease to be hit when in state 1 (bhit equals 0 again) should trigger state 2. Pausing fully without hits in state 2 should then return to state 0. Some of this logic gets implemented in the bumper callback function (the hit part), some of it is in the infinite loop for the robot forward motion (the finite state machine logic).

Drawing a state diagram for the finite state machine should clarify what is involved. Try to get it working for a single sensor (say the bump sensor), then work it out for two sensors (bump and wheel drop). If you do so, then you should see that the main logic is predicated on a boolean value that checks the hit and drop statuses (you can even go crazy and add in the cliff sensor status).

There are two ways to solve this: (1) write your own orientation estimator to integrate the gyro information, or (2) access the orientation estimate of the system and use it. In both cases, what happens next is that some kind of feedback control is needed to regulate the orientation to the desired value (90 degrees offset from the initial value). Once close enough, then the turn maneuver should be considered executed.

If using the built-in ROS topic for the orientation part of the robot's pose, then you'll have to work it out in quaternion form (or really in complex form since the other two quaternion values remain at zero). Given the current robot orientation as a complex number, it is possible to get the desired final orientation through multiplication by the proper complex number.

Now, what about the feedback control part given that everything is in complex form? Remember that these numbers live on the unit circle, so they are like vectors. The vector difference inner producted by the normal (in right hand rule sense) to the orientation vector give the error. If it is positive, then the robot must turn left. If ti is negative, right. The closer to zero it is, the closer to the desired orientation. This becomes the feedback term. The only problem is that a complete 180 degree turn is not possible with feedback since the inner product is zero. For 180 degree turns, some special logic is needed. Usually one just commands it to turn in an arbitrary direction. The next time step, the standard feedback control should work.

This task is quite similar to the previous task, but the objective is to remain straight. That means whatever the initial orientation is, that is now the target orientation. The feedback controller should use the inner product between the target orientation and the current orientation to arrive at the feedback law.

The turtlebot is actually quite decent at driving straight. If you want to see the controller in action, you'll have to give it a little nudge when it is running to perturb it away from its forward motion. It should turn back properly.

Sensing 101