PX4-Pro Babysitter? (Arming / setpoints frustration)

Hello,

I’m working on a mainly ROS-oriented setup, but there are obvious reasons why some of it should be left to the code-base that really knows autonomous flight. I simply want to arm PX4 and give it commands in the form of velociy and / or position. This has proven to be the hardest part of the whole project so far. Given the fact that I’ve had to learn everything from linux to C++ form scratch that’s actually pretty impressive.

I’ve turned off all circuit breakers, I’ve crushed a couple of autopilots in frustration and I even gave up and turned to arducopter (3.5.3(’?)- which actually armed easily through ROS. From there on out there was just endless hopelessness, so I’m back to PX4 again.

Can someone please help me with just getting this damned headache out of my head?? I don’t care if the autopilot knows where it is, I don’t care if it’s not re0sponsible; I do the tests in an isolated environment and would just like to be able to turn on the equipment I’ve spent all this money on!

I’m using a DJI550 pixhawk2(cube), odroid XU4, firmware 1.6.5stable, astra camera, rplidar, 6xdji-420ESC’s, tanaris frsk, some GPS I had laying around (GPS is not to be used), px4flow and lidarlitev3 (not working btw, waiting for active I2C splitter supposedly delivered today.

And while I’m here anyways; same issue with the intel aero running docker. For some reason the FCU refuses to enter “connected”-state, and same story follows!

There are just too many checks and too few ways around them if one wish to customize the setup beyond altering quad-setups! There should be a way to just get the system up and running with functionality despite the commander feeling safe.

  1. Managed to arm, as I was using a land-connect I use when I work (not having to swap batteries all the time) this somehow prevented me fro arming.

  2. Now I’m sending setpoints, FCU is connected, vehicle is armed and status is offboard - tried all kinds of combinations of no-rc etc, no action.

  3. Finally commander gave me a hint - “no position lock”. Even though I’ve both set the GPS circuit breaker and the “allow arming without GPS”.

It really just comes down to trial and failure for someone who doesn’t know their way around the almost thousand params…

And sorry for being such a whiny bitch about it, I’ve been up all night with this.

Hello,

There are a lot of details here, and OFFBOARD is really more of a developer feature.

If you enabled logging from boot (SDLOG_MODE 1) and went through this again describing what you’re trying to do, and then what actually happened I could take a look at the log and tell you exactly what’s actually happening.

The GPS circuit breaker is for detecting a bad GPS. Arming without GPS is one thing, but you still need a valid position estimate for modes (including particular offboard usage) that require it.

If there are rough edges for this use case let’s try to fix them, including better documentation. https://dev.px4.io/

Hello,

Thank you for the positive response, despite my rambling. (I apologize for this).

So to be as specific as I can be; I am trying to utilize the twist/pose controllers to manage low-level control - keeping the unit stable and moving it slowly from point to point - without having to set up a lifetimes worth of code. I need this first, and if everything works, (as I always expect but never experience), the next step is…more fancy.

Position is already handled by the established system, but as mentioned, it lacks the ability to handle a quad/jhexa-copter. This is the reason why I stated that I “don’t care if the autopilot knows where it is” - I have to tell it where it’s supposed to go nonetheless. At this time the tuning and understanding of PX4’s own filtration/fusion is beyond my capacity.*

I’ve done some small changes to the offboard example, and I’m now able to arm, change to offboard, send persistent setpoints - and I found another of my problems with getting some action: my frsky was not set up correctly. (It still ain’t, but I had another one which seemed to be. ) I’ve moved to a more “expendable” set-up, but I actually found the pixracer more cooperative than the pixhawk2; is this only because I now have RC-control? (I realized that was a stupid question as I wrote it).

Specifics:

  1. Main issue (as far as I understand atm): Lack of position for the autopilot.
    Solution#1: Vicon_bridge as pr developer guide. This package no longer have the referenced launch-file (actually it was a .sh file?). Anyways, I don’t think it’s a good siolution to my case.
    Solution#2: Publish NavSatFix with 7 (maybe 8?) decimals will yield higher accuracy than “naked” GPS (ofc dep on fix# etc), is this as simple as that, or do I have to do it in synergy with the editing of mavros’ configurations?
    Solution#3: Publish position as a ROS transform? Am I understanding the option correctly? This would be the by
    far best alternative for me.

1.2) To calculate from local Cartesian coordinates to GPS and forward it to mavros is a little extra work, no way of just using local coordinates given that home position is set?

  1. Is it my responsibility to provide accurate and updated position if I want the system to react to i.e drift or gusts of wind etc? If I’m publishing setpoints while the craft is at x0,y0,z0, while aaa… Yeah it must be, I guess.

I will do as you suggest after I’ve had a little sleep, hehe, get back to you then.

Btw; regarding documentation: I was using deprecated mavros until these last few days. Only when I randomly tried the install-script provided I got the soure-installed one with the correction utilities. This should be stated explicitly, binaries for kinetic is no good. (The scripts work excellent btw, thanks! )

The offboard example is also deprecated, just very small changes to the semantics and it’s good, but still not intuitive for those who are likely to use it as their offboard code.

Aaand, last ting, why not add a subscriber to pose, listening to a custom topic for new pose-messages (in offb_example)? If the pose is made global it can just be changed in the callback, removes the concern of both having to publish fast enough and being able to actually publish at your own pace (while not messing with the arming/offb checks). However I could be missing something crucial, as mentioned I really don’t have much clue.

Thank you!

Jesus christ, haha, PLEASE disregard everythin pre-2020.

I was just wondering what you were talking about, and was about to link to videos and docs until I saw the date…

I hope you had fun and got it to work!