PR simulator in hardware, new module #11400


Hi everyone,

I would like to do a follow up on the Pull Request I made few days ago

I added a module called sih (for simulator in hardware). This is an alternative to SITL and HITL for quadrotors where the simulator is executed in the microcontroller.

Did anyone had a chance to try it ? any comments ?

Thanks ,




I would like to know if it is possible to use jMAVSim as a visualization for a quadrotor.
The idea would be to disable the simulation engine, read the MAVlink message HIL_STATE_QUATERNION sent by the autopilot hardware and display the states in the 3D visualization.

The PX4 team proposed me to use jMAVSim for the visualization of the quadrotor trajectory (I am currently using FlightGear).

Do you have an idea of an easy way to implement that in jMAVSim?

I imagine:

  1. adding an argument to start jMAVSim without the simulation engine, let’s say ‘-nse’. That will involve a modification of the main function in
  2. for the MAVlink, I guess I should create a new class that inherited from MAVLinkSystem and use it instead of MAVLinkHILSystem. This will be used to read HIL_STATE_QUATERNION and should send nothing.
  3. To keep the same code structure, I guess I would just put the simulator in pause and update the visual with the states from HIL_STATE_QUATERNION. Unfortunately, it seems the Visualizer3D is linked with the physical World object (itself containing the physical vehicle). Is it possible to separate the physical and visual objects?

Any other things I should be aware of before starting?





Can you send me a link for an example of code of the semaphore to get a real time calback that can be itself interrupted?





I am not 100% clear on what it is you wanted to do, so I am not sure if the examples are germain.

Here is one example: and

The term call back is overloaded. An HRT call back in on an interrupt thread. A HPwork call back is on a high priority thread and it would not be a good idea to block it as well.

Interrupts and HP work should be “Short service” “long service” should be done on properly prioritized threads.

In that case a thread waits on a semaphore sem_wait() and the HRT call back posts to that semaphore sem_post(). The down side is resources need to be allocated to the task. If the memory is available this is not an issue.


Thank you for this info, I will explore the options.


I finally implemented it using hrt_call_every() and px4_sem_wait()

void Sih::run()
    px4_sem_init(&_data_semaphore, 0, 0);

    hrt_call_every(&_timer_call, LOOP_INTERVAL, LOOP_INTERVAL, timer_callback, &_data_semaphore);

    while (!should_exit())
        px4_sem_wait(&_data_semaphore);     // periodic real time wakeup

        inner_loop();   // main execution function

hrt_cancel(&_timer_call); 	// close the periodic timer interruption

// timer_callback() is used as a real time callback to post the semaphore
void Sih::timer_callback(void *sem)
    px4_sem_post((px4_sem_t *)sem);

It works super well, thanks :smiley:

  • sampling time [us]: 3999 avg, 3937 min, 4059 max, <3us rms error
  • the module sih uses 10.7% of the CPU time (on auav-x2.1 board), and the idle is at 50%

The suggestions on how to change jMAVSim sound ok. I don’t know the details myself but if you can add your visualization only feature without too crazy changes and disabled by default, I think it’s worthwhile to get it merged.


I implemented something which is working but the rendering is jerky.

I used KinematicObject.setPosition() and KinematicObject.setRotation() to update the position and orientation of the vehicle whenever HIL_STATE_QUATERNION (i.e. the groundtruth) is received from the autopilot. The code is available here.

It looked like an aliasing problem, so I tried with the flags -aa and -no-aa to enable/disable the antialiasing. But both attempts resulted in a jerky display.

Any other flag I can modify for the display?
Any other idea?


Hi Romain,
Your concept is really nice. Could you please explain me, why px4_fmu-v2 is not supported? Is the hardware too slow or any other reason?

Thank you and kind regards



As far as I understand, excluding the simulator-in-hardware from px4_fmu-v2 is due to hardware limitations. Maybe @dagar can give more details as he advised me to do so.




px4_fmu-v2 has a silicon errata. Therefore, we can only safely use 1 MB of 2 MB flash space and are quite limited in what can be included in the binary.