augcog / isaacs_server Goto Github PK

Create a dummy drone that delays by 1/2 a second before returning from the service call with a success message.

Lets make this method a global method that takes in a parameter (sensor or drone). This way we dont end up with different things assigning IDs.

Originally posted by @erwang01 in #9 (comment)

Need to publish GPS coords for drone to move in VR. this is a highish priority.

Currently algorithms communicate with the server (operator.py) as another client entity via the rosbridge websocket server. It would be nice to have some sort of API that enabled the algorithm to sit directly on the server rather than having to go through the websocket server every time.

This is in both drone subclasses

Return type of many service call functions should be : dictionary {
success: boolean
message: descriptive string
}

per drone.py

Originally posted by @erwang01 in #9 (comment)

For the sake of convention lets just have all ids be field name id. The IDs should be recognizable by themselves whether they are drones or not.

Pending approval from the team.

If we link topics to the drone object already, does the user really need to report publishes?

Originally posted by @erwang01 in #9 (comment)

• Add Drones
• Upload Mission
• StartMission(ID)
• PauseMission(ID)
• ResumeMission(ID)
• LandDrone(ID)
• FlyHome(ID)

See API document for more details.

Verify that drones have unique names.

Implement a Drone Interface Base Class. This should be extendable and each child class can be a different ROS node or smtg.

Drone - Server communication.

What is the difference between these two services? Is it necessary that we keep them separate?

If so, add the update_mission endpoint to operator.py

Add test to see if the drone.py implementations provide the proper response fields, including the new id field.

Originally posted by @erwang01 in #9 (comment)

In particular rospy and std_msgs are needed at minimum.

The register drone service test does not think that the register drone service ever responded (it just hangs there on line 12 linked below). However, the operator.py recognizes the drone has been registered and responds fine to an all_available_drones service call.

https://github.com/immersive-command-system/isaacs_server/blob/6e276db3e5692d4e98c8c3defb871ec5cde02e3a/src/service_test/register_drone.py#L12

Add Drone should use a universal roslibpy client used by all scripts on one server.

Go through the existing code in the operator branch write documentation for the Wiki.

Mainly we care about the API calls and what they do.

Be careful to not extrapolate what our code does. If our code doesn't do something it should do, either open a github issue for it or say in the wiki that it doesn't do xyz.

This is gonna be an overhaul of our specs from here: https://docs.google.com/document/d/1g3dKYSgtFYrp6Fd4SA6JV8K353C8m3OqXH_cyjhj9-0/edit
and https://docs.google.com/document/d/16jO-q_J6VPLoWYZGIHMzHoWHSoP7eIxv-Z6Rr-1b4Ko/edit

We are trying to assess how much of our code base actually conforms to the spec sheet along with providing a well written wiki so we can lose the google doc.

Our custom DJI sim may not be exactly the same as the original DJI SDK (in fact all its topics are labeled fake). We need to test the DJI drone client on the actual DJI SDK. Moreover, the DJI drone client's code needs to change slightly for that to happen.

Create some sort of framework that can map python functions into service calls, that way we don't need to write handlers every single time.

Implement Service Call endpoints as dictated by the API Document

In Operator.py, our service calls are passed in a response object that we populate. When we say response = func(), we will remap the response variable to the return value of func().

See if this breaks our program. My hunch is that the response returned as a result will be empty / not contain the final values that we want. (potentially containing failure codes due to default assignments)

Example:
https://github.com/immersive-command-system/isaacs_server/blob/72cd8dad09452e4e5a0b51d10d7194082350847f/src/operator.py#L151