search

fselius / qtcopter

2 stars 0 forks source link

Code structure #1

Closed fwalch closed 9 years ago

fwalch commented 9 years ago

This is an idea how to structure the code as Ro'ee, Vasily and myself discussed yesterday.

Most code goes into one of the subdirectories of the qcopter package. We can also add tests in this package (test directory; run with catkin_make run_tests). For simulation, we could add some launchfiles into the same package, but it's probably cleaner to do simulation stuff in a separate qcopter_sim package (because it requires additional dependencies).

High-level overview

So for the competition, it would work like this:

We identified the following steps, for each of which a class has been created for now:

  1. Take off movement/TakeOff
  2. Approach mission site ("dumb", using hints hardcoded into the launch file from our measurements at the competition site) navigation/ApproachMissionSite
  3. Mission-specific:
    1. Try to locate exact point where to start mission (e.g. for ball drop, go into spiral flight, trying to find target on the ground). This needs to be fast and will give some candiate locations. missions/*/IdentifyMissionSite with navigation/exploration/*
    2. If a possible location is found, stop the flight and verify that we are indeed in the correct location (this can be slower). If we are not in the right location, resume step 3.1 Otherwise, position in an ideal starting point for the mission (e.g. ball drop: center drone above target on ground). missions/*/VerifyPosition
    3. Approach and continuously verify we are at the correct location/position. Once in a good position (ball drop: landed in center of target, QR scanner: in front of QR code), perform the mission task (drop ball, scan code, ..) missions/*/PerformMission
  4. Fly back to base movement/ApproachBase
  5. Land movement/Land

Each of these classes can, additionally to being used as a "normal" class, be implemented as a ROS node (only requires adding code to subscribe to topics in if __name__ == '__main__'). If executed as a standalone node (i.e. for example python2 ./missions/balldrop/PerformMission.py), we can test functionality of parts of the system individually. We can manually satisfy preconditions (e.g. manually fly to mission site and position above the target), then start automated part (land on target and drop ball).

Bringing these steps together would be implemented in nodes/<mission> by calling into the library classes outlined above, switching from one stage to the next using some state machine.

Any thoughts, questions, suggestions, ...?

noamyogev84 commented 9 years ago

great job!

2015-04-07 19:47 GMT+03:00 Florian Walch notifications@github.com:

This is an idea how to structure the code as Ro'ee, Vasily and myself discussed yesterday.

Most code goes into one of the subdirectories of the qcopter package. We can also add tests in this package (test directory; run with catkin_make run_tests). For simulation, we could add some launchfiles into the same package, but it's probably cleaner to do simulation stuff in a separate qcopter_sim package (because it requires additional dependencies). High-level overview

So for the competition, it would work like this:

  • Preparation:
    • Get some measurements from the competition area.
    • Enter these as initial hints for the drone into the qcopter/launch/.launch file.
    • Competition:
    • Run roslaunch qcopter .launch, and that's it. Drone will take off, fly according to these hints, find the exact mission site, perform the mission, fly back and land.

More details

We identified the following steps, for each of which a class has been created for now:

  1. Take off movement/TakeOff
  2. Approach mission site ("dumb", using hints hardcoded into the launch file from our measurements at the competition site) navigation/ApproachMissionSite
  3. Mission-specific:
    1. Try to locate exact point where to start mission (e.g. for ball drop, go into spiral flight, trying to find target on the ground). This needs to be fast and will give some candiate locations. missions//IdentifyMissionSite with navigation/exploration/
    2. If a possible location is found, stop the flight and verify that we are indeed in the correct location (this can be slower). If we are not in the right location, resume step 3.1 Otherwise, position in an ideal starting point for the mission (e.g. ball drop: center drone above target on ground). missions/*/VerifyPosition
    3. Approach and continuously verify we are at the correct location/position. Once in a good position (ball drop: landed in center of target, QR scanner: in front of QR code), perform the mission task (drop ball, scan code, ..) missions/*/PerformMission
      1. Fly back to base movement/ApproachBase
  4. Land movement/Land

Each of these classes can, additionally to being used as a "normal" class, be implemented as a ROS node (only requires adding code to subscribe to topics in if name == 'main'). If executed as a standalone node (i.e. for example python2 ./missions/balldrop/PerformMission.py), we can test functionality of parts of the system individually. We can manually satisfy preconditions (e.g. manually fly to mission site and position above the target), then start automated part (land on target and drop ball).

Bringing these steps together would be implemented in nodes/ by calling into the library classes outlined above, switching from one stage to the next using some state machine.

Thoughts?

You can view, comment on, or merge this pull request online at:

https://github.com/fselius/qcopter/pull/1 Commit Summary

  • Set up ROS workspace.
  • Set up initial structure, dummy unit/integration tests.

File Changes

Patch Links:

— Reply to this email directly or view it on GitHub https://github.com/fselius/qcopter/pull/1.

fselius commented 9 years ago

Looks great! We should also think about how to handle exceptions and failsafe. If battery < 30% abort current mission and run movement/land.

fwalch commented 9 years ago

For exceptions and failsafe, we could probably run a dedicated node that takes over once it detects a failure (e.g. if another node crashes). A quick search turned up the node_monitoring project (which is apparently not maintained anymore) and arni, which acts on statistics of topics.. maybe we can use that to detect if a node doesn't publish anything anymore (thus has likely crashed).

fselius commented 9 years ago

It would be cool to have something that monitor unexpected behavior and acts upon it. Unexpected behavior could be:

But that's still far ahead of us..