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
Tags:
Permalink Reply by OG on March 15, 2012 at 1:38pm I can confirm APM2 serial interface not connecting with APC220, RN-XV WiFly Module, RN-42 AT Bluetooth Modem - BlueSMiRF Silver. all these are working with APM1 any thing I can do to help resolve this issue?
the fact that this module does not seem to work on an apm2 at all, is there a voltage level issue?
also my suggestion for a fix it to modify the arduplane/arducopter code
eg
in gcs_mavlink.pde
// send out queued params/ waypoints
if (NULL != _queued_parameter) {
static uint16_t count = 0;
if (count % 3 == 0) {
send_message(MSG_NEXT_PARAM);
}
count++;
}
this code will slow down param sending by 3, and should always connect.
Michael

Well, it does work partially with APM2, I can connect, but it's unreliable and params can't be changed.
Permalink Reply by u4eake on March 17, 2012 at 5:42am Hi Michael,
I can confirm that with your change (slowing down parameter sending 3x) the connection succeeds with APM1 1280. But changing parameters doesn't work anymore, neither does uploading waypoints.
Also I have to reboot ACM if I want to connect again after a disconnect, without rebooting, I get a timeout.
u4eake,
can you test doing wp upload and dl with all the stream rates set to 0 ? you will need to change them, and wait 20-40 seconds for them to take affect. and try doing wp's and setting params.
Andke, tcp is a lossless protocol, so explains why it works. UDP and straight serial are not.
i think the bottom line here is that there is to much data passing across the link to be realy useable. the params flood the interface, trying to send 50 paramaters per seconds, which causes the connect failure. and with wp's and setting params, the other data, attitude and location must be to close to flooding the link as well. This is where idealy the apm should be set at 19200 baud not 57600, as the internal apm handling will prevent a fair bit of flooding/packets being dropped/delayed.
in the planner i will upload tommorow i have change the param request retry to 6, from 3. and also changing the way the heartbeat is detected.
before it was, see hb, look for another within 1.2 seconds, seen = pass, not seen = fail.
and the fact you guys cant even get past that tells me that you are not seing a hb packet within that 1.2 seconds. fyi hb packets are sent every second.
also, the reason for the not being able to connect after a little while. i beleive this is to do with the stream rates once again. duing bootup, gyro init etc, the streams wont be flooding the link, the planner can talk to the apm during this time, so connects.
Permalink Reply by Andke on March 17, 2012 at 8:58am sounds very reasonable - and you are probably onto something there. - I'll try to use *only* TCP from now on. The strange thing is, that if link flooding would be the problem - then TCP should jam up even faster, not only due to the need for ACK but when retransmissions would be done over and over again.. So till I fly much more with TCP - I think it's strange that it does not fail to connect - kind of contradicts the otherwise good idea to think we flood the link.
BTW: Even the slowest GPRS classes handle 20kbit , up to 40kbit depend on class. if I am on edge, that is ~60 or ~120 I do not know how many kbit the serial interface is really outputting ?
Permalink Reply by kolin on April 1, 2012 at 9:23am Hi,
I'm also trying to get APC220 working. I changed baudrate of APM to 19200, set APC's to 19200 on RF side and serial side. As Brent suggested on page 3, I commented out this in gcs_mavlink.pde
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);
and aplied your patch to slow down sending parameters by 3 and still no big joy. I'm able to connect righ after startup, I can see updating of HUD, but can't upload waypoints, can't do calibration and I can't connect after while. As I understand APC220 isn't wonderfull piece of hardware but I don't want to throw it away. Problem really seems to be lack of bandwith. What about using handshake?
APM v1
Arduplane 2.32
Mission planner 1.1.59
Thanks
Permalink Reply by OG on April 1, 2012 at 9:45am My module are still working on 2.5 & I have them duplexed 57600 baud rate ! use the latest misson planer! but not on APM2
Permalink Reply by u4eake on April 2, 2012 at 3:01pm With mission planner 1.1.59 and APM 2.5.3 (git 21880a5d1750 ) no joy in connecting anymore. It used to work with the sending rate of params / 3 on 1.1.56, but now even that won't connect. I get a timeout (no heartbeat) and it won't even try to load params anymore...
ctrl-T also doesn't want to connect.
Damn this is annoying, what can I do to help troubleshoot this ? I can modify ACM code, but I don't have visual studio and am not familiar with the mission planner code.
Permalink Reply by u4eake on April 2, 2012 at 3:24pm Scrap the above, I am now able to connect with mission planner update rates set to 0 and "reboot on usb connect" disabled.
I can still connect with update rates 3,1,1,1,1 and then I can also change pid settings, but waypoint reading or writing doesn't work.
Will keep testing.
goto config > planner > reset apm on connect, and switch that option.
Permalink Reply by Alberto Cristóbal Granda on May 13, 2012 at 2:56pm Hello to everybody:
I am new here,
I have being flying with Arducopter since 6 months ago, I hade The APMplanner and I connected to my Acopter with dhw Wireless APC220
everyting was OK but I have upgrade today and I cant not connet again with the wireless, I can do it with the USB cable but no with the APC220.
The modems are OK because I use then to connect an MK to the MK tools and it works good.
I receive the message " No Heatbeats packets received"
Where is the problem??
Thanks
Alberto
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.24 members
1289 members
248 members
57 members
87 members
© 2013 Created by Chris Anderson.
Powered by
