Flight Tests For Co-operative Missions Using ArdupilotMega

This is in continuation to my earlier blog post on Hardware In Loop Simulation For Co-operative Missions Using ArdupilotMega.

This video was recorded through live video telemetry from the 'Follower' aircraft running custom code(attached below) on APM autopilot board. The 'Follower' aircraft receives waypoint information from a 'Leader' aircraft also running on APM autopilot board and thus follows the leader aircraft autonomously through the air.

The video shows the airframe of the follower on which the camera was mounted. We were hoping to catch the 'Leader' aircraft on the camera flying ahead of this follower, but poor video signal quality left us wanting more. Although you can occasionally see the leader in the video (at 3:30), its no more than a black spot in the air. Next time we'll probably use something like FlyCamOne for onboard recording or a better video telemetry kit.

Autopilot Used(Both Leader and Follower) : APM 2.5 (Latest)

No hardware changes required except for soldering burg-strips on UART2 of APM2.5 board. UART2(Serial3) is used for all telemetry.

Communication modules used : Xbee Pro S1 in API (mode 1) on all Aircrafts(UART2) and Groundstation Laptop

Aircraft GCS communication : MAVlink v1.0 *Embedded in Xbee API header and Footer.

ie (API Header)[All MAVlink Packets](API Footer)

GCS used : MissionPlanner, Qgroundcontrol GCS coupled with MAVproxy.

MAVproxy is used to collect data from groundstation Xbee and Add/Strip API headers as and when required to send clean MAVlink packets to qGCS and MissionPlanner through UDP connection on separate ports.

Inter Aircraft communication : In Xbee API protocol (Not MAVlink)

No. of MAVs in the cooperative mission simulated : Upto 3 till now, can be easily extended to more.

Cooperative missions flight tested : Leader follower for 2 MAVs.

The sketchbook containing the firmware for the above cooperative mission is attached.

Flight Tested Leader-Follower Sketchbook. I'll write a small readme on how to set this system up and get it going soon, it's straight forward really.

@Cliff-E: GPS and waypoint data for inter-aircraft communication is being sent in the 'slow loop' (the 3 1/3 Hz loop), although I've used the 10 Hz loop in HIL simulation to good results. I am yet to try the 10 Hz interaircraft communication in flight tests though.

Dead reckoning commands to multiple copters...could you elaborate on that a little ?

We went straight API for inter-aircraft communication to keep the overhead bytes a minimum, assuming that using MAVlink would further add its own Header and footer making the packet longer(What update rates do you guys use ? What is the packet size ?). For sending 12 bytes of payload data (4 each for lat, long, alt) through straight API, our packet becomes 23 bytes long(we have a start tag and a special data crc for safety). Although for all this we had to write our own send/receive and encode/decode functions alongside the existing MAVlink functions, so I agree using MAVlink would have been much simpler(I'll probably try that now).

Also, our destination addresses are 'hardcoded' for xbee source-ids, that is, aircrafts are identified through their xbee source ids. How do you setup destination addresses through GCS ? Do you also use MAVproxy to deal with API on the ground side ?

Thanks.

You need to be a member of diydrones to add comments!

Join diydrones

Comments

Abhsiehk Mukherjee January 5, 2014 at 8:41pm

What add-on functions can be done so as to make the system better?
Bharat Tak February 11, 2013 at 9:21pm

@Cliff-E: GPS and waypoint data for inter-aircraft communication is being sent in the 'slow loop' (the 3 1/3 Hz loop), although I've used the 10 Hz loop in HIL simulation to good results. I am yet to try the 10 Hz interaircraft communication in flight tests though.

Dead reckoning commands to multiple copters...could you elaborate on that a little ?

We went straight API for inter-aircraft communication to keep the overhead bytes a minimum, assuming that using MAVlink would further add its own Header and footer making the packet longer(What update rates do you guys use ? What is the packet size ?). For sending 12 bytes of payload data (4 each for lat, long, alt) through straight API, our packet becomes 23 bytes long(we have a start tag and a special data crc for safety). Although for all this we had to write our own send/receive and encode/decode functions alongside the existing MAVlink functions, so I agree using MAVlink would have been much simpler(I'll probably try that now).

Also, our destination addresses are 'hardcoded' for xbee source-ids, that is, aircrafts are identified through their xbee source ids. How do you setup destination addresses through GCS ? Do you also use MAVproxy to deal with API on the ground side ?

Thanks.
Cliff-E February 11, 2013 at 5:23pm

What update rate are you sending the GPS and waypoint [change] data? We're finding that dead reckoning commands to multiple copters are smoother and use GPS to close the loop for simple avoidance measures (granted we're using multicopters).

We're using API mode with MAVLink in similar fashion (header+mavlink+footer), why did you guys go straight API mode for inter-copter communications when you can just use the same mechanism and just specify destination addresses (and you can flip a bit on any message for broadcasting)? Are you noticing a performance advantage (cause we don't see a difference)? And destination addresses can get setup (not hardcoded) by the GCS when everyone gets armed, aka "preflight".

Good job nonetheless.
Developer

Kabir February 11, 2013 at 7:20am

Where are you guys located? Where is this flying field located?
3D Robotics

Chris Anderson February 11, 2013 at 5:52am

Sounds impressive! But I'm not quite understanding what the video shows. Is that plane the follower?

This reply was deleted.