Add hil state quaternion

[kd0aij]

one more try at fixing #33

[bkueng]

Looks good now, merged.

[kd0aij]

thanks, that was very educational :)

[mpaperno]

Sorry a bit late on this, just catching up. Could this new message be optional somehow? I've found reducing/limiting the amount of data being sent on the link to the flight controller to be highly preferable to adding new data. I"m not sure what PX4 uses HIL_STATE_QUAT message for, but it's just noise in my/AQ implementation.

Thanks,
-Max

[kd0aij]

@mpaperno This only affects SITL/HIL. Under what circumstances would you not want simulator ground truth?

[mpaperno]

This only affects SITL/HIL.

What else could it affect? I'm confused by this statement.

Under what circumstances would you not want simulator ground truth?

The flight controller doesn't need to know "ground truth" in order to fly. To simulate a "ground truth" situation which could actually happen in real life, something like RTK correction data would be more useful IMHO.

Anyway, my main point here is that in at least some circumstances this extra data on the line is not desirable. Disabling this extra data w/out having to edit code and rebuild would be useful.

-Max

[kd0aij]

I thought "on the line" referred to a physical link. Are you running into problems with cpu load or network bandwidth?

[mpaperno]

Yea, line = physical link. Sorry if that was vague. In the past, bandwidth is the biggest problem I've found, followed closely by CPU and (especially) I/O performance on the PC side (desktop OSs not exactly being "real-time" for the most part).

-Max

[kd0aij]

I agree that realtime performance is nice if one is using a simulator with manual control inputs to practice "real" flying. But for all other applications, a discrete event simulation need not achieve realtime rates to be accurate.

I'd be interested in learning more about how you're using jMAVSim. Also, what hardware/OS and what kind of cpu load and interprocess comms bandwidth do you see?

[mpaperno]

Using it mostly for real-time HILS, testing AutoQuad firmware with "real" flying. Autonomous flight modes can also be tested w/out manual (radio) inputs. The only link type fast enough right now on our hardware is USB (AQ doesn't have Ethernet). Seems to work on most modern 64-bit PC hardware with at least a few CPU cores and good USB drivers. Win/Mac/Linux. CPU load varies... on my primary 8-core @ 4GHz Xeon box it's pretty low... :) But it works fine on slower machines as well... as long as nothing else is running which might preempt CPU time and I/O (eg. virus scanner).

I made some further threading improvements on my fork, if anyone wishes to test that out. Seems to improve real-time performance quite a bit and make it more consistent between different PC hardware.

https://github.com/mpaperno/jMAVSim/commits/master and especially these 3:
mpaperno@2c9d6f5
mpaperno@d3ca262
mpaperno@991f4da

-Max

[kd0aij]

I was using HIL/jMAVSim for simulated flight testing in PX4 up to a year ago, but switched over to SITL once that became more mature. I still test manual control of things like 6DOF ACRO mode (PX4/PX4-Autopilot#5498) using near-real-time simulation on my 6-core AMD Linux box, and it seems about the same as the real thing (except for the pucker factor).

I had also played around with thread synchronization on my fork, but DrTon and I didn't seem to agree :) I like the idea of using atomic access where thread sync isn't necessary; is the clone() method a language built-in? I haven't been keeping up to date with Java since about 2007.

[bkueng]

How about we use MAV_CMD_SET_MESSAGE_INTERVAL to set the HIL_STATE_QUAT rate, and default to a rate of 0?

I'm also interested in more fine-grained synchronization, but it's also more difficult to get it right.

[mpaperno]

@bkueng

How about we use MAV_CMD_SET_MESSAGE_INTERVAL to set the HIL_STATE_QUAT rate, and default to a rate of 0?

That sounds good to me, especially if it fixes latest PX4 issue. Sorry for the late reply.

-Max