Hi all,

I'm trying to operate the Arducopter via MAVlink from my ROS node indoors, and one of the stumbling blocks is the lack of fused IMU velocity updates in the GLOBAL_POSITION_INT packet. I only get altitude values in this packet and 0s for velocities, perhaps since the ArduCopter expects to have some initial GPS data?

If I were to implement sending my own LOCAL_POSITION_NED packet in the ArduCopter source, what internal data member should I use? g_gps, which is already used in the global_position packet will clearly not help. Should I then just resort to integrating the raw accelerometer values?

I want to exploit any fused velocity calculations onboard, especially after attaching an optical sensor. Since I can already get fused angular positions and velocities, why can't I get similar velocities without the GPS?

Or am I just doing something wrong?


Views: 3281

Replies to This Discussion


     Sounds like you're up to some pretty complex work.  We've been talking in the dev team about fusing the optical flow sensor values into the inertial navigation solution so if you can do it somehow, we'd love to pull it into trunk.

     Really I think you want to extend the AP_InertialNav library and create a new correct_with_optflow() method.

     By the way, the accelerometer based velocity can be pulled from the library with these calls


     but as you say, they currently rely on a gps...or rather they won't start providing values until the inertial_nav's home lat & lon is set.  You could set that to some arbitrary value though.

     Good luck.

Thanks for the prompt reply, Randy!
Hm, I might not have the time to do the optical flow fusion atm, but your suggestion to pull the accelerometer based velocity is really helpful. I'll try to get that working soon.
Just another bother - I take it that I only need to make a couple of calls to set_current_position() in the userhook_init() method, or will it be more complicated than that? (Faking gps calls/setting the gps_last_updated time in the update loop, etc)
Thanks, again!


    Calling the set_current_position will start it all working but if you look in the inertial nav library for _gps_last_update you'll see that it has a 3second timeout.  So you need to remove that or provide an alternative or the position_ok() will go to false and none of the navigation routines, etc will work.

Yup, just what I had thought. Thanks for confirming that! :)

It's nice to see that I'm not the only one who might need to spoof GPS data. On the one hand, it's annoying that you need a good GPS datum for the nav calculations. But on the other hand, this means it's possible to integrate flying by IR beacons on a vision system by turning the beacon data into a fake GPS location...

Hi, I'm having a somewhat similiar problem.  I have a ROS node setup and I think it's working fine.  I'm attempting to control the throttle via ROS.  I can see that the APM is Armed (by viewing the ROS topic /state) and I believe my code on the APM is executing properly (I can watch it execute by sending gcs_send_text_p messages to my ROS node).  Also, I am using the MAVLINK_MSG_ID_SET_ROLL_PITCH_YAW_THRUST command in the GCS_Mavlink and again I believe this is working correctly.  I However, I can't get any pwm signal to show up by using the set_throttle_out().  I tried using set_throttle_out(1.0,false),set_throttle_out(100.0,false), set_throttle_out(1000,false) etc and I can't get any change.  

I am able to use the rc_override mavlink command successfully.  If anyone has any tips let me know.


     I'm guess a bit but I think you will need to get g.rc_3.control_in to be > 0.  If you don't do that I think it'll probably overwrite anything that you directly send using set_throttle_out...I think.

     the 1st parameter of set_throttle_out is a number from 0 ~ 1000 representing the throttle.  The 2nd parameter says whether you want that to be increased to account for the copter's tilt angle.  aka angle_boost.


Randy - You are exactly right!  Thanks!

I set g.rc_3.channel_in to 100 and I change the set_throttle_out to range from 0 - 1000 and can watch it on my scope and on a servo.

You da man.

Very Useful! Thanks! :D

Hi Randy,

So I was trying out the Optical flow sensor today (finally!) and I can confirm that I get the same build issues as others have in trying to build the example sketch while attempting to build under linux with an APM 2.5, and Optical Flow 1.0. I fixed it by adding a #define CONFIG_HAL_BOARD HAL_BOARD_APM2 to the beginning of the sketch. 

Although it does build, (and I'm hardcoding the A3 pin number, 57, in the constructor of flowsensor(), since the macro you have suggested in the wiki doesn't exist/I don't know how keywords.txt works), when I connect via the serial port, the code seems to be crashing and resetting repeatedly, i.e., I keep getting
ArduPilot Mega OpticalFlow library test ver 1.5
on the serial line repeatedly. A few quick print messages  seem to suggest that something bad's happening in the flowsSensor.init() method.

Any suggestions?

p.s. I'm also having trouble trying to connect to the ArduPilot when using the Optical Flow sensor with a very similar reset behaviour when I try to connect with my build from trunk version. I see no connection issues when using the stock firmware and optical flow connected. I can also see values change on the optflow test, and it crashes/disconnects after a few minutes.

One interesting thing I noticed - the Arducopter release version  https://code.google.com/p/arducopter/downloads/detail?name=ArduCopt...) has an older version of the optical flow test sketch. Could that be the reason why it's not working with the trunk code? 

hmm...ok.  I'll have to check out the trunk code.  Pat H told me that the trunk code hadn't been completely tested since the move to AP_HAL.  I would have thought that the 2.9.1 code would have worked fine (it's pre AP_HAL).

Sorry for the troubles, I'll have a look at it although I'm moving house for the next few days..


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service