FW position controller does not run without global position

[RomanBapst]

Ekf2 does not always publish global position. Since the fw position controller polls on the global position
it does not run in that case.

[julianoes]

This shouldn't be a problem since position based modes aren't available if global position is not valid. And if they are available, it's therefore a bug.

[dagar]

Altitude control mode without global position?

[dagar]

Position control could also switch to _l1_control.navigate_heading().

[RomanBapst]

@dagar Ping :) you probably rememer this.

[julianoes]

Position control could also switch to _l1_control.navigate_heading().

This is logic that the commander should do and not a controller.

@Tumbili what exactly are you suggesting? You can't control position without knowing position, right?

[dagar]

We're mainly talking about FW altitude control mode.

[RomanBapst]

@julianoes @dagar I'll probably be looking at this in the next few days.
I'll be reporting back.

[dagar]

@Tumbili any thoughts of what we should do here? Ideally ALTCTL should work without global position, but if we can't do that easily at a minimum we need to make it required for FW in the state machine.

@AlexisPotvin FYI

[RomanBapst]

@dagar We have decided to get rid of the global position topic on the controller side. We have one position topic which has flags giving information about the scope of the position estimate. We didn't really (at least on the controller side) see a benefit of having two topics. However, we still publish global position because other parts of the system still rely on it (e.g commander or maybe even QGC).

I liked the idea of having a piece of code or a module which polls on a specific topic and only runs once the topic updates. However, you will run into corner cases like altitude control for the fw position controller and in the end you will be using flags again. I'm not saying that it's not possible to do it!

What's your opinion on this?

[dagar]

I don't necessarily want to distract from real work with refactoring/reorganization discussion that you may have already completed (differently), but since you asked...

I didn't really have an opinion before, but now that I look at the messages more closely it certainly would be nice to have more granularity, split them logically, and remove any duplication. I think it's very helpful for understanding the architecture, readability/discoverability (my own sanity), the nice topic poll/run pattern, and of course our new logging.

In the fw position controller case I think using local position for altitude and position control modes is relatively easy, we just need to be careful with TECS between modes. I volunteer to make the change if you're interested in going this way.

Are you aware of the other corner cases?

While we're on the topic, would it make sense to split up the massive position_setpoint message, instead using the individual setpoint messages for velocity, force, local_position? In general is it good practice/design to have a module that in different modes both subscribes and publishes the same message at different times? Eg the position controller subscribes to velocity_setpoints in offboard control mode, but otherwise publishes them.

[PX4BuildBot]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 30 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)