search

BCLab-UNM / SC2

Swarmathon Team Code for the NASA Space Challenge 2 Competition
MIT License
2 stars 0 forks source link

Added volatile sensor location calculation and second attempt scoring #73

Closed abbypribis closed 4 years ago

abbypribis commented 4 years ago
  1. When a VolatileException is triggered in a behavior, score in Scoot.py is called. In score:
  2. The location of the volatile sensor is calculated
  3. The location and vol_type is reported to the /vol_detected_service
  4. If rover is successful, it sleeps for 0.5 seconds (to avoid the VolatileException from being triggered again, while the volatile "disappears") and returns True to the behavior
  5. In the behavior, if score returns True, we have completed our task
  6. If rover is UNsuccessful, the brakes are activated, the rover waits for the upper limit of the /volatile_detection_service_delay_range, calculates the location of the volatile sensor again, and reports the location and vol_type again
  7. If the rover is successful the second time, its brakes are turned off, the rover sleep for 0.5 seconds and returns True to the behavior
  8. If the rover is UNsuccessful the second time, its brakes are turned off, and returns False to the behavior
  9. If False is returned from score, this triggers the rover to turn around in the behavior (mostly to avoid the rover catching the same VolatileException and being stuck in this loop of trying to report the volatile forever) - I wanted this turnaround to be in the behavior, but I wasn't sure how to implement it without importing Obstacles messages

To test: run roslaunch ./launch/scoot.launch "ROS_NAMESPACE:=scout_1" "search:=searchRandomWalk The rover publishes messages about scoring, failing, waiting, scoring the second time, and exiting the behavior

FYI - if someone can think of a better way to do this than in nest try/except/else blocks, that would be cool

Carter90 commented 4 years ago

I noticed to updated the volatile name in some but not all the spots missed

abbypribis commented 4 years ago

Yeah, I just fixed the parts that would stop the volatile service from giving an error when it detected a carbon mono volatile. I haven't noticed it complain about carbon mono since.

Carter90 commented 4 years ago

So far scoring the positions looks good. In 20 mins I had a score of 16. Been getting a lot of ROSInterruptExceptions, looks like there is a pile of ROS package updates, I'm going to do an upgrade and see if that helps. EDIT: Did an update with not luck might need to make the service calls in general more robust.

abbypribis commented 4 years ago

I haven't merged your brake service changes into my branch - did you try that?

gmfricke commented 4 years ago

Abby making new commit so there isn't a redundant "brakes off" command

abbypribis commented 4 years ago

Looks good after testing - still lots of brake error messages, but those are quasi-fixed in pull requests already merged into master. However, I saw it successfully fail to send the volatile message, brake and wait, successfully send the message another time, and unbrake (in Driver) before moving on