Offboard mode queries.

[tanmayshankar]

Hello everyone,

I am running the Pixhawk with an Odroid XU3 on my Hexcopter, I've got Ubuntu 12.04 / ROS Hydro set up on it. mavros, mavros-extras installed as binaries. I've been trying to get Offboard mode and setpoint position control to work for a while now, with no success.

I create a custom C++ node that publishes geometry_msgs::PoseStamped messages onto several topics. I was unsure of what the topic name was for ROS Hydro, so I published it over "/mavros/setpoint_position/local", "/mavros/setpoint_position/local_position", "/mavros/setpoint/local_position". The rate of publishing is around 3 Hz.

Here are the steps I followed -

1. Launch px4.launch, with the baud rate and device ID adjusted to ttyUSB0 and 460800 instead of 57600, which works for me.
2. Run the above C++ node to publish setpoints.
3. a) Arm the Hexcopter using an RC in manual mode.
   b) Flip the switches on the RC corresponding to offboard, and position control mode.

This still doesn't work, the Hexcopter hovers in the same place when I tried this. I also tried running
rosrun mavros mavsys mode -c OFFBOARD, instead of the RC, but it times out.
I also tried running the setpoint_demo.py executable, with the same result.

Any ideas on what could be going wrong? (Details below).
My diagnostics mentions APM somewhere, and I2C errors, but I'm not sure what that means.

My mavros says - Flight mode: POSCTL
Reset pos sp : (3,-6), (or something similar).

On echoing /mavros/state, it says ARMED :True, GUIDED: True.

/diagnostics is as follows:

header: 
  seq: 264
  stamp: 
    secs: 1437504141
    nsecs: 573507835
  frame_id: ''
status: 
  - 
    level: 0
    name: mavros: FCU connection
    message: connected
    hardware_id: Mavlink
    values: 
      - 
        key: Received packets:
        value: 9446
      - 
        key: Dropped packets:
        value: 0
      - 
        key: Buffer overruns:
        value: 0
      - 
        key: Parse errors:
        value: 0
      - 
        key: Rx sequence number:
        value: 58
      - 
        key: Tx sequence number:
        value: 0
  - 
    level: 0
    name: mavros: GPS
    message: 3D fix
    hardware_id: Mavlink
    values: 
      - 
        key: Satellites visible
        value: 8
      - 
        key: Fix type
        value: 3
      - 
        key: EPH (m)
        value: 2.40
      - 
        key: EPV (m)
        value: 2.47
  - 
    level: 0
    name: mavros: Heartbeat
    message: Normal
    hardware_id: Mavlink
    values: 
      - 
        key: Events in window
        value: 10
      - 
        key: Events since startup
        value: 258
      - 
        key: Duration of window (s)
        value: 10.009986
      - 
        key: Actual frequency (Hz)
        value: 0.999002
      - 
        key: MAV Type
        value: 13
      - 
        key: Autopilot type
        value: 12
      - 
        key: Autopilot base mode
        value: 0xD9
      - 
        key: Autopilot custom mode
        value: 0x00030000
      - 
        key: Autopilot system status
        value: 4
  - 
    level: 0
    name: mavros: System
    message: Normal
    hardware_id: Mavlink
    values: 
      - 
        key: Sensor present
        value: 0x00000000
      - 
        key: Sensor enabled
        value: 0x00000000
      - 
        key: Sensor helth
        value: 0x00000000
      - 
        key: CPU Load (%)
        value: 30.3
      - 
        key: Drop rate (%)
        value: 0.0
      - 
        key: Errors comm
        value: 0
      - 
        key: Errors count #1
        value: 0
      - 
        key: Errors count #2
        value: 0
      - 
        key: Errors count #3
        value: 0
      - 
        key: Errors count #4
        value: 0
  - 
    level: 0
    name: mavros: Battery
    message: Normal
    hardware_id: Mavlink
    values: 
      - 
        key: Voltage
        value: 15.73
      - 
        key: Current
        value: 0.0
      - 
        key: Remaining
        value: 73.0
  - 
    level: 2
    name: mavros: APM Memory
    message: No data
    hardware_id: Mavlink
    values: 
      - 
        key: Free memory (B)
        value: -1
      - 
        key: Heap top
        value: 0x0000
  - 
    level: 2
    name: mavros: APM Hardware
    message: No data
    hardware_id: Mavlink
    values: 
      - 
        key: Core voltage
        value: -1.000000
      - 
        key: I2C errors
        value: 0

---

[LorenzMeier]

When you launch, are you setting the autopilot ID to 1 and the component ID to 1 as well? You need this with current master.

@aperture-laboratories Could you also report your success / status here once you iterated on your current state?

[LorenzMeier]

@TSC21 @vooon Let us know if you have further feedback.

[TSC21]

I've got Ubuntu 12.04 / ROS Hydro set up on it

Well this could answer to a lot of things. @tanmayshankar what branch of mavros are you using right now? master or hydro-devel?

[TSC21]

hydro-devel: https://github.com/mavlink/mavros/blob/hydro-devel/mavros/launch/px4.launch#L8 - so it has to be changed to 1.
master: https://github.com/mavlink/mavros/blob/master/mavros/launch/px4.launch#L8 - it's right

[tanmayshankar]

Hi TSC21 and Lorenz,

The Odroid is running a binary of mavros, which apparently is Hydro according to your comment. (default value is 50 in the launch file). I am going to check after setting it to 1, and get back to you in a few minutes.

Thanks for the quick responses, I really appreciate it!

[tanmayshankar]

Is it a problem that my diagnostics is shouting out APM?

[TSC21]

I create a custom C++ node that publishes geometry_msgs::PoseStamped messages onto several topics. I was unsure of what the topic name was for ROS Hydro, so I published it over "/mavros/setpoint_position/local", "/mavros/setpoint_position/local_position", "/mavros/setpoint/local_position". The rate of publishing is around 3 Hz.

Regarding this: if you have doubts, you can always ask. For hydro-devel you have to publish to /mavros/setpoint/local_position.

[TSC21]

Is it a problem that my diagnostics is shouting out APM?

Well I can't really tell... but I think it depends. What firmware are you using? APM or native PX4?

[TSC21]

The Odroid is running a binary of mavros, which apparently is Hydro according to your comment.

What branch have you cloned to your Odroid? Having component ID of 50 doesn't mean it's the hydro version, can be that it's an older master.

[tanmayshankar]

I'm using native PX4, I upgraded it from the stable release using QGC a while ago (just to be sure I wasn't running into issues because of old firmware).

It must have been Hydro - I installed it as apt-get install ros-hydro-mavros and mavros-extras.

Thanks for clarifying the topic name. When I looked up the source, I was a little confused due to the namespace resolution and reading up on different issues, where the topic renaming was done.

[TSC21]

So is it working now?

[tanmayshankar]

Hmm. Now when I try it, it says -

FCU: Flight mode: MANUAL
FCU: Flight mode: ALTCTL
FCU: [mpc] reset alt sp: 1
FCU: REJECT POSCTL

Earlier, it used to say it is in POSCTL mode, and even though I switched to OFFBOARD, it did not "reject offboard". The Hex was still responsive to the RC controls though, which means it wasn't in OFFBOARD.

[tanmayshankar]

Right now, it is not in offboard. I tried switching to POSCTL through the RC, after publishing the setpoints. It goes into ALTCTL, and is still responsive to my RC controls.

[LorenzMeier]

If position control is rejected its most likely because you have no GPS lock. No position hold without GPS.

[TSC21]

Well for rejecting POSCTL means that there's no valid position lock... But you can switch to OFFBOARD without having to switch through POSCTL. Is your node sending a continuos stream of setpoints? Can you try setpoint_demo.py again?

[TSC21]

I tried switching to POSCTL through the RC, after publishing the setpoints.

Well this doesn't make sense to do cause you just have to publish setpoints if you want to switch to OFFBOARD mode.

[TSC21]

And just a recommendation: I totally recommend you to upgrade your Ubuntu release to 14.04 or above (you just have to check for the custom images that exists on the odroid forum) and use ROS Indigo/Jade, cause from hydro-devel to current master it's a gigantic leap. We have already finished our support for Hydro cause it is entering a EOL state.

[tanmayshankar]

I do have a GPS lock, the node that publishes setpoints subscribes to that to generate the setpoints.
I'm sitting outside my building for that. :D

@TSC21 Sorry, I meant offboard.

I am going to try setpoint_demo, and another version of the setpoint publisher I wrote. I'll be back with updates in a few minutes.

[tanmayshankar]

Hi,

It is back to where I started from. I tried running the setpoint_demo,
rosrun mavros mavsys mode -c OFFBOARD returns timed out.

There is no explicit message of Reject Offboard anywhere, but the copter is still responsive.

Also, I will probably switch to Indigo soon, I just need to port some other things I have developed on that.

[TSC21]

Strange. Do you have gitter account so we can talk?

[tanmayshankar]

I can create one, in about 20-25 minutes. Is that okay?

[tanmayshankar]

I have a feeling I am making a fundamental error somewhere.

[TSC21]

Well sure. Also (off-topic), I'm pretty interested on what you are trying to achieve (had the chance to take a look that you have forked RTAB-Map).

[tanmayshankar]

Sure! I'll be back in a while, we can continue this then. Thanks a lot again for all the help so far!

[TSC21]

Contact me on gitter when you are able to. We have to do a step-by-step debug on this.

[bryanmonti]

@LorenzMeier Status is good. I was able to get into offboard mode once I changed component_id to 1 instead of 50. This was under tgt_component in px4.launch.

You should be able to see it rejecting offboard in the console/terminal that you launched roslaunch (which should also give you a series of tones). If not, then there's something else wrong.

[vooon]

Mavros master branch still buildable in Hydro, because travis still uses 12.04. So at least try to build master yourself. Compilling on rpi2 tooks about 20 minuts, XU should be faster.

[tanmayshankar]

Hi Vladimir, I will try compiling master from source.
In the meantime, does anyone have (successful) outputs of offboard control, from /diagnostics, /mavros/state and the mavros launch? I want to see what the differences are.

I will post the launch files / nodes I am using soon, if there are any errors we can stop with those.

Also, I have a switch on my RC corresponding to RC mode. When I flip it on (trying to enable offboard), it does not give me any message, however, when I switch it back off (what I think is disabling offboard), it says reject offboard.

I have tried running offboard in both situations, in case I had my switches mapped the wrong way, neither works.

[aerialhedgehog]

Hey Tanmay, double check what we set on the etc/extras.txt, i think you might be running mavlink passthrough or a custom mavlink app? maybe that's causing issues. also, is the system id important here? i think the frame you're running is something other than 1.

[tanmayshankar]

Hey Trent,

Thanks for the quick response.
This could be the issue - I hadn't thought of the extras.txt. Here are the current contents of the file -

#Telem 1 for Testing
#mavlink stop-all
#mavlink start -d /dev/ttyS1 -p

#Telem 2
mavlink start -d /dev/ttyS2 -m custom -f
mavlink stream -d /dev/ttyS2 -s LOCAL_POSITION_NED -r 20
usleep 100000

#ODroid
mavlink start -d /dev/ttyS6 -r 20000 -b 460800 -p

I am running the UART over the /dev/ttyUSB0 device, at a 460800 baud rate (like the CAS code).
I do have a custom (ROS) node on the Odroid that is trying to publish the required setpoint topics for offboard control.

Any idea what I should be adding / changing to the extras.txt file? Thanks!

[tanmayshankar]

I think it would be something like
mavlink start -m custom -d /dev/ttyUSB0 -b460800 -x
usleep 100000

(I am really not sure, just guessing).

[vooon]

What port on pixhawk you use for odroid?
I think better to use TELEM2, as it don't require special startup in extras.txt (look SYS_COMPANION).

Your extras.txt seems not correct.

[tanmayshankar]

Hi Vladimir,

I think the extras.txt had been set up according to https://pixhawk.org/dev/mavlink_message_passthrough .

We are using the serial port (Serial 4) on the pixhawk, wired to a USB on the Odroid, in accordance with https://pixhawk.org/dev/companion_link .

The telem2 port is used up by telemetry radio for communication with the ground station, although I think this could be changed.

@aerialhedgehog Does the above sound about right? Also, do you know if switching this setup makes sense in this case?

[vooon]

And TELEM1 too?

[tanmayshankar]

I will try changing this set up (putting the Odroid on Telem2) and update the status.
Do I still need to include
#Telem 2
mavlink start -d /dev/ttyS2 -m custom -f
mavlink stream -d /dev/ttyS2 -s LOCAL_POSITION_NED -r 20
usleep 100000

in my extras.txt?
Also, to send position setpoints, do I need to be stating something link
mavlink stream -d /dev/ttyS2 -s LOCAL_NED_POSITION_SETPOINT_EXTERNAL -r 20 ?

[vooon]

On TELEM2 only SYS_COMPANION setup required. extras.txt not needed, if you don't need RC channels.
If it is needed here example: https://github.com/vooon/rarog/blob/master/rarog_configs/pixhawk/extras.txt

[tanmayshankar]

Hi Vladimir,

I changed the setup such that the Odroid connects to the Pixhawk using the Telem 2 port,
then modified SYS_COMP to 921600, and checked out the system_id that was loaded on the pixhawk. It was set to 3 (since we were running more than 1 vehicle).
I changed the px4.launch file accordingly, and commented out the TELEM2 and Odroid lines from my /etc/extras.txt file.

It finally displayed "Offboard mode" with my custom C++ code. I am yet to flight test it (hopefully I can in a few hours).

I will modify my txt according to your example, and then get back to you with the status.

But thanks so much for all the help, I am really glad to see it accepting offboard, if not yet flying.

[tanmayshankar]

Much thanks to Lorenz, Trent, Nuno, Vladimir and Bryan!
I will get back with the results of my flight test.

[aerialhedgehog]

Glad it worked! Sounds like Telem2 or the 921600 baud is hardcoded
somewhere in the link with mavros?

On Wed, Jul 22, 2015 at 2:05 PM, tanmayshankar notifications@github.com
wrote:

Hi Vladimir,

I changed the setup such that the Odroid connects to the Pixhawk using the
Telem 2 port,
then modified SYS_COMP to 921600, and checked out the system_id that was
loaded on the pixhawk. It was set to 3 (since we were running more than 1
vehicle).
I changed the px4.launch file accordingly, and commented out the TELEM2
and Odroid lines from my /etc/extras.txt file.

It finally displayed "Offboard mode" with my custom C++ code. I am yet to
flight test it (hopefully I can in a few hours).

I will modify my txt according to your example, and then get back to you
with the status.

But thanks so much for all the help, I am really glad to see it accepting
offboard, if not yet flying.

—
Reply to this email directly or view it on GitHub
#347 (comment).

• Trent Lukaczyk
  Stanford University Engineering 2015
  Cornell University Engineering 2010
  trent.lukaczyk@stanford.edu

[vooon]

https://github.com/PX4/Firmware/blob/master/ROMFS/px4fmu_common/init.d/rcS#L487-L503

[TSC21]

Great :) let's see that thing fly eheh

[tanmayshankar]

Hi guys.

I reverted back to the serial port, with a baud rate of 460800, and I tried flight testing the entire system yesterday. It rejected the offboard mode, unfortunately.
I think there is an issue with how fast the commands are send via my topic, and the wifi connection might have been slower outside than the one I was using to test on the ground.
I am going to try the following -
a) Increasing baud rate to 921600 for the serial port as well.
b) Setting up my "flying wifi conditions (a wifi hotspot from a phone). " and testing it out.
c) Maybe increasing the publishing rate of my ROS node.

If all of this fails, I will revert to telem and flight test.

[tanmayshankar]

I changed the baud rate on the serial port, and flight tested the thing.
Interestingly enough, it was able to navigate to a particular (fixed) position setpoint.
The motion started off jerkily, (change in altitude and yaw), but it stabilized at the destination.

When I tried to dynamically change the setpoint value based on a subscription from another node, it rejected offboard. The other node was running on another Hexcopter at a slower baud rate. I am pretty sure this has something to do with the speed of the topic being published.

I plan to change that tomorrow and flight test it again.

[tanmayshankar]

I think it's now confirmed that it is best to use a 921600 baud rate on the serial port.

I had 2 vehicles up in the air, both with Odroids running ROS, connected via UART /Serial port at a 921600 baud rate. I dynamically changed the setpoint value for Vehicle A based on the local position of vehicle B, and it worked pretty well. They were both running along with a ground station with ROS, connected through a wifi hotspot.

[killerlayup]

@tanmayshankar
have you solve this issue you posted?

[tanmayshankar]

Hi @killerlayup ,

Yes, I had solved it thanks to the help I got above.
I had also created a code base for running UAV's autonomously using mavros.
You can see it here.

https://github.com/tanmayshankar/hexcopter_autonomy

[killerlayup]

hi @tanmayshankar
do you have free time? if you can talk with me on gitter.im, that will be great!

[tanmayshankar]

Sure, I just messaged you.