APM Mission Planner with APC220 RF module

Dear All,

Firt...let me thank you guys working very hard with all these Ardu-things (ArduPilot, ArduCopter, APM, ...). Very nice and I love it!

I have bought a set of APC220 RF sender/receivers for using as telemtry link for my ArduCopter. I could not connect with the APM Mission Planner...got a time-out for "no heartbeat sent". It did however work with HK GCS and QGroundStation so I started to dig into why it did not work with APM. Luckily, the code is available and hence I have now managed to get it to work.

The APC220 requires the RTS and DTR to be false at all times as no handshaking can be used. I also found that the version of ArduCopter (2.4.1) that I have does not send heartbeats on the telemetry port...have I set something up badly here?

To get this to work you can edit the code to change how the OpenBg() is executed in the MavLink.cs according to:

lock (objlock) // so we dont have random traffic

{
log.Info("Open port with " + BaseStream.PortName + " " + BaseStream.BaudRate);

if (useAPC220)
{
// No RTS/DTR at all for this one...
BaseStream.RtsEnable = false;
BaseStream.DtrEnable = false;

BaseStream.Open();

BaseStream.DiscardInBuffer();
}
else
{
BaseStream.Open();

BaseStream.DiscardInBuffer();

BaseStream.toggleDTR();
}

Thread.Sleep(1000);
}

I added a small "useAPC220" propery that I set to "true".

I also added/changed a setting where the code expects the heartbeats to come:

if (useAPC220)
{
// No hearbeats coming from my 2.4.1 FW using APC220...why?
// firmware issue?
sysid = 1;
compid = 1;
mavlinkversion = 2;
aptype = 2;
break;
}
else
{
// incase we are in setup mode
BaseStream.WriteLine("planner\rgcs\r");

buffer = getHeartBeat();

// incase we are in setup mode
BaseStream.WriteLine("planner\rgcs\r");

System.Threading.Thread.Sleep(1);

buffer1 = getHeartBeat();
}

So, I hardcoded some values (version, id's etc) that is coming from the heartbeat package normally.

Anyhow, this is a rather bad approach (but quick and dirty and works for my special case). So, now I wonder if it would be possible to add a few settings in the APM Mission Planner to handle this? Maybe one can have a setting for "use handshake" and one for "expect heartbeat". This would make the APM to be compatible with the APC220 as well.

Well...that was what I had in mind. Thanx once again for your hard work!

/Stefan

Views: 4691

▶ Reply to This

Replies to This Discussion


DeveloperPermalink Reply by Michael Oborne on March 14, 2012 at 4:14pm

ive moded the connect sequence again, please give 1.1.52 a try.

the reason hk's connected is it doesnt care if it lost a param, where as i force it. this is because pid settings may not load and cause other issues.


btw the planner does have an override option for connecting. (Control-T) use at your own risk


DeveloperPermalink Reply by Michael Oborne on March 14, 2012 at 4:16pm

also just a fyi.

the planner sends the request, once the apm starts sending params, all other data stops, only params are sent. so technicly flodding shouldnt happen if it has worked in the past


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 12:19am

Just tried with v1.1.52, but still no luck with APM2 - doesn't connect, just times out.

Still connects fine to APM1, refresh params works once but not the second time - all params go blank but still get live flight data through. If I power down APM1 (and the APC220 connected to it) and then refresh the params it refreshs fine (but not a second time).

EDIT: I have now just been able to connect to APM2, (after restarting MP and APM2). Have live flight data but cannot read or write params.


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 12:36am

MP log attached

Attachments:

DeveloperPermalink Reply by Michael Oborne on March 15, 2012 at 3:25am

ok something new to try.

set the telemetry rate on the apm to 19 aka serial3_baud

set your remote modem to 19200 baud as well. this will turn on the internal apm serial speed checking. and should prevent alot fo currupt packets. and now try connecting


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 3:43am

Trying this now, using the RF Magic program linked here, I've changed the 'Series Rate' to 19200, left the 'RF TRx rate' at 19200, different 'Node ID's', did this to both modules (and changed the port speed to 19200).

No joy Michael, can't get them to connect now... APM1 too


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 4:05am

Tried twice, no joy. Going back to 57600 I can at least connect to APM2 on most tries but changing params doesn't work (which is what I really want to do)


DeveloperPermalink Reply by Michael Oborne on March 15, 2012 at 4:18am

when you change the serial3_baud on apm did you reboot apm?


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 4:42am

Sorry, I understood to change the baud in the Mission Planner, where do I change "serial3_baud"? EDIT: found it config.h, checking now...

No, I didn't reboot APM after, should've, but will try that now


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 5:10am

OK, done it correctly now including changing the "serial3_baud" to 19200. Rebooted APM and still have the problem. It stalls at SR3_EXTRA3 then goes really slow from there and ends with failed connection.


ModeratorPermalink Reply by Graham Dyer on March 15, 2012 at 5:38am

Permalink Reply by Brent on March 15, 2012 at 7:05am

Syberian posted this up @ RCG megapirates thread concerning APC220

To all the guys experiencing the problems with APC220 link:

You have to lower the update rate in the mission planner. Go to Configuration-Planner and set 'telemetry rates' to 3,1,1,0.

The Glider`s adventures was caused by flooding the APC with data stream. The telemetry data amount was too high to fit in the 19200 baud aerial speed of this module. Since the modules are semi-duplex i.e. working sequentally on the same frequency, there were no space left for incoming ground commands. Also there were massive packet drops and skips on the board side.

I dove deeply into this today when tried to connect my APCs to a new Megapirate Plane 2.24. The mavlink protocol was not designed for that low transmission rates.
I`d ended up reducing the telemetry rates as mentioned above.
Also these lines should be found and commented in the gcs_mavlink.pde (backup the original file):

send_message(MSG_GPS_RAW);
send_message(MSG_NAV_CONTROLLER_OUTPUT);
send_message(MSG_RAW_IMU1);
send_message(MSG_RAW_IMU2);
send_message(MSG_RAW_IMU3);

Mentioned above will drastically reduce the channel loading.

Michael if you want, PM me your address and I will send you a set of APC220's .

Thanks for your time looking into this.

RSS

Social Networking

Top Content 

1 ArduPlane 2.73 released

ArduPlane 2.73 released
2 How to analyze a crash?

How to analyze a crash?
3 ArduVTOL

ArduVTOL
4 NEVER connect a Capacitor backup or voltage protector on APM board

NEVER connect a Capacitor backup or voltage protector on APM board
5 HD video for UAV's

HD video for UAV's
6 APM Copter 2.9.1.b has been released

APM Copter 2.9.1.b has been released
7 DIYDrones Chat Feature Info

DIYDrones Chat Feature Info
8 Arducopter 3Dr or Phantom

Arducopter 3Dr or Phantom
9 Arducopter Question

Arducopter Question
10 An Open Letter to Google Chairman Eric Schmidt on Drones

An Open Letter to Google Chairman Eric Schmidt on Drones

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The fourth round is an accuracy round for multicopters, which requires contestants to fly a cube. The deadline is April 14th.

A list of all T3 contests is here. 

Groups

Advertisement

© 2013   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service