[generic] path_upload_map question about rapp-api

[klpanagi]

Both png_file and yaml_file arguments are expected to be files. The combination of these files form a map that will be later used to perform path_planning on, by calling the /path_planning_plan_path_2d service

doc-here

[alexge233]

is it OK if I expect an std::string in place of the yaml? (assuming a serialised file rather than a parsed object).

[etsardou]

If you mean the C++ API to send a serialized file in the web service, no, since the web service and the python/JS API are already implemented this way.

If you mean for the user to provide your implemented C++ call a std::string (instead of a yaml), why is it a problem for the developer to provide the path of the yaml file? The two-files format (yaml & png) is the standard way in ROS to parse maps.

[alexge233]

This is what I don't get: do I have to upload those files, or are they assumed already on the platform, and I simply have to state which one to use?

Am I sending parameters, or files? If the latter, then I need to serialise the PNG (done via class picture) and the YAML (which is in essence an std::string for my intents and purposes).

[klpanagi]

This is what I don't get: do I have to upload those files, or are they assumed already on the platform, and I simply have to state which one to use?

The path_planning_upload_map web service has been developed in order to upload map files which will be later used to perform path-planning (e.g. path_planning_plan_path_2d).
This way, clients can (ONCE) upload a map and perform multiple path_planning_plan_path_2d service calls.
The Web Service expects both files to be uploaded. Those files are stored on the Platform.

Am I sending parameters, or files? If the latter, then I need to serialise the PNG (done via class picture) and the YAML (which is in essence an std::string for my intents and purposes).

Both yaml_file and png_file are expected to be file uploads in a multipart/form-data .POST request

[alexge233]

I am sorry but this is still confusing me.
You say:

Both yaml_file and png_file are expected to be file uploads in a multipart/form-data .POST request

But you have a png_file parameter. I am guessing this is the name of the image file being uploaded?

Same with the yaml you have a yaml_file parameter, which I am also guessing this is refering to the yaml file being uploaded?

If this is the case, then my constructor is:

path_upload_map(
                 const rapp::object::picture png_file,
                 const std::string png_filename,
                 const rapp::object::yaml yaml_file,
                 const std::string yaml_name,
                 const std::string map_name,
                 std::function<void(std::string)> callback
               )

Thus when you receive the call, you will get a multipart/form data POST, with a JSON referencing the multipart form binary and text data of the files.

Is this what you want?

[etsardou]

If the path_upload_map is the API function the developer has to call, then he must not create rapp::object::picture objects. He just needs to give as input parameters the following:

path_upload_map(
const std::string png_filename,
const std::string yaml_name,
const std::string map_name,
std::function<void(std::string)> callback)

Its the C++ API's job to take these files (specified by their path only), internally create any object necessary and make the call to the platform Web service.

I guess you have implemented face detection, qr detection (and all other calls requiring to upload an image) the same way.

[alexge233]

@etsardou no I have done the exact opposite throughout the entire rapp api. In fact its the other way around, normally every API takes object params (e.g., STL, OpenCV, Boost) since those are libraries.
The responsibility of loading and manipulating the files lies with the developer, as well as dealing with their memory management.

Have a look at the following:

1. face_detection: https://github.com/rapp-project/rapp-api/blob/cpp/cpp/includes/cloud/vision/face_detection/face_detection.hpp
2. qr_detection: https://github.com/rapp-project/rapp-api/blob/cpp/cpp/includes/cloud/vision/qr_detection/qr_detection.hpp
3. speech_to_text_sphing4: https://github.com/rapp-project/rapp-api/blob/cpp/cpp/includes/cloud/speech/speech_detection_sphinx4/speech_detection_sphinx4.hpp
4. same with path planning, human, hazard or object detection and so on.

and their respective examples:

1. https://github.com/rapp-project/rapp-api/blob/cpp/cpp/examples/speech_to_text.cpp
2. https://github.com/rapp-project/rapp-api/blob/master/cpp/examples/face_detect.cpp

Of course I can provide helper functions so that the files are loaded from a location, but I honestly see little benefit in doing so (other than some minor error checking).

Back to the discussion at hand:

1. I am correct in assuming that both a JSON and the multipart/form-data are expected?
2. Should the file names refer to the multipart boundary binary data?

[etsardou]

Then I see no point in giving file names at all. Just proceed with the files themselves.

[alexge233]

@etsardou thats what I thought too, hence why I kept asking 👍

EDIT:

Just to be clear:

1. the JSON will contain ONLY a map_name
2. the POST multipart/form-data will contain the binary data of the PNG and the string data of the YAML.

[alexge233]

Hi,

I've done some major refactoring:

1. renamed a class (header to pose_metadata since I use header in asio for TCP/IP).
2. broke down de-serialization from a JSON/Boost propetry tree, as struct/class constructors (UNTESTED)
3. changed struct time to work with std::chrono (feel free to remove member sec).

Can somebody please write a simple test for the navigation/path planning and test it? I'll write individual unit tests (especially with the JSON params), but as of yet branch cpp has untested code.