Extending mavros support to IRIS+

[pmukherj]

Hey @vooon and @mhkabir ! I'm just getting back into autopilots and find the mavros stack to be MOST complete. Great job, esp with the use of the plugin architecture!

I have an IRIS+ (Pixhawk with the native APM firmware onboard). I know that for it to work with mavros I have two options: a) Switch the IRIS+ to use the PX4 stack. How hard would this be? Are there any guides for this? Would all the UX features (LED messaging, sound tones) still be available through PX4? b) Extend mavros support to the APM stack. I know you guys (understandably) stopped supporting this. Do you think it is a significant task to extend support back to the APM stack? I know the mavlink headers have diverged? Are there any other significant differences?

Currently, when I try to use mavros with the IRIS+, all the plugins, heartbeats, parameters and firmware versions come up fine, but no actual data is seen (no IMU data, no RC data etc.). None of the topics are publishing (similar to this old issue: https://github.com/mavlink/mavros/issues/165). Here's a ROS log (with DEBUG type messages) of the errors. https://www.dropbox.com/s/p4m9stn78imxeaj/mavros_log.csv?dl=0

Thanks for all your work and if I get this up and running I look forward to contributing back to this project!

P.S: Feel free to label this just a question!

[LorenzMeier]

@pmukherj The led messaging and sound tones are actually provided by PX4 and just reused by APM. You can set up the Iris with QGroundControl, which will require you to maybe learn slightly different flight mode names, but otherwise you can expect similar functionality. The MAVLink headers haven't diverged, but the APM usage of MAVLink lags the general protocol development usually a bit as they have to watch their deployed user base and compatibility carefully.

[mhkabir]

Hi @pmukherj We still have support for APM with regards to what is already implemented in the APM source. As Lorenz said, they lag behind general protocol development, so many features aren't implemented like external estimation, etc. It looks like you're running a slightly older mavros version, so you might want to pull the latest master and compile. Can you get us a rosbag to look at? What launchfile did you use? Did you echo the IMU topic to check?

rostopic echo /mavros/imu/data

Kabir

[vooon]

Hi @pmukherj,

APM message set is supported, and will be supported because i have training bixler with APM :) But PX4 have richier message set for robotic, e.g. setpoints.

I looked at the log, seems that you used px4 launch instead of apm ones.

[pmukherj]

Thanks guys! this is great information. I'll add it to the wiki so you guys don't keep getting these questions! @vooon Good catch. Can't believe I missed that. I tried apm2.launch with slightly better results, I occasionally get battery data on the topic (/mavros/battery), but still no IMU data. Here is a new log (https://www.dropbox.com/s/q6asu9o92unmnwn/apm2_log.csv?dl=0). It keeps complaining about 'Cached parameter is invalid'? The firmware has been flashed by APM Planner in MAC. I wonder if I should try Mission Planner in windows, though it really should not make a difference. Also, I'm wondering if this data stream is even allowed over the USB port? Do I have to use the Telemetry port on the pixhawk for this data?

@mhkabir I did echo that topic with no luck and I believe when the plugins start getting data they show an "enabled" message on the console. I'm on the latest master branch, I believe.

Given what you guys have said, I will most likely switch to px4, but I'm just trying to get to the bottom of why this wouldn't work with the 3DR IRIS out of the box. I probably missed something dumb.

[vooon]

@pmukherj i don't see reports about rx ATTITUDE msgs. Try to enable bridge and connect GCS (APM Planner 2) via IP (UDP/TCP).

Also you should try regular telemetry ports (UART).

[pmukherj]

Yes, This is for a microcomputer mounted next to the pixhawk, so its not really going through any IP bridges. Its currently a direct USB connection between the computer and pixhawk. Do you suggest I test it with an IP bridge first? You're right, I should probably test it with the UART ports, its odd that this block on the USB port (the fact that IMU data/RC data cannot be streamed through USB) is not mentioned anywhere in the pixhawk documentation.

[vooon]

I don't used APM on Pixhawk, only short test when it arrives... (and i seen all data via USB).

Also better connect your OBC (On Board Computer) to FCU via UART. Because i seen some related errors in google groups.

In test bridge i mean: FCU -USB-or-UART-> mavros -IP-bridge-> GCS (APM Planner 2). This chain will confirm that IMU data not sent by FCU and it's not mavros bug.

[mhkabir]

I think I've seen this issue on my older systems. As far as I remember, APM doesn't stream all messages without getting stream rate requests. Mission Planner automatically does this on first connect. You should try doing a UDP proxy to a GCS from the your onboard computer. GCS should explicitly request streams and you should see data coming in. Another very useful debug method is to connect the autopilot to Qgroundcontrol and check the incoming streams in "MAVLink Inspector" On 19 Dec 2014 22:29, "Prasenjit Mukherjee" notifications@github.com wrote:

Yes, This is for a microcomputer mounted next to the pixhawk, so its not really going through any IP bridges. Its currently a direct USB connection between the computer and pixhawk. Do you suggest I test it with an IP bridge first? You're right, I should probably test it with the UART ports, its odd that this block on the USB port (the fact that IMU data/RC data cannot be streamed through USB) is not mentioned anywhere in the pixhawk documentation.

— Reply to this email directly or view it on GitHub https://github.com/mavlink/mavros/issues/179#issuecomment-67665047.

[vooon]

@mhkabir i got IMU data without configuring streams (it default around ~2 Hz).

@pmukherj see docs for set_stream_rate srv and gcs_url param.

[pmukherj]

I see that's interesting insight. Is there anyway to explicitly ask for a stream rate at connection initialization? Should that be baked into the plugin when connecting to an APM?

I did try to connect to it with qgroundcontrol. Again, the connection initialization goes through fine, but I still see no data i.e. there is clearly no IMU data (visualization does not tilt with the autopilot). When I switch the firmware to px4, everything works fine. Also, when I connect to the Pixhawk directly via USB using the APM gui (APM Planner) and APM firmrware, the IMU data comes in fine. So maybe it is just the set_stream_rate issue that APM firmware requires but PX4 doesn't. I'll try that next.

[tonybaltovski]

I use an APM2.6 with ArduCopter V3.2. I get IMU data about 8 Hz and I am able to see the orientation in apmplanner2 on Ubuntu 14.04. I used rosrun mavsys rate --all 20 and it did increase the rate but not to the full amount. I was having issues with the PX4 but I didn't have chance to tackle them yet but I will hopefully soon.

[pmukherj]

Hey @tonybaltovski, that seems to work for me as well. I asked for even higher frequencies (30-40?), and it went upto 25Hz and capped out. It also gives out a warning ([ WARN]: TM: Wrong FCU time.), everytime I ask for a different frequency.

I'm wondering if that's just a function of the baud rate. If I up the baud rate to 921600, would I be able to get faster rates? Or maybe the UART's will allow faster rates? Hmm.

Either way, it seems with the APM, we should bake in an explicit call to get different frequencies within the plugin initialization.

[mhkabir]

Hi @pmukherj The problem here being, as I said, you need to explicitly request rates. APM isn't made for such research-driven purposes, and I think you might need to look into the code to remove the cap. 25Hz is indeed rate-limit as MP doesn't allow you to set higher than that either. I think they limit it further on UARTs

The warning "Wrong FCU Time" has got nothing to do with the mavsys rate call. It is from the plugin Timesync (TM) and means it that your Pixhawk has no GPS lock and a proper UTC time source.

Baud rate is ignored on USB. If you do switch to PX4 stack, we recommend UART too, and maximum rates are a function of baudrate. You can set stream rates in a file on your SD card and UART should stream data from boot.

@vooon Let me find a board and check if this is reproducible. We can script it and run from the APM launchfile ;)

[pmukherj]

Amazing! I'm convinced, I started switching everything over to the px4 stack. Firmware reflashed, everything calibrated. I'll take px4 related questions to the relevant forums. Till then I'm going to close this question.