Replies to This Discussion

ModeratorPermalink Reply by Nathaniel Caner on December 25, 2012 at 11:19am

Tridge,

I'm trying to understand what I'm seeing in the graph of the tlog as far as 'HeartBeat' messages goes. I think I have graphed the right items here, but I'm not sure what I should expect to see for the 'HeartBeat' portion of the graph. Is it a frequency count or should I expect to see it oscillate up and down like a heartbeat? If it's a frequency count what is the expected frequency? Lastly what are the 2 different RSSI values and how do they differ? Is there a wiki somewhere on the MavLink protocol with an explanation of the different parameters?

Regards,

Nathaniel ~KD2DEY

• ▶ Reply

DeveloperPermalink Reply by Andrew Tridgell on December 25, 2012 at 2:23pm

Hi Nathaniel,

Heartbeat messages go in both directions. In this case I suspect the plane was not receiving heartbeat messages from the ground station.

The logs show heartbeat messages like this:

2012-12-16 04:52:46.49: HEARTBEAT {type : 1, autopilot : 3, base_mode : 1, custom_mode : 16, system_status : 2, mavlink_version : 3}
and also like this:

2012-12-16 04:52:52.40: HEARTBEAT {type : 6, autopilot : 3, base_mode : 0, custom_mode : 0, system_status : 0, mavlink_version : 3}

The first one has type==1, which means "fixed wing". That is ArduPlane. The second type has type==6 which means "GCS", so that is Mission Planner.

So the planner was configured to send heartbeats. The puzzle now is why the APM went into GCS failsafe.

The timing is key. Here is the message where the APM enters GCS failsafe:

2012-12-16 04:52:47.19: STATUSTEXT {severity : 1, text : Failsafe - Long event on, }

That is only 1 second after the start of your log, but it is 24 seconds after your APM booted (we can tell that as many of the messages have a "time since boot in microseconds" field).

The logs also show that MP doesn't send it's first HEARTBEAT until 5 seconds later. It looks like it doesn't send heartbeat messages while it is downloading the parameters from the plane.

I'm going to make a small change to the ArduPlane code to reset the timer for GCS failsafe when we finish the system startup. That would prevent what happened to you, and also makes more sense as it is the time since we finished init rather than the time since power on that really matters.

There is another puzzle in your log however. The ArduPlane code has a "throttle suppression" mechanism that is supposed to prevent the motor starting while waiting on the ground. Whenever the plane is in an auto mode (including RTL from failsafe) it monitors the height and ground speed (from the GPS) and if the height is below 10 meters and the ground speed is below 5m/s then it won't run the motor.

In your case you happened to get GPS lock soon after startup, and your GPS reported a ground speed at that time of 10m/s, so the throttle suppression was disengaged. I suspect your GPS was under a roof and got a poor ground speed estimate from the initial satellite lock.

Cheers, Tridge

• ▶ Reply

ModeratorPermalink Reply by Nathaniel Caner on December 25, 2012 at 7:17pm

Tridge,

Once again you are spot on with your assumptions! Yes I was indoors when testing so the GPS didn't have a clear LOS. The behavior makes much more sense to me now. Could we use the Airspeed instead of the Ground Speed when ARSPD_ENABLE and ARSPD_USE are set to one? Would that be more reliable?

Is there a wiki section somewhere that goes into the Mavlink parameters in detail? I'd like to become better at reading the logs and understanding what some of the more cryptic parameters abbreviations mean.

Thanks again for your help. I hope you had a happy holiday down under.

Regards,

Nathaniel ~KD2DEY

• ▶ Reply

Permalink Reply by ben on January 31, 2013 at 10:58pm

hi there,

im having a similar problem , when ever i turn off my transmitter my motors go full speed after bout 10 seconds which is bout the time of fail safe.... and if i leave that off and turn everything else on ...motors go wild again. im running sabertooth to power the apm 2.5 unit. which powers the input and output separately . ive checkd sabertooth dip switches, and now im wondering if its something to do with the apm 2.5 unit itself holding values when it loses signal.

• ▶ Reply

Permalink Reply by Bill Bonney on February 3, 2013 at 8:38am

See http://code.google.com/p/arducopter/wiki/AC2_Failsafe
See http://code.google.com/p/ardupilot-mega/wiki/APM2xFailsafe

ArduPlane and Arducopter have different fail safe logic, and who knows what ArduRover does, well probably Thomas knows ;-). I would recommended posting in the ArduRover forum a new topic asking how fail safe works in ArduRover. That's a better place to discuss that

Also look at the fail safe section in Mission Planner. You can set what the fails are output is for the motors there.

And check this tutorial on analyzing the logs, that will help you understand what the APM decided to do (probably an RTL)
http://code.google.com/p/arducopter/wiki/AC2_Logs

Hope that helps

• ▶ Reply

Permalink Reply by ben on February 7, 2013 at 1:12pm

well i turned failsafe completely off yet it still either sends a signal or sabertooth is holding a signal not sure why everything is fine...

• ▶ Reply

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