Replies to This Discussion

ModeratorPermalink Reply by Adam AKAV8R on February 4, 2011 at 11:59am

Anyone have any ideas?

• ▶ Reply

Permalink Reply by Johann Van Niekerk on February 4, 2011 at 12:09pm

Hi Adam

 

After you plugged in your Xbee and you pressed connect and waitted for the APM to calibrate , hit the "yaw Zero" button under the 3d model and then try

• ▶ Reply

ModeratorPermalink Reply by Adam AKAV8R on February 4, 2011 at 12:49pm

Didn't seem to make a difference.  I tried it a couple times and everything is still opposite.  Nose IMU down model plane pitches up, bank IMU left model plane banks right, etc....

• ▶ Reply

Permalink Reply by Phil Cole on February 4, 2011 at 8:04pm

There is a setting screen with reverse buttons. Have you need there yet?

• ▶ Reply

ModeratorPermalink Reply by Adam AKAV8R on February 4, 2011 at 9:08pm

That worked!  Thanks Phil

• ▶ Reply

Permalink Reply by Kartik Chandrasekhar on May 4, 2011 at 4:57am

How did you manage to get the XBee modules to talk to each other? I configured the XBee modules according to these instructions: http://pixhawk.ethz.ch/wiki/tutorials/how_to_configure_xbee. Then, I also set up the APM code on Arduino (GCS Port 3, etc). HK GCS works fine with USB connection, but I am struggling to get it to work through the XBee modules. Any help please?

• ▶ Reply

ModeratorPermalink Reply by Paul Mather on May 5, 2011 at 7:10pm

Which XBees are you using? Some have a baud rate limit.... have you tried a slower baud rate?

 

Here's my APM_Config.h

 

#define FLIGHT_MODE_CHANNEL 8
#define FLIGHT_MODE_1 AUTO
#define FLIGHT_MODE_2 RTL
#define FLIGHT_MODE_3 FLY_BY_WIRE_A
#define FLIGHT_MODE_4 FLY_BY_WIRE_B
#define FLIGHT_MODE_5 STABILIZE
#define FLIGHT_MODE_6 MANUAL
#define GPS_PROTOCOL GPS_PROTOCOL_AUTO
#define GCS_PROTOCOL GCS_PROTOCOL_MAVLINK
#define GCS_PORT 3
#define GPS_PORT 1
#define SERIAL0_BAUD 38400
#define SERIAL1_BAUD 38400
#define SERIAL3_BAUD 38400
#define ALLOW_RC_OVERRIDE ENABLED

 

If you're using the pre-compiled firmware from Michael O's planner, then you don't have a choice on baud rates. I think it's 57600 for GPS on port 1 and 115200 for GCS on port 3....I think

 

http://code.google.com/p/ardupilot-mega/wiki/Wireless

• ▶ Reply

Permalink Reply by Kartik Chandrasekhar on May 6, 2011 at 4:23am

We're using the 2,4 GHz XBEE Series 2. It's still not working :(

• ▶ Reply

ModeratorPermalink Reply by Darren on May 6, 2011 at 4:50am

Defaults are as follows:

USB APM, Serial0 is 115200 (although I think it is still 38400 on ACM)

GPS is auto detect on Serial1 but normally 38400

Telemetry (XBee) on Serial3 is 57600

 

HK if thats your settings, it may explain some things. How long have you been using 38400 for telemetry?

• ▶ Reply

ModeratorPermalink Reply by Paul Mather on May 6, 2011 at 8:04am

Since the beginning. 115200 is an absurd baud rate... far higher than needed and so much more prone to bad data.

• ▶ Reply

ModeratorPermalink Reply by Darren on May 6, 2011 at 1:57pm

I am not trying to debate baudrate selection. But unless I'm mistaken; I simply stated default paramaters of 115200 on the hardwired usb cable. not on the xbees' that have been defaulted in repository at 57.6 for a long long time.

However I can personally attest that I have flown with 900pro xbees set at 115200 for over a year with no issues at all in range or of garbage. And only recently have I brought them down to use 57600. To be honest; that was only to test with svn and apm uploaded versions, as well as other folks custom apm_config.h arduino fed tests too. And once things settle down, I do plan on going back. more bandwidth empty buffers faster, which relates to quicker release of the transmit process.

So bottom line; I cant say I've seen any real world problems at the baud rates above 38.4

 If you wish, I can begin including more tests in both 38.4 and the higher rates. to see if it eliminates any comms issues.

• ▶ Reply

ModeratorPermalink Reply by Paul Mather on May 6, 2011 at 3:10pm

I'm glad you prodded me to do this Darren, I went ahead and did some testing with my XBee Pro 2.4's (XPB24 - 802.15.4). I used the code below and simply changed the SERIAL3_BAUD from 115200 to 57600 to 38400. At 115200, nothing worked. Absolutely nothing. The data was not arriving at the GCS the same way it was sent. It was close. But a few bits were off in every message and not once did it recognize a correct MAVlink packet (thank you checksums). So I stepped it down to 57600. No changes to the GCS aside from selecting the different baud rate. Guess what? Everything worked perfectly! I stepped down to 38400 and again, flawless. The spec'd number of 250kbps in this document is totally false: http://www.digi.com/pdf/chart_xbee_rf_features.pdf

 

This thread on the Digi website confirms it: http://forums.digi.com/support/forum/viewthread_thread,8632

 

And I believe this is the reason DIYDrones no longer supports the 2.4G XBee Pro's. So if you'd like actual data to flow through your 2.4G XBee's, you need to set it to 57600 or less. This might not be a problem with human readable protocols (ie AttoPilot or ArduPilot Legacy) but I didn't test those. I can confirm with MAVlink binary it does not work at 115200.

 

#define FLIGHT_MODE_CHANNEL 8
#define FLIGHT_MODE_1 AUTO
#define FLIGHT_MODE_2 RTL
#define FLIGHT_MODE_3 FLY_BY_WIRE_A
#define FLIGHT_MODE_4 FLY_BY_WIRE_B
#define FLIGHT_MODE_5 STABILIZE
#define FLIGHT_MODE_6 MANUAL
#define GPS_PROTOCOL GPS_PROTOCOL_AUTO
#define GCS_PROTOCOL GCS_PROTOCOL_MAVLINK
#define GCS_PORT 3
#define GPS_PORT 1
#define SERIAL0_BAUD 57600
#define SERIAL1_BAUD 57600
#define SERIAL3_BAUD 57600
#define ALLOW_RC_OVERRIDE ENABLED

• ▶ Reply

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