Px4 Support for Embedded Coder - pixhawk not configured correctly

8 views (last 30 days)
Kevin Hainline
Kevin Hainline on 13 Oct 2019
Edited: Deep Parikh on 3 Feb 2020
Trying to get simulink writing to my pixhawk 4 on 2019b, windows 10.
I am able to compile, upload, and connect with external mode. I can even read inputs from my RC radio or show gyro values on scopes/displays. HOWEVER:
I cannot, for the life of me, arm the PWM outputs so that I can actually use them. "px4demo_PWM", does not work for me, and any number of changes I cannot seem to get to work. If I power everything down, move the servos somewhere, and then power everything up, the servos always move to the "failsafe" positions after initialization. I can even change the failsafe position and get the servos to move there instead, but I cannot command out normally despite the failsafe being set to off and ARM enabled.
Looking at "actuator arming" the actuators are not, in fact armed, so I tried manually doing a uORB write to force it to an armed state. It showed armed, not on failsafe, not lockdown, etc., but no commands could get out.
After much troubleshooting and banging my head on the table I eventually came to realize the RGB LED flashing red and determined that means the pixhawk is "not configured correctly". Would I be correct in guessing this is why it refuses to arm? Fundamentally my primary question is "how do I get my pixhawk to drive servos normally?" but there are numerous follow up questions:
Is this potentially an issue with my hardware or is this part of the normal setup? Are you supposed to load the normal px4 firmware in QGC, configure it normally in QGC, including calibration and such, and then come back to simulink and use embedded coder? Is there a way to change configuration parameters without using QGC? What parts of the PX4 flight stack are being overriden when you load a custom simulink app (if any)?
I'm trying to understand where the line is between the core flight stack and the app i'm trying to run on top of it. Preferrably, I would handle arming myself within my app and not have to deal with all these other checks that PX4 is natively doing behind the scenes. Is there a way in the "rc.txt" file to basically say "let simulink_app handle everything, pipe all raw sensor data to it, run all outputs from it, no questions asked?" But, at the same time, the core flight stack appears to be generating a navigation solution that you can easily tap into using a uORB read, and I want to be able to leverage that.
I know that's a spew of questions, sorry about that. Please provide any clarification you can, thanks!

Accepted Answer

Deep Parikh
Deep Parikh on 21 Oct 2019
Edited: Deep Parikh on 3 Feb 2020
  1. Regarding the PWM pins not working as intended : PX4 has two arming mehnisams. The one which you are doing with the uORB write and the other which is done using a sfety switch. As mentioned in the documentation for "px4demo_PWM" example, to get a desired PWM output, safety switch must be connected to the pixHawk and you have to press it for certain seconds to arm the pixHawk. The issue appears to be related to physical arming through the safety switch. Hence, ensure the safety switch is connected propely and arm the pixHawk using it.
  2. The PWM channels are segregated in certain groups for various flight control boards. While writing to various channels, ensure that you are writing values to each channel in a particular PWM channel group to get desired output.
  3. You can remove the SD card from the pixHawk, load the normal firware with QGC, select airframe and perform calibration and then load firware using simulink. Do not forget to insert SD card with specified file once the firware is uploaded via simulink.
  1 Comment
Kevin Hainline
Kevin Hainline on 29 Oct 2019
I got it working on my pixhawk 4 now, thanks.
What happened was by the time I was trying the safety switch I had screwed up the rc.txt config trying to get things to work. After resetting to the default rc.txt and holding down the safety switch everything was fine. (It's always the simple things).
Unfortunately, if I try the exact same procedure on my pixhawk 4 mini, I have no such luck. On pixhawk 4, at the end of startup the LED is flashing and the servos have gone to failsafe. I hold safety switch for a bit, LED goes red and servos jump to "center". On pixhawk 4 mini, it appears hung in startup: the servos never go to failsafe, the LED is just OFF, not flashing, and holding down the safety switch does nothing. I even kept the same safety switch between the two boards to try to remove that variable; no joy.
Removing the SD card for QGC is a nice workaround that has been very helpful: before I was changing the mavlink settings on the card everytime depending on if I was uploading or using QGC.
How do I select the workflow path for waypoint follower vs. flight controller?

Sign in to comment.

More Answers (0)

Products


Release

R2019b

Community Treasure Hunt

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

Start Hunting!