In preparation for the Japan Innovation Challenge we’ve been working on implementing slung payload oscillation suppression. While this feature is still a work-in-progress (see pull-request here) we hope to include it in ArduPilot Copter-4.6.0 which should start beta testing later this month.
The ArduPilot flight code has been enhanced so that Lua scripts can add a position or velocity offset (in real-time) to a mission. So instead of the vehicle flying exactly along the programmed flight path, the Lua script can slightly modify its position or speed.
For this application the copter-slung-payload Lua script has been created that adds a velocity that moves the delivery vehicle in the opposite direction to the payload’s current acceleration. This movement causes the payload to lose energy and stop oscillating (see the Physics Classroom for more details on pendulums). The script also calculates the position offset between the vehicle and payload and moves the vehicle so that the payload lands as close as possible to the waypoint target location.
For now the script is only active while the vehicle is in Auto mode executing NAV_SCRIPT_TIME and PAYLOAD_PLACE commands but in SITL testing the same algorithm works while executing other commands and even in other flight modes
As you can see at the end of the video, this results in the payload landing just 1.1m from the target.
To provide some more background, in previous years my team (TAP-J) has always used the Daiwa Winch which has the advantage of keeping the payload close to the delivery vehicle as it travels to the target location (which avoids any payload oscillation) but the winch itself adds weight (about 600g), takes time to deploy (max line release speed is about 1m/s) and we’ve also faced some issues with the winch becoming stuck due to the bouncing of the payload. Here is a video from a successful drop using the daiwa winch in 2019
So this year we wanted to try a simpler and hopefully more reliable approach using a slung payload. The payload must be slung about 40m below the delivery vehicle in order to give at least 10m of clearance above the trees (which are 20m ~ 30m tall). The payload place mission command is used to reduce the delivery vehicle’s altitude until the payload touches down and then automatically trigger the release of the payload which is attached using a servo gripper (the servo is mounted on the bottom of the delivery vehicle). This is the exact servo gripper that we are using
We debated whether to put the servo gripper on the payload or the delivery vehicle. Either was possible but we opted to put it on the delivery vehicle because it is simpler and the competition rules allow this.
To keep the line from becoming tangled or getting caught in the delivery vehicle propellers we use a hand fishing reel with some lead weights attached at regular intervals. Next time we will mount the hand reel on a wider flat piece of wood and place it closer to the vehicle.
Hey Randy! Great to see the talk you did on this in the conference. Charlie and I spoke to you afterwards to ask about implementing this without the use of a separate GPS on the load, but instead using some on-drone hardware to report an x/y angle in conjunction with a known sling length.
What is the best way to pass this data into the Lua script? I figure it would be through serial of some sort? I’m just starting to get my own SITL set-up going, so I will try some things on my side as well, but I figure you may have a good idea on where to start. Thank you!
Yes, this idea has come up and it will probably work. I think adding another function to replace the handle_global_position_int() method might work. In particular the part below the “-- update payload location” comment where it updates the payload’s estimated position.
BTW, if you have such a device and you’re happy to share then I could more directly help you with the development. No pressure though of course.
Thanks Randy,
Where can i find more details on how to setup and configure the Slung module.
E.G which FC is recommended on the end , which code is running there etc
Hi Randy,
I am familier with the wiki, and actually im not a newbe. It may be me, but seems that no details on how to install and configire it. how to configure the FC on the slung end does it needs any specific version, does it needs any arming settings etc..
I think this section from the wiki describes how to setup the payload. It doesn’t have a ton of detail but it’s complete I think. Anything that’s not clear? I guess we could add that any vehicle type can be installed on the payload (Rover, Copter, Plane, Tracker)
Mount an autopilot, GPS and telemetry radio to the payload. This payload autopilot must transmit the GLOBAL_POSITION_INT mavlink message to the autopilot at 10hz using a system id that is different from the autopilot’s. In the video above a Here4 GPS running ArduPilot was used along with an ESP32 radio running DroneBridge ESP32
I’m curious what it would take to get this to work in loiter mode? I’ve got a servo grapple on the end of a line that I’ve mounted the necessary hardware to and everything seems to be taking to each other right, just need to maiden it! I’ll be manually flying it a lot and I think it’d be super useful to have it stabilize the payload after coming to a stop when lifting off the sticks.
I think it might be as simple as modifying these few lines in copter-slung-payload.lua that check the flight mode is Auto and the active mission command. Relaxing these checks would allow the offsets to be sent in another mode and I’m pretty sure (but not 100% sure) that we support offsets in all flight modes
Thanks for the response! I’ll give it a try and let you know how it goes. Bit of an update, flew the script in auto mode for the fist time today and things got exciting. I’ve attached a link to a short clip of one of our attempts. The script seems to be propagating oscillation. I wonder if this has something to do with our line being considerably shorter and the period being so much faster than what you originally designed around? Also wondering if it matters that the payload fc is not facing the same direction as the drone fc. Could it just be confusing acc x and y?
The heading of the payload and FC shouldn’t be a problem. The payload should be sending the position, velocity and acceleration in earth-frame (e.g. North-East).
I agree that the issue is likely that the line is much shorter than my setup so the system is becoming unstable. I think the only solution is to greatly lower SLUP_VEL_P from 0.5 to maybe 0.1 and see if that helps.