px4flow simulated driver for SITL

[protobits]

I would like to seek for some guidance in how to tackle the addition of reading simulator px4flow data, generated from simulator under SITL. I have extended jmavsim to produce HIL_OPTICAL_FLOW message (will put up a pull request for that, but I would like to complete the Pixhawk side in order to test it).

Now I'm trying to grasp how should I implement this on the pixhawk side and it is a little too complex for me. I would like to ask for some guidance. I can start working and provide a pull request for you to review.

At the moment I have identified that I should extend simulator_mavlink.cpp to handle the MAVLINK message and fill a data structure. However, I'm not sure how this data gets fed to the rest of the pixhawk code. I see some apps such as "accelsim" but I can't see how they are related to this handling performed on simulator_mavlink.cpp. Also, it uses low-level posix interface which confuses me since I was expecting simply to read data from simulator (over mavlink) and then publish it as an ORB message. Or is the idea to always provide a low-level interface?

Thanks,
Matias

[LorenzMeier]

Hi Matias,

We actually have implemented both the uORB approach or the low-level sensor approach. The benefit of the sensor approach is that you can exercise more good. However for your use case directly publishing to uORB should be fine and what you described seems like the right approach.

We will join you in this effort starting this Monday with significant development resources.

[protobits]

Great, I more or less assumed this was the case.

I actually implemented this using orb_advertise on simulator_mavlink.cpp. I
can put up a pull request with my current code if you want. It is a small
change.

I can also put up a pull request for jmavsim, but there are some stubs (I
only implemented px4flow's sonar simulation, not the actual flow readings).

On Sun, Sep 20, 2015 at 5:59 PM, Lorenz Meier [email protected]
wrote:

Hi Matias,

We actually have implemented both the uORB approach or the low-level
sensor approach. The benefit of the sensor approach is that you can
exercise more good. However for your use case directly publishing to uORB
should be fine and what you described seems like the right approach.

We will join you in this effort starting this Monday with significant
development resources.

—
Reply to this email directly or view it on GitHub
#2870 (comment).

[LorenzMeier]

Both would be great and we would love to work with you completing that.

[protobits]

Great. I'll try to contribute with what I can. I'm currently trying to
hack/adapt INAV estimator to use sonar since I need this soon to continue
with my research, so having simulated PX4FLOW helps for that.

Here's the pull request: #2885

On Sun, Sep 20, 2015 at 6:10 PM, Lorenz Meier [email protected]
wrote:

Both would be great and we would love to work with you completing that.

—
Reply to this email directly or view it on GitHub
#2870 (comment).

[LorenzMeier]

Fixed, thanks!