Problem compiling Ardustation2

I get this...

 


Ardustation2.cpp: In function 'void send_message(mavlink_message_t*)':
MAVLink:98: error: 'struct __mavlink_message' has no member named 'payload'
MAVLink:100: error: 'struct __mavlink_message' has no member named 'ck_a'
MAVLink:101: error: 'struct __mavlink_message' has no member named 'ck_b'

 

Here is the function:

 

void send_message(mavlink_message_t* msg)
{
  Serial.write(MAVLINK_STX);
  Serial.write(msg->len);
  Serial.write(msg->seq);
  Serial.write(msg->sysid);
  Serial.write(msg->compid);
  Serial.write(msg->msgid);
  for(uint16_t i = 0; i < msg->len; i++)
  {
    Serial.write(msg->payload[i]);
  }
  Serial.write(msg->ck_a);
  Serial.write(msg->ck_b);
}

 

Any ideas?

 

 

Views: 231

▶ Reply to This

Replies to This Discussion

Permalink Reply by Heino R. Pull on October 3, 2011 at 9:00pm

The Mavlink library has changed slightly in the latest libraries breaking Ardustation 2.  Compile with the Arducopter 2.0.38 or earlier libraries and these errors will be fixed and Ardustation 2 should still work ok with Mavlink in the later APM or ACM software (such as Arducopter 2.0.46). I'm working on fixing these errors with the latest libraries. 

Permalink Reply by Toby Mills on October 4, 2011 at 1:03pm

Hi Heino

 

That worked, though i'm using Arduplane, the arducopter libraries worked.

My plane is running the latest code so I assume its correct that it won't be working until the mavlink library has fixed. Let me know if there is anything I can do to help, not much of a coder but happy to test.

Permalink Reply by Heino R. Pull on October 10, 2011 at 7:23pm

Toby:

I tested ArduPlane 2.24 on Sunday with the antenna tracker , my original Ardustation 2 software (version 1) and Arducopter library 2.0.36 and the tracker did work.  If you need a quick solution I can upload this configuration.  Otherwise, I worked  on the Mavlink compatibility issue tonight and manage to fix it. I'm using the Ardustation 2 "Not Working (version 9)" and testing for now with the Arducopter 2.47.  The Mavlink interface start/stop and antenna tracker is now working.  I won't be able to test with ArduPlane 2.24 until Wednesday night, but the big issue I was facing is now resolved. I plan to upload the new version (v10) probably on Thursday.  This version will reconfigure itself based on seeing a heartbeat identified as ArduPlane or Arducopter.

 

Heino

Permalink Reply by Toby Mills on October 10, 2011 at 7:31pm

Heino

Thats is great, may as well focus on getting it running with the newest libraries than bother you getting an old version working.
I'll wait till thursday, update to v10 and give it a try.

Cheers

Toby

Permalink Reply by Heino R. Pull on October 13, 2011 at 6:31pm

Toby,

 

I didn't get everything that I wanted working (auto detect of ACM/APM and APM parameters), but antenna tracking is working for both ArduPlane and Arducopter. I also included the library I compiled with (ACM 2.0.48), but the APM 2.24 library should work.

 Ardustation2.0.10 Unified ACM/APM

 

Heino

Permalink Reply by Toby Mills on October 14, 2011 at 12:52am

Thanks Heino


I tried the new code but I think I must have a fault with my Ardustation on the xbee side of things.

It all compiles ok and appears to be running on the ardustation fine.

As soon as I power it up the red and blue light come on, then go off and come on again when it goes to "Starting XBee". (whether my APM and remote XBee are turned on or not).

Doing a get parameters times out.

I tried uploading Arducopter 2.048 into my APM and that didn't work either (also set the type to ACM in the ardustation code).

It feels like nothing is getting from the Xbee into the Ardustation.
Both Xbees test fine when I connect via the Mission planner to the APM.

I've  checked all the solder joints and all looks ok.

I might try and look at it under a big magnifier tomorrow in case I have a bridged joint or dry joint somewhere but any ideas would be appreciated.

 

 

 

 

Permalink Reply by Heino R. Pull on October 14, 2011 at 9:53am

I looked at my setup and the red light (associate) and blue light (RSSI) are on the whole time if my quad's xbee is up and running. They don't blink just after power up but stay fully illuminated the whole time.

If I power up without the quad's xbee turned on, the red associate light will be on and the RSSI (blue) is off. Again there is no blinking of the red and blue lights after I power up.

If I pull the XBEE out of the Ardustation, neither light illuminates at all when I power up.

 

The LEDs are connected directly to the XBEE through the Xbee connector and have a 390 ohm resistor to ground to limit the LED current. I would check the traces from the XBEE socket to the LED and then to ground.  The RSSI (blue) light indicates the received signal strength of the last packet received and is suppose to vary with signal strength - since it is a PWM signal. The associate is when the XBEE is associated - but I'm not sure when associated is asserted on an XBEE. 

 

I believe those lights should work whether the ATMEL processor is installed or not. I pulled the ATMega 328 on my Ardustation and powered up and the RED light stayed on and the blue light comes on when the quad's XBEE is up.  So the Arudstation software isn't in the loop in regards to those signals. I would pull your ATMEGA328 and see what happens to the XBEE and if you get the flashing behavior. If so, then there is something up with your XBEE connector or the XBEE itself - although you did say it works when using the Mission Planner.

 

One additional thing - through tjhe XBEE software API it is possible to redirect the purpose of DIO5 (Associate) and DIO10 (RSSI) to have different purposes.  I believe you can use the XBEE configurator to check that these are set to the default settings:

 

DIO10 is configured with AT Command P0 with a value of 0 - 5 with a default value of 1 for display RSSI

 

DIO5 is configured with AT Command D5 and has a value of 0-5 with a default of 1 - which seems to be Power LED output. The latest XBEE manual doesn't have a setting for "associate" and the value 2 is missing which must have been it.  So I may be wrong above and that the red light is always just an XBEE power light. It seems to depend on what version of the XBEE 900 pro module you have.

 

Hope this helps...

Heino

Permalink Reply by Toby Mills on October 14, 2011 at 8:40pm

Thanks Heino

I combed the whole board under a 20x magnifier and found a couple of slightly dry joints so I cleaned them up a bit.

This has changed the behaviour slightly.
With an Xbee not plugged in the LEDs do not come on as expected.

With the XBee installed, both LEDs (red and blue) come on straight away and stay on whether or not the remote XBee is powered up at all.

Turning on and off the remote Xbee has no impact on the Ardustation LEDs.

I removed the processor as suggested and the lights still come on when powering up including the blue one when there is no remote device turned on.

I double checked both XBees in USB adapters and the lights on these go on and off as expected so they are definately configured correctly and they work fine (I fly almost daily with these and they have worked great for months).

As i've now traced everything under the magnifier, I'm coming to the conclusion I must have either a faulty board or dodgy component somewhere.

 

 

Permalink Reply by Heino R. Pull on October 14, 2011 at 8:51pm

I just remembered something when I broke the XBEE connector on my Ardustation.  I had to unsolder and resolder the connector when I flexed the connector with too much force.  When I soldered the new connector in I saw some warning in the forums about soldering the 10 pin headers in with too much solder.  It is possible to short the pins in the XBEE connector very easily when soldering them.  If you haven't  checked it yet, I would try using an ohm meter on the sockets to check if there are any shorted pins.  That might explain the RSSI signal staying on no matter what. Since your XBEE woirks fine in another carrier board it has to be those 10 pin connectors.  I found a source online for the 10 pin connectors if you do need to resolder them.

Permalink Reply by Jeff E on October 14, 2011 at 9:33pm

I have that same issue with the xbee regulated board. Soldered to much the pins got shorted. Might be a good place too start. If I remember the correctly the RED will always be ON when the Xbee is plugged in. The Blue will stay on when the connection between xbee is established.

Permalink Reply by Toby Mills on October 14, 2011 at 10:23pm
Bugger. If that wasn't the problem, it is now.
I checked and there were no shorts between any pins so I thought I would touch up the soldering and add a bit more...

Too much, now the xbee won't slot in and make a connection so I've got no xbee lights at all now.
Once it's in there I don't think there is any way of getting the solder out cleanly.
Permalink Reply by Andre S on February 12, 2012 at 11:29pm

Hi all,

in case someone would also like to use this code (and ends up having the same problem): it seems that if one replaces the send_message part with something like this

mavlink_msg_request_data_stream_send(chan, 1, 0, MAV_DATA_STREAM_RAW_SENSORS,
MAV_DATA_STREAM_RAW_SENSORS_RATE, MAV_DATA_STREAM_RAW_SENSORS_ACTIVE);

and makes sure the target system id is correct and uses the same way to initialize chan to be a mavlink channel (see e.g. ArduPlane GCS_Mavlink) then it works. Tried yesterday on my workbench with a direct serial connection but of course it should also work with the Xbee in between.

Cheers,

Andre

RSS

Contests

Season Two of the Trust Time Trial (T3) Contest has now begun. The third round was a reliablilty/aerial photography round for both planes and copters, which is now closed. Stay tuned for the next round, beginning soon.

A list of all T3 contests is here. 

 

Top Content 

1 What do you think the APM should do on fail safe

What do you think the APM should do on fail safe
2 ArduCopter 2.5 released!

ArduCopter 2.5 released!
3 Brainstorming Specifications.

Brainstorming Specifications.
4 Control Software

Control Software
5 Housekeeping note: Kevin Finisterre

Housekeeping note: Kevin Finisterre

Groups

© 2012   Created by Chris Anderson.

Badges  |  Report an Issue  |  Terms of Service