We've just released ArduPlane 2.33 for your flying pleasure!
This release adds three new features over the previous release:
The new MAVLink stream handling means that when you ask for a telemetry stream you can now ask for any stream rate that is a multiple of 20ms period. Previously if you asked for 5 Hz for a stream then you got it at 3.3Hz, as we only supported 1, 3.3, 10 and 50 Hz streams. The new stream rate code is much more flexible.
The main motivation behind the new stream rate code is the ability to get the most out of the new 3DR radios. The new radios send information on their buffer state to APM, and the APM code can now adjust the telemetry stream rates to ensure that the internals buffer in the radio doesn't overflow. That allows you to run the serial link to the radio at a much higher baud rate than the radio link is using. So you can adjust the air data rate to improve range without having to reconfigure APM and the radio for a different serial rate.
The end result is that if you have a 3DR radio you no longer need to carefully adjust your MAVLink stream rates to fit in the radio bandwidth. Just ask for a high number and the APM will adjust the timing to whatever fits.
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.
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.
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
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?
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
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!
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.
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;>.
// Change scaling to 0.1 degrees in order to avoid overflows in the angle arithmetic
int16_t min = angle_min / 10;
// Change scaling to 0.1 degrees in order to avoid overflows in the angle arithmetic
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.
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.
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!
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?
Have a look carefully at the startup messages on the board. Does it say "No dataflash card inserted"?
If so, check the card is firmly seated (maybe pull it out and put it back in). Also, check your voltage levels carefully. The dataflash card is the first thing to stop working if your voltage is off. Use the planner to look at the Vcc voltage of the 2560. It should be close to 5V.