| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| turtlebot:adventures:sensing101 [2015/10/06 22:49] – pvela | turtlebot:adventures:sensing101 [2024/08/20 21:38] (current) – external edit 127.0.0.1 |
|---|
| - Starting with code similar to the ''kobuki_buttons'' code and considering the ''goforward'' code, write a python script called ''gostraight'' such that the robot maintains a forward orientation during its driving. Like ''kobuki_buttons'', this code will use a subscriber to grab the orientation information and uses it to create a feedback signal for straight driving (thereby overcoming any discrepancies between the commanded signal and the actual signal). Like the ''goforward'' code, it will publish drive commands. Since the orientation is a quaternion, you will most likely want to use complex numbers to do the [[turtlebot:adventures:Sensing101_ThetaError|error calculations]]. This keeps the measurement in its most native form until the very end, and will be useful for future enhancements of the feedback controller. Presuming that the robot was just started and has a heading of 0, it should drive forward and use feedback to maintain a zero heading. Compare your original goforward modification versus the feedback-based modification down a long corridor. Is there a difference in how long it can remain centered? | - Starting with code similar to the ''kobuki_buttons'' code and considering the ''goforward'' code, write a python script called ''gostraight'' such that the robot maintains a forward orientation during its driving. Like ''kobuki_buttons'', this code will use a subscriber to grab the orientation information and uses it to create a feedback signal for straight driving (thereby overcoming any discrepancies between the commanded signal and the actual signal). Like the ''goforward'' code, it will publish drive commands. Since the orientation is a quaternion, you will most likely want to use complex numbers to do the [[turtlebot:adventures:Sensing101_ThetaError|error calculations]]. This keeps the measurement in its most native form until the very end, and will be useful for future enhancements of the feedback controller. Presuming that the robot was just started and has a heading of 0, it should drive forward and use feedback to maintain a zero heading. Compare your original goforward modification versus the feedback-based modification down a long corridor. Is there a difference in how long it can remain centered? |
| - Create a script that uses odometry information to turn to a specified orientation. This will be similar in spirit to the gostraight code, but it will just turn in place. The difference most likely will be that the gains should be different as the robot motion behaves nonlinearly as a function of forward velocity. That means the linear control gains should differ. Call the script ''turninplace''. | - Create a script that uses odometry information to turn to a specified orientation. This will be similar in spirit to the gostraight code, but it will just turn in place. The difference most likely will be that the gains should be different as the robot motion behaves nonlinearly as a function of forward velocity. That means the linear control gains should differ. Call the script ''turninplace''. |
| - Copy the draw_a_square code and modify it to use the gyro information. Can you use it to rotate as close to 90 degrees as possible during each turn phase of the draw a square path? (In reality you might not use the gyro measurements directly, but might use their integrated form available through a topic) In this version, you will need to switch between different movement states and controllers. So, although the previous two methods were most likely done within the callback function, here you should consider a finite state machine much like in the ''kobuki_bumpers'' adventure. The callback functions will generate an error signal, while the different state machines will generate the proper control signal and publish it. The solution I envision can either involve a single callback routine for the odometry with processing that depends on the current robot state, or multiple callback routines for the odometry that get switched around based on the state. Here are some tips for the [[turtlebot:adventures:Sensings101_ForwardError|error signal]]. | - Copy the draw_a_square code and modify it to use the gyro information. Can you use it to rotate as close to 90 degrees as possible during each turn phase of the draw a square path? (In reality you might not use the gyro measurements directly, but might use their integrated form available through a topic) In this version, you will need to switch between different movement states and controllers. So, although the previous two methods were most likely done within the callback function, here you should consider a finite state machine much like in the ''kobuki_bumpers'' adventure. The callback functions will generate an error signal, while the different state machines will generate the proper control signal and publish it. The solution I envision can either involve a single callback routine for the odometry with processing that depends on the current robot state, or multiple callback routines for the odometry that get switched around based on the state. The forward driving will require a controller too. Here are some tips for the [[turtlebot:adventures:Sensing101_ForwardError|forward error signal]]. |
| |
| If you get stuck, then here are some [[turtlebot:adventures:Sensing101_Hints|Hints]]. | If you get stuck, then here are some [[turtlebot:adventures:Sensing101_Hints|Hints]]. |
