Simulink-PX4: Difference between R2022a R2022b (same simulink model does not work in R2022b)

1 visualización (últimos 30 días)
I have recently updated from R2022a to R2022b. I had a project, which essentially builds on top of the following example:
However, the simulink model no longer runs properly in R2022b, so I wonder if there are any noticiable differences (I suspect memmory-related)?
To be more specific:
  • I am using default cmake for pixhawk 4
  • The conversion from R2022a to R2022b project was done by simply dublicating the fully functioning project folder and opening it in R2022b. Then, I only have to correct one single bus entry (changed from "yaw" to "heading") and that is it. No other changes made anywhere else.
  • The model does not run properly in R2022b: everything compiles and runs (in IO mode). In 2022a I can dispay almost anything by left clicking on the signal, which is the same in 2022b. However, the same signals (e.g. quaternian attitude, adc out) are now always zero (or -0), when they should not be. Note that some values are working/dispaying properly. More importantly, I have a sink (send to PWM) blocks at the end of the model and they no longer do anything (although I can clearly see I am trying to set a PWM value, but does not effect the physical actuators that are connected and powered).
  • I have tested different systems and subsystems in a separate simulink model (much smaller of course) and everything works great (both in R2022a and R2022b) when separated, but not all together in one model. I am quite certain there is some limit which I am not aware of. Although, again, everything just worked in R2022a so I am confused.
  • I know IO is slow, especially in large simulink models, but I would expect it to work in the same way as in previous version. I have also tried to compile and and run everyrhing on board, but with the same luck (nothing works). Again, everything works in R2022a with no change to the model or project.
  • I know that R2022a uses PX4 v1.10.2 and R2022b uses v1.12.3. Unfortunately, I am not that familiar with PX4 to tell the difference, but there might be something in the firmware itself that can be adjusted to remove this. Let me know if changing the default .cmake file or startup routine can fix this issue.
  3 comentarios
Yehenii Kovryznenko
Yehenii Kovryznenko el 8 de Feb. de 2023
Editada: Yehenii Kovryznenko el 9 de Feb. de 2023
Thank you for your quick response @Arun Mathamkode!
Yes, I am talking about running a Simulink model in Connected I/O mode with the Pixhawk 4 board attached using a usb-cable.
Also, I have tried running the example and everything seem to work just fine. I have also tried copying the converted Simulink model into this example (just copy-pasted the Simulink blocks, deleting the ones from the example, but did not touch anything else) and again observed the same problems as earlier. To be more specific here is the screenshot of the estimator outputs:
As you can see some data (e.g. vehicle_odometry and vehicle_local_position) is coming though, but some values (vehicle_attitude) remain always constant when they clearly should not (I am actively moving the board with my hands). Interestingly enough, the exact same block works just fine if I comment out most of the other blocks, so I am sure this has nothing to do with the specific blocks. Here is just a screenshot with everything downstream commented out:
Again, this happens to different blocks across the model and is only happening with everything running at once. I am sure there are no errors in the model, since it worked just fine in R2022a and I have checked all the blocks separately (just running systems and subsystems separately, while everything else is commented out) to made sure everything still works.
Just a side note, I am not overwriting any of the uorb messages from the estimator anywhere in the model. Also, in all cases the model compiles and run without any issue at all. In fact, Simulink runs the model just fine, but most values remain constant since input sources appear to be constant.
Arun Mathamkode
Arun Mathamkode el 9 de Feb. de 2023
Thanks for the clarification. Connected I/O Simulation is not ideally designed for running controller kind of application where the model need to run in at a much higher rate. In Connected I/O every Source/ Sink block needs to communicate to the PX4 boards and thus there is a specific minimum time required for a block execution. As the number of Source/ Sink block increases, the simulation also gets much slower and performance will be impacted. Refer the this documentation for more details. I would recommend you running the model in Monitor and Tune simulation instead of Connected I/O in your case. I also would recommend you log the signal and observe it in the Simulink Data inspector, instead of the display block for better visibility.

Iniciar sesión para comentar.

Respuestas (1)

Arun Mathamkode
Arun Mathamkode el 9 de Feb. de 2023
Connected I/O Simulation is not ideally designed for running controller kind of models where the model needs to run at a much higher rate. In Connected I/O every source/ sink block needs to communicate to the PX4 boards and thus there is a specific minimum time required for a block execution. As the number of Source/ Sink blocks increases, the simulation also gets much slower and performance will be impacted. Refer to this documentation for more details. I would recommend you run the model in Monitor and Tune simulation instead of Connected I/O in your case. I also would recommend you log the signal and observe it in the Simulink Data inspector, instead of the display block for better visibility.

Etiquetas

Productos


Versión

R2022b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by