Replies to This Discussion

DeveloperPermalink Reply by Andrew Tridgell on April 9, 2012 at 2:59am

Hi Jason,

The ground station sends MAVLINK_MSG_ID_REQUEST_DATA_STREAM messages saying what stream they want at what rate. Have a look at handMessage() in GCS_Mavlink.pde.

You can set this in MP using the Configuration -> Planner -> Telemetry Rates options.

The stream rates are also exposed in APM as EEPROM parameters, so you can also set them via PARAM_SET calls, although the ground station regularly sends new REQUEST_DATA_STREAM updates which will override this.

If you are using one of the new 3DR radios with DUTY_CYCLE set then APM and the radio will automatically adjust the telemetry rates down to suit the available bandwidth.

Cheers, Tridge

• ▶ Reply

Permalink Reply by Simon Amstel on April 10, 2012 at 2:38am

That information is super useful! I always thought that the plane just blurted out Mavlink and that the settings were to save GCS resources for Netbooks etc that can't parse the data very quickly. 

Many thanks

• ▶ Reply

Permalink Reply by James on April 9, 2012 at 4:44am

Hi to all!!  

Gongrats to the Dev Team, the last month was like a torrent of releases and features, many thanks! Tridge tweaks things like minigun as far i can see, in GIT. Awesome Job!!

For sure we are happy fliers, members, droners, clients etc. 

but we will be excited- happy  Drone - Mappers if u plz implement camera tracking to the new code

Many thanks again

Regards 

James

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on April 9, 2012 at 2:10pm

Hi James,

Thanks for the kind words!

The main reason I haven't worked on camera tracking in ArduPlane is I don't have a setup that allows me to test it. I do have a camera in my Telemaster, but it points straight down for the OBC search.

As you probably know, the camera mount and tracking code is already in the ArduPlane tree, but it is disabled by default. To enable it, you need to add:

#define MOUNT ENABLED

in APM_Config.h and rebuild.

The actual camera handling code is shared with ArduCopter. You configure it via MAVLink, telling it what GPS location to point at and other properties of the camera. You also need to setup the RC functions of the channels you use for controlling the camera. The key options are the RCx_FUNCTION settings, which tell the RC channel what role it plays (ie. if it controls roll, or pitch or yaw of the camera). For example, to set channel 6 to control the roll of the camera you would set RC6_FUNCTION=8 (the constant 8 is from RC_Channel_aux.h, and means 'k_mount_roll').

So what we really need now is for someone to volunteer to be the 'owner' of camera tracking in ArduPlane. That would involve testing and documenting how to setup and use camera tracking. It may well be that it all works already, or it may be that it needs some tweaks to make it work right. If everyone waits for me to do it then it may take a long time, as I have a lot of stuff on my todo list!

If someone can confirm that it already works then I will enable it by default in future releases, and then we just need to write up some docs on setup and usage.

Do you have the time to try out the current camera tracking code and write up what works and what doesn't?

Cheers, Tridge

• ▶ Reply

Permalink Reply by James on April 10, 2012 at 1:56am

Good Morning Tridge,

That was the most straight answer for months!! and answers at least 20 forum threads about cam stabiization..  I suppose, the code is there somewere (maybe just enable mount by mavlink) also documentation is there ( if you erase the compilation step). I will try your suggetions and read more about rc functions, but iam miles away from understanding all the librares nedded to check..  

I tried out the current camera tracking code, with presistance for more than two months, burnt a brand new red board and some servos, nothing worked so i gave up  and i refresh like 10 times/day the wiki and GIT waiting , for a new precompiled version... 

Thanks for your time

James

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on April 10, 2012 at 3:59am

Hi James,

I didn't realise there were so many questions about this! Please ask again if you get stuck.

As I mentioned, this sort of feature really needs someone who will 'own' it, and give it the testing and documentation it deserves. Looking at the code, I don't see why it wouldn't work right now, but that of course is a long way from someone confirming it all works with a set of photos taken on a test flight!

What I really need to do with these feature is add it to our automated test suite. That would be the best way to ensure it stays working. Now I just need the time to do that!

Cheers, Tridge

• ▶ Reply

Permalink Reply by Greg Fletcher on April 10, 2012 at 7:23pm

Hi Tridge, I am volunteering for this mission. I kinda have all ready done it. I sent you several PM's and received no reply. I can confirm that the existing mount code kinda works with gps tracking and the rc control doesn't realy work at all. The gps pointmode is actually disabled.

        m.transpose();
        targ = m*_GPS_vector;
        /* disable stabilization for now, this will help debug */
        _stab_roll = 0;_stab_pitch=0;_stab_yaw=0;
        /**/
        // TODO The next three lines are probably not correct yet

All set to zero. Didn't you see my vid(or maybee you did and thought L was a loon), It was bad and an unedited fist take. Here it is again. I will get it ported over to 2.33 probably by this weekend. There are loots of changes to be made.

1 I see that it is mow in the 50 Hz loop, it used to be in the medium loop. Done.

2 There is a fundamental error in the angle to servo that the 2 segments below are compensating for. That's the "//...overflows in the angle arithmetic" What's needed is this <#define DEG_PWM 0.11111111111111>, and this <radio_out = (_reverse * angle * DEG_PWM) + 1500;>.

RC_Channel_aux

    // Change scaling to 0.1 degrees in order to avoid overflows in the angle arithmetic
    int16_t min = angle_min / 10;

AP_mount

    // Change scaling to 0.1 degrees in order to avoid overflows in the angle arithmetic
    G_RC_AUX(k_mount_roll)->closest_limit(roll_angle/10);
    G_RC_AUX(k_mount_pitch)->closest_limit(pitch_angle/10);
    G_RC_AUX(k_mount_yaw)->closest_limit(yaw_angle/10);

Respectfully

Greg

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on April 10, 2012 at 9:01pm

Greg,

My apologies for not replying to your messages! I was really swamped at the time working on the 3DR radio firmware and then I just forgot after things settled down. Sorry!

Can you do a patch or a git clone that fixes the issues for you? Then if you reply here hopefully I'll actually respond!

btw, I'll also be a bit slow to respond this week, as it is a teaching week for me. Things should be a bit saner next week.

Cheers, Tridge

• ▶ Reply

Permalink Reply by Greg Fletcher on April 10, 2012 at 9:47pm

Tridge, Glad to here from you. I'am  sorry but i don't know what a git clone is. I would like to learn. I can zip up some files send them and you could do it? I am using Arduino for compiling now.

Trust me. I figured out the gimbal stuff using an ardu imu2. When I saw that there was new Ardupilot code with the gimbal control I looked at it saw some stuff that I had already tried that worked with one axis at a time, but got "twisted" when "reverse simulated with servos in the loop";)

I will try and get up to speed on the git repository.

Cheers, Greg

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on April 10, 2012 at 10:42pm

Hi Greg,

Have a look at this guide for contributing. If you have a git clone and make some changes, then you can send a "patch" file generated with git for me to apply.

If you can't work it out then you could send a zip file, but please only send me the changed files, and tell me exactly what version the changes are against.

Thanks for taking this on!

Cheers, Tridge

• ▶ Reply

Permalink Reply by Eagle on April 9, 2012 at 5:33pm

Hi Tridge, Just updated APM2 with ArduPlane 2.33 release.

I dont needed automatic compass declination and don't have a 3DR radios since I use Xbee.

But I want to keep APM2 updated with the latest ArduPlane version. (maybe a bad idea)

Now like many I struggled with magneto lately...to get a grip with COMPASS_LEARN, and learned to use  MANUAL_LEVEL param , etc ... from 2.32.

Now I think there is a problem with LOG_BITMASK....

Could it be an offset with Mission Planner and the addition of COMPASS_AUTODEC?

Don't know.  But I'm unable to set logging anymore.

Am I the only one not being able to set the bit mask for logging? Other user please acknowledge.

I used CLI to set it. But When I go back to Mission Planner, log bit mask shows '0'

Maybe a bug in Mission Planner due to the addition of COMPASS_AUTODEC param or the problem is sitting at 8 inches from the keyboard. Hope Michael can acknowlege on this.

 

Anyway Please, before looking at camera traking and stuff, can we have a stable and functionnal ArduPlane software version?

Lets say just to be able to stabilize, FBW-A/B, RTL etc... and follow freaking waypoints?

 

No offense to the team.

Thanks all for your hard work.

Eric

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on April 10, 2012 at 4:21am

But I want to keep APM2 updated with the latest ArduPlane version. (maybe a bad idea)

actually, I think its a good idea! I don't do a release unless I think everyone should use it.

Now I think there is a problem with LOG_BITMASK....

that's strange. I do test that option regularly, and it is part of the standard autotest. You can see the dataflash logs from our autotest system here

The only thing I can think of is if you have an old 1280 based APM1. The on-board logging is currently the only feature we disable by default on the 1280 boards, as we couldn't fit all the code in. You can re-enable it, but then you'd need to disable another feature (perhaps the GPS auto-detection?).

Do you have a 1280 based APM1 perhaps?

Anyway Please, before looking at camera traking and stuff, can we have a stable and functionnal ArduPlane software version?

Lets say just to be able to stabilize, FBW-A/B, RTL etc... and follow freaking waypoints?

I do test all of those features very regularly. I tested all of those on Friday as part of my pre-release test flights.

If you could post a telemetry log and describe what didn't work then maybe we could work out what's wrong together?

Cheers, Tridge

• ▶ Reply

• ‹ Previous
• 1
• 2
• 3
• 4
• Next ›
• Page