search

yoyo802088 / ARB-Y

RoveCrest project for the EEC193AB course and University Rover Challenge
0 stars 0 forks source link

Emergency detection & escape implementation #9

Open yoyo802088 opened 3 years ago

yoyo802088 commented 3 years ago

Wanyue will be implementing how the rc car would know that it's in an emergency situation and how it would attempt to get out of it.

reginazhai commented 3 years ago

This is the reference code I found online about sending navigation goals through our own code. Since we have not finished setting up the motor for the RC car this week, I don't know for sure how to detect the velocity of the car. But it navigates to the goal assigned in simulated environments. [https://hotblackrobotics.github.io/en/blog/2018/01/29/action-client-py/]

reginazhai commented 3 years ago

The current /catkin_ws/src/champ_control/position_tracking.py is used for emergency escape.

We use python3 to run the code.

$python3 position_tracking.py

Incorporating the code from teleop_twist_keyboard, we came up with the hardcoded solution when the car gets stuck. The program would first receive the data from topic /zed/zed_node/pose, which contains the position of the car. If the car's position remains the same under a threshold (0.001 as default in this case), we would consider that the car is not moving. Hence, we would try to go straight (publish linear.x and angular.z through /cmd_vel) and see if the position changes. If not, it would try to drive to the left and compare, and then drive to the right to compare. If none of the driving works, it would stop and display "Help! Stuck!" in the terminal page.

If the car get to the point to display"Help! Stuck!", it means that the car need some people to manually bring it out. The car would try for another two times until it gets to "Help! Stuck!" If it gets to the third time, the car would stop and wait for actual help.

During the moving around process, if the position of the car actually changes, it would discard the previous stuck condition and start from the number of stuck from 0.

Possible future improvement:

  1. It is possible that the car is able to move around while getting stuck, so we would also want a smarter approach.
  2. While the program is able to run by itself, it cannot run with move_base for now. Since both are sending information through /cmd_vel, the commands that low_level_control.py receives is mixed. There will be some sudden changes in behavior for the car. Hence, we would like to find a way to resolve the problem (possibly through changing move_base)