I've just released ArduPlane 2.67
This release fixes a number of important bugs, as well as adding a few new features.
This release changes how the level parameters are stored in EEPROM, so it is very important that you re-level your plane after upgrading if you have MANUAL_LEVEL set to 1.
The key changes in this release are:
- fixed a bug in the uBlox GPS driver that could cause it to setup the GPS with the wrong dynamic model, using the "portable" model instead of the "Airborne-4G" model. In some cases it could also leave the GPS in its default dynamic model. This results in poor navigation, and sometimes in poor attitude control due to inaccurate acceleration correction.
- fixed a bug in the APM parameter code that resulted in the deadzone parameters of auxiliary channels not being able to be set. For example, setting RC5_DZ would actually set RC5_MIN.
- add support for using vertical velocity from a uBlox GPS as part of the DCM acceleration correction.
- added new accelerometer calibration code from Randy. This adds an optional calibration step that can be performed using the "accel" command in the setup menu in the CLI. See description below.
- allow the CLI to run over the telemetry radio link. This is particularly useful for the new accel calibration code.
- added a new secondary aileron type. I'm hoping this will resolve the ongoing issues some users have had with the secondary aileron support
- changed WIND.speed direction to match the convention that the speed is based on where the wind is coming from
- fixed handling of parameter names of 15 or 16 characters (they could appear garbled in the ground station)
- added RSSI_PIN option to set the pin that measures the receiver RSSI
- added support for showing compass health in SYS_STATUS MAVLink message
- fixed throttle disable in VFR_HUD MAVLink message to always be between 0 and 100
added new parameter APM_OFFSET (thanks to Alexey Kozin)
The new accelerometer calibration code that Randy did is particularly interesting, as it gives us a way to get the accel calibration much more accurate along all 3 axes, which should improve the attitude solution somewhat. It is not properly documented yet, but if you are feeling adventurous then try running the CLI and running the "accel" command in the setup menu. This replaces the normal levelling process.
Happy flying!
Cheers, Tridge
Replies
We have been experiencing a telemetry connection issue recently as per this conversation http://diydrones.com/forum/topics/connection-error-in-apm-mission-p...
This only seems to happen with arduplane and not arducopter, is this anything to do with the update?
Hello I have revised the code ARDUPLANE 2.6.7 and found strange that the option airspeed.use () = false is identical g.alt_control_algorithm =ALT_CONTROL_NON_AIRSPEED
to be able to use trottle control from the airspeed sensor, but classical altitude control should be returned
static void calc_throttle()
{
if (!alt_control_airspeed()) {
to old
static void calc_throttle()
{
if (!airspeed.use()) {
+ the same change in radio.pde
in this case
parameter g.alt_control_algorithm =ALT_CONTROL_NON_AIRSPEED
will disable airspeed only here:
static void calc_nav_pitch()
{
// Calculate the Pitch of the plane
// --------------------------------
if (alt_control_airspeed()) {
will only be used to control the throttle channel
Hi Tridge,
Some receivers (such as frsky D4R-II and D8R) output rx RSSI as PWM on one of their regular servo output pins (once the rx has been put into PPM mode, freeing the pins up), would it be possible to support such receivers?
e.g. if RSSI_PIN is set to one of the existing channel inputs, it uses the channel PWM value (which I gather is already being calculated) as RSSI rather than taking an analog reading?
Having said that, in the case of the D4R-II, since it only outputs PWM RSSI when the rx is put into PPM mode, the APM would also have to be in PPM mode, so I guess it would no longer be reading anything but the first channel input anyway and this won't work.
Perhaps the solution is to have a new parameter RSSI_PWM (0=analog, 1=PWM) and have the RSSI code itself do either PWM or ANALOG readings. This would rely on the available spare pins brought out on the APM1&2 being capable of PWM readings (not sure if this is the case) and may complicate the code (I don't know how PWM readings are taken).
I hope all of that made some sense!
Dave
Hi
I have just uploaded 2.67 to my APM 1
I was really looking forward to being able to use terminal/cli over the 3DR radio link.
I cannot get it to work yet however, are there any setting I need to change?
Good news Andrew, soon I will test it.
Thanks!
Guto
Great job Andrew. It's possible to fly away in autonomous mode, change the route manually with the radio and the plane flies in this new direction whitout wind influences (deviations)? like a fly to here but with te radio control considering that you are far for the radiomodem signal
Is there a setting that when in RTL the plane descends linear with home distance?
An example: When i am around 4km away and my hight is 500m above home.
FS kicks in, than my plane dives to 100m immediately and i have no chance to get back control till my plane gets close.
This is very frightening to me. :)
If it would work like in auto mode that would be great!
I am not afraid of coding, if i have to.
Please give me advices.
Thx,
Gábor
Andrew
First Great work.
Glad to see 2.67, plan on trying the MP upload to see how it works on Sunday. Been using a complied version for a few days, testing on AMP1 for a new plane.
At this rate I'm not going to have a reason to keep Arduino compiler on my computer.
That said, You heard a but, How hard would it be to have a Mavlink message just for OSD.
Maybe like this
<message name="OSD" id="XXX">
<description>Missing values for OSD</description>
<field type="uint16_t" name="mampsused">Instead of % send mAmps used</field>
<field type="uint16_t" name="Batt2voltage">Second Battery Voltage</field>
<field type="uint16_t" name="Batt2 current">Second Battery Current</field>
<field type="uint16_t" name="Batt2mAmpused">Batt2mAmpused"</field>
</message>
I'm sure there are other values, but the few I would like to see.
I have tried to modify a few of the Mavlink message without much luck to add some of the above.
Maybe a point in the right direction. ( I believe I failed on the CRC check of the message)
Last in the release notes you talked about on manual level, reseting the values. Does the update need a full erase of the eeprom and start over?
Congrats to the Team!
I am going to test it out thoroughly over the weekend. Happy Turkey Day to all!
Hi
I put the 2.67 firmware and there are 3 ports to configure through the MP, A0, A1 and A13, A1 is used for air speed and A2 for battery, tried putting in A13 and gave error to assign it :/ /
well, I would like to know exactly how connects the correct pins to connect the output of the RSSI from RMILEC UHF.
Can someone help me? not find anything about it
thanks!!
-
1
-
2
of 2 Next