OFFBOARD mode docs

[TSC21]

Hi,

I would like to get some info regarding the OFFBOARD mode, pointing out:

• [x] How to activate it in QGS and how to properly configure an RC switch to it (since http://pixhawk.org/users/system_modes/mode_switch_config doesn't make reference to OFFBOARD mode)
• [x] How it is implemented, i.e. if I switch to it (via RC switch or QGC), what's it's behaviour? Does it stay in position hold and hovering waiting for offboard commands?

Regarding offboard2_externalsetpointmessages and https://github.com/PX4/Firmware/pull/1151:

• [ ] Is it already testable and how can it be tested (a proper procedure to test it based on OFFBOARD behaviour currently implemented)
• [x] What kind of control can already be issued? pos, vel (linear and angular=attitude rate), accel,... ?

@LorenzMeier, @thomasgubler can you give some points here? If you give some guidelines regarding the above I wouldn't mind to do get some documentation ready to add to PX4 docs. Thanks in advance!

[TSC21]

Ok regarding the first topic, I got the answer by modifying the RC_MAP_OFFB_SW parameter in QGC, adding a RC channel # to it. Regarding the other stuff, still need some clarifications though. Thanks!

[TSC21]

Ok I alreday started testing offboard2_externalsetpointmessages. I'm using GCS to debug. I have channel 7 of my RC allocated to change to OFFBOARD mode. Pixhawk is directly connected to my Laptop through USB. No battery connected and no arming.

I can easily change to ALTCTL, POSCTL, LOITER and MISSION using RC channels and no rejections since I have position lock with GPS+PX4Flow. But when I switch to OFFBOARD mode I always get the response REJECT OFFBOARD.

What should be done so that OFFBOARD can be accepted?

Update: Also tried with battery connected and armed, with the same results.

[thomasgubler]

@TSC21 I currently test with the mavlink command MAV_CMD_NAV_GUIDED_ENABLE to switch to offboard, also note that i do not test with the standard controllers (I use custom ones here). As far as I know, before the introduction of the new mavlink messages only position and velocity offboard control was implemented. So I expect this to work.

Offboard attitude control may need some small additions like converting the quaternion.

Re your error: are you sending offboard setpoints? Without a valid offboard setpoint the system will not switch to offboard mode. Also see this WIP qgc branch https://github.com/mavlink/qgroundcontrol/tree/joystickinput_settargets You can use it to test with a joystick.

[TSC21]

Also see this WIP qgc branch https://github.com/mavlink/qgroundcontrol/tree/joystickinput_settargets You can use it to test with a joystick.

Can you merge last version of master so it can be updated? And can you give a guide on how to use the joystick? Can I use the keyboard instead?

Offboard attitude control may need some small additions like converting the quaternion.

I just need to set the yaw rate, so the mav can turn left or right. Is it already ready to receive this? I'll be using a velocity controller that controls linear x,y and z vel (with this one controlling the altitude) and that controls angular velocities of yaw. They are sent using cmd_vel topic on ROS.

Re your error: are you sending offboard setpoints? Without a valid offboard setpoint the system will not switch to offboard mode.

No I'm not sending yet. I was hoping that switching to OFFBOARD mode will issue position hold and then wait for offboard commands. Isn't it better that way?

So imagine that I'm already in POSCTL. If I switch to OFFBOARD do I have to have a offboard loop that keeps the device in position hold through sending setpoints? That seems to be painless to get and not easy to me to get working :S

[kylc]

My understanding is that if an offboard signal has not been received more recently than the OFFBOARD_TIMEOUT defined in commander.cpp then the state transition to MAIN_STATE_OFFBOARD will be denied. If the signal is lost when in offboard mode then the controller will revert back to POSCTL mode, unless the RC signal is lost too.

You'll want to start looking here: https://github.com/PX4/Firmware/blob/master/src/modules/commander/state_machine_helper.cpp#L605

I have some example code that translates the ROS cmd_vel topic to MAVLink offboard messages here: https://github.com/osurdml/offboard_comm.

[TSC21]

@kylc Thanks! So since OFFBOARD_TIMEOUT 500000, which means 0.5 sec, I have to send a signal (which, given the current time gap, as to be a stream instead of a single pkt) which is constantly received by the FCU and, during that time, I can switch to OFFBOARD mode. Is that correct?

By the way, I looked into your code and certainly you must be aware that current Mavlink sub-rev4 doesn't support already SET_QUAD_ROLL_PITCH_YAW_THRUST pkt, right? Right now, and given the offboard2_externalsetpointmessages branch, you should use SET_POSITION_TARGET_LOCAL_NED for controlling linear velocities (in your case), and SET_ATTITUDE_TARGET for rpy rates or quaternions. At least, if you don't want to advance to current implementation.

My current code translates directly cmd_vel to linear vx, vy, vz velocities, which are sent by SET_POSITION_TARGET_LOCAL_NED, and to angular rates of rpy, which are sent by SET_ATTITUDE_TARGET. In this last case, I just control yaw rate, but I have doubts regarding this one: If I want to turn left or turn right, do I send negative rate and positive rate respectively? @thomasgubler can you confirm this? Thanks!

[TSC21]

@thomasgubler one more thing. Regarding the joystick. I already connected a joystick I have to the QGS. The following screen displays the joystick config:

Can you please explain how this works? First, I can just use a analog stick and the values that it inputs are only -100 or +100. I selected the position type of control and can only still choose to control rpyt. What recommendation do you give to setup the controller? Thanks in advance!

[thomasgubler]

The text in the drop downs does not depend on the mode. Maybe that is a bit confusing and we need to change this. Just use the dropdowns to map the correct axis to rpyt. Then the position mapping is: x: pitch stick, y: roll stick, z: thrust stick

First, I can just use a analog stick and the values that it inputs are only -100 or +100.

Usually you get all values from -100 to 100 for the 4 axes and some of the buttons. You want these for control.

[TSC21]

Thanks @thomasgubler!

Usually you get all values from -100 to 100 for the 4 axes and some of the buttons. You want these for control.

I found out some options on the joystick that allows to config analog stick and define macro control (all values from -100 to +100) to both the analog sticks (after calibration). Why do we need to have all values? What's the mapping being done for position? (i.e. +100 for pitch is like +1 meter in x?) And, can I control also yaw with the joystick in positioncontrol?

Is it testable right away? Do you recommend activate OFFBOARD mode before taking-off, and do take-off with the joystick?

My current code translates directly cmd_vel to linear vx, vy, vz velocities, which are sent by SET_POSITION_TARGET_LOCAL_NED, and to angular rates of rpy, which are sent by SET_ATTITUDE_TARGET. In this last case, I just control yaw rate, but I have doubts regarding this one: If I want to turn left or turn right, do I send negative rate and positive rate respectively? Cause cmd_velsends values between -1 and 1 to control if it is left or right.

Can you confirm this please? Thanks!

[thomasgubler]

this stuff is higly WIP, the scaling is not fix yet: https://github.com/mavlink/qgroundcontrol/blob/joystickinput_settargets/src/uas/UAS.cc#L2788 you can try to find something decent.

By adding qDebug() << variable; there in the code you can quickly test if your scaling makes sense.

You can for sure test this. Best is probably to test in HIL or in while holding the quad in your hand (without props). While it is technically possible, I I would not switch in the air atm. :)

The mixing of position and attitude setpoints is something we still have to look at in detail. I would recommend to first test position only. Once that works, it's a very small step to add yaw.

[TSC21]

this stuff is higly WIP, the scaling is not fix yet: https://github.com/mavlink/qgroundcontrol/blob/joystickinput_settargets/src/uas/UAS.cc#L2788 you can try to find something decent.

Probably the current scaling is not the best. Probably we should define px or py updates to like: if +100, then +1m to px; -1m when -100. Same to py. That will assure a safer control. What do you think?

This is not my current priority as I also want to test control using ROS cmd_vel. I just want to be sure that external setpoints work and how they work. And my current doubt is: how do I setup yaw with the current SET_ATTITUDE_TARGET. As I asked, if I want to turn left or right, do I have to control both quaternion and rates, or do I just have to send negative or positive rates? This last one seems the most adequate though.

Anyway, I will test this with the quad on my hands. Don't know how to use HIL (if you can teach me how it could be good also).

Thanks once again!

[thomasgubler]

And my current doubt is: how do I setup yaw with the current SET_ATTITUDE_TARGET. As I asked, if I want to turn left or right, do I have to control both quaternion and rates, or do I just have to send negative or positive rates? This last one seems the most adequate though.

As said, attitude will not work yet. The conversion is missing as the attitude controller does not understand quaternions. We can certainly try to support both attitude and attitude with rates. Of course pure attitude will be simpler.

[TSC21]

We can certainly try to support both attitude and attitude with rates.

In my case, attitude with rates will be ideal since my ROS controller uses cmd_vel as a Twist msg that controls angular vel for z, which means, controlling the rate of yaw to left or right depending if it sends negative or positive values (it's limited to 1m/s to both sides, for security and stability purposes).

So if angular.z between -1 and 0, rotate yaw left with the correspondent rate , else if angular.z between 0 and +1, rotate yaw right with the correspondent rate. Can that support be added in the next few days? I will really need it for my project :)

Note: the Mavlink msgs will be sent, in my case, by this two mavros plugins: setpoint_velocity for position and setpoint_attitude for attitude. As you see, in this last one, there's a possibility of using. or control of the quaternion, or control of rates. I'll be using the rates, if possible.

[TSC21]

@LorenzMeier I would like to open a docs page regarding OFFBOARD control. Can you please open one in a site from PX4 AutoPilot so I can add some starting docs regarding it's use and implementation?

@thomasgubler if you don't mind, I'm going to add info based on your offboard2_externalsetpointmessages implementation :)

[LorenzMeier]

@TSC21 Please edit the pixhawk.org wiki. The research project website is for the ETH project only.

[TSC21]

Oh sorry, didn't check that one! :) Can you get one page open there then please? Choose what you think is the best location on it.

[TSC21]

@thomasgubler I'm using the joystick branch of QGC to send setpoints through the joystick. Already calibrated the joystick and it's functioning well. But, being armed or disarmed, my FCU always sends "Reject OFFBOARD" even though I have the joystick connected and even trying to send setpoints by moving the analog sticks. No luck!

What am I supposed to do to get to OFFBOARD mode? This is also delaying me regarding the ROS implementation I have. Sending MAV_CMD_NAV_GUIDED_ENABLE or set the mode through MAV_CMD_DO_SET_MODE doesn't work (this last one doesn't work just to OFFBOARD mode but works for the rest of the modes). For the first I receive command unsupported: 92 and for the second I receive command temporarily rejected: 176.

Also have a switch on my RC to change to OFFBOARD, and for that one I receive the Reject OFFBOARD message. It's not clear what needs to be done so that the FCU changes to OFFBOARD mode.

If you please can take some time to clarify this I would be grateful. Thank you in advance!

(note: can you please also merge the last master to the joystick branch also? thanks)

[andre-nguyen]

If your RC is in offboard mode and you are being rejected it either means you timed out or you haven't started sending setpoints yet. (That's my guess at least)

[TSC21]

@andre-nguyen I suppose it can be one of the two or both. But how do I setup QGC on the branch joystickinput_settargets so to send the setpoints I think it's the main question, cause I already enabled the joystick and calibrated it (In File>Joystick Configuration).

Also, how do you recommend to do this on the ROS side? There's already a implementation to send MAV_CMD_NAV_GUIDED_ENABLE and MAV_CMD_DO_SET_MODE. First one doesn't work cause it's not handled in the firwmare side. The second one is "temporarily" rejected. Anyway, I suppose that first I have to send one setpoint msg (or a stream of them), to the FCU and then activate OFFBOARD mode so it can accept the setpoints, right?

[TSC21]

The other thing I can think off is given the last messages updates, that the current implementation is not receiving/detecting the setpoint msgs.

[thomasgubler]

How do you get the "Reject OFFBOARD" messages? what do you do before you get these?

I use MAV_CMD_NAV_GUIDED_ENABLE all the time. The implementation in the firmware is here: https://github.com/PX4/Firmware/pull/1151/files#diff-1d51a813dcb26f46616f71f28aacc70dR613

[TSC21]

How do you get the "Reject OFFBOARD" messages? what do you do before you get these?

I start QGC, enable and calibrate joystick and switch the RC switch to get to OFFBOARD.

[TSC21]

Note: Let me just be sure of one thing. I'll be back in 5 minutes.

[thomasgubler]

ok can you try with the mavlink messages only, without the RC?

[TSC21]

Yes I'm updating the firmware again and I will check that. I suspect I was using the offboard branch but updated to use master instead of the offboard code. Am flashing the firmware again.

Update: when I have something I will report. Have to leave my laptop for now.

[TSC21]

OK success!

(MAV 001:50) [cmd] main state: OFFBOARD 
(MAV 001:50) [cmd] nav state: OFFBOARD 

The problem was what I stated above: wrong firmware flashed -.- Thanks anyway! I will do some tests tomorrow and see what I can get with sending velocities and positions through ROS.

[TSC21]

@thomasgubler do you recommend any HIL simulator to test this branch?

[thomasgubler]

you can test with qgc/flightgear. Make sure that flightgear runs at a high framerate. Also you will have to use low control gains the whole control performance will be pretty bad (slow but stable) but you can use it to check that your code works etc. Also jmavsim is an alternative which I never really used though.

[TSC21]

Also you will have to use low control gains

Can you please describe what parameters should I change? Thanks!

[thomasgubler]

Literally all attitude and position control gains. I can give you tomorrow a set which I think worked when I last time used the standard px4 controller in hil.

[TSC21]

Great :) By the way, as I ask you above, what has to be done regarding the velocity setpoint handling so it can issue velocity control on the FCU, since you said it won't work atm?

Update: @thomasgubler Ok I tested the joystick with the real quad (no propps attached). It works ok with the Attitude controller, but when I switch to Position or Force I get "Reject OFFBOARD". Is there an explanation to it?

Thanks in advance!

Update: solved the joystick mode with this PR.

[TSC21]

Regarding the velocity sp: Checking https://github.com/PX4/Firmware/blob/9bda573151ae1b5fa87686ee58596ea14e052941/src/modules/mc_pos_control/mc_pos_control_main.cpp#L618, does this implementation allows the correct velocity control, or does it need some tweaking?

[ziyangli]

Is there a doc for using offboard mode now?

[dreamkeep]

Hi @TSC21 , what is the firmare version you used for px4 offboard test?

[TSC21]

@dreamkeep this thread is kinda hold but right now you can use current master to do offboard control. I'm closing this since it's already documented in https://pixhawk.org/dev/offboard_control and https://pixhawk.org/dev/offboard_control/testing.