As a follow up to an indoor test we did a about a month ago (blog post here), Assistant Professor Nagatani-san of Tohoku University, Izu-san of EnRoute (a primarily Japan based RC company) and I tested dropping a 2.5kg rover from a 4kg Hexacopter outfitted with an APM2.5 running ArduCopter 2.9.1. The test was done on the side of a semi-active volcano, Shinmoe which is in Kyushu, Japan.
The flight was all in Loiter mode with the release of the Rover via a servo controlled by the Camera Shutter function attached to channel 7 on the transmitter. The pilot (me) was positioned right near where the video was shot from.
Basically it worked but there we hit a number of issues:
- AC 2.9.1's Loiter has a 5m radius deadband meaning it moves back to it's original target unless you move more than 5m away (from the target). This meant that repositioning the copter precisely was quite difficult.
- As it was shot on the side of a Volcano at >1100m elevation, the wind was relatively strong and pushed the copter around at times.
- the release mechanism for the rover was slightly damaged in transport meaning it took multiple attempts to get it to release.
Next time we will try to do it fully autonomously.
We also took the opportunity to fly a separate large Quad outfitted with a 10000mAh battery up for a view of the crater. The flight took about 12min but it could have flown at least another 5min. Problems we hit included:
- Like the large rover-carrying-hexa this quad had very large propellers which could be caught by the wind at times meaning the controller had a lot of work to do to keep it upright at times.
- Arducopter 2.9.1 has a bug in that it proceeds to the next waypoint once it's reached the target lat/lon. This is fine for mostly horizontal flights but it's serious trouble for a flight like this in which the vertical component takes longer than the horizontal. The solution was to set the target take-off altitude to 150m and reduce the WP_SPEED to 2m. We ended up overdoing it so we flew the mission higher and more slowly than necessary.
Still, it did the mission as planned.
All feedback welcome!
Comments
I'd try some SimonK flashed ESC's. What you might be seeing is like I said a while ago, as the props get bigger, the inertia causes the response to go down, fast, and you might be at the limit of what's possible. I don't think the quad layout helps. Octo would be better I bet.
I should show you the video from my quad that I shot on the same day I did the extreme wind test in my heli. The quad was barely flyable. The video would make you sick almost instantly.
John: Ah yes, that's another way to do it. Boring, but certainly smarter! ;)
@Jason,
Ah, thanks for that. Maybe I'll just make all waypoints require an altitude then.
The big quad in the long distance flight was really hard to tune and I think you're right that it's a delay. It uses 600kv motors and these "Aquila" ESCs.and really big (15x5.5?) carbon fibre propellers. I had thought that it was the props that were causing the delay but maybe you're right it's the ESCs. They can't be flashed...they're the type where you can't calibrate them, you just need to ensure your tx's min throttle is 1000.
Randy, do you have normal ESC's or Flashed ones? It seems like there is a very fast oscillation in there which could be tuned out. If the ESCs cause the delay, not much you can do.
Do you think the new loiter and Nav code in the trunk would handle this much better?
As you probobly know the waypoint altitude requirement isn't really a bug. It's a lack of implementation on the MP and Mavlink side. There is no way to specify if a waypoint is required to hit an altitude.
In commads_logic.pde see these lines:
// if no alt requirement in the waypoint, set the altitude achieved bit of wp_verify_byte
if((next_WP.options & WP_OPTION_ALT_REQUIRED) == false) {
wp_verify_byte |= NAV_ALTITUDE;
}
then later..
if(alt_change_flag == REACHED_ALT) {
// we have reached that altitude
wp_verify_byte |= NAV_ALTITUDE;
}
But I think Leonard removed the alt_change_flag so we don't know if we've reached the required altitude.
If you comment out just the parts that say this:
// if(next_WP.options & WP_OPTION_ALT_REQUIRED) {
...
// }
You will have every WP require altitude to move on.
Jason
That's more like what real autopilot flying looks like for most people. It's erratic.
Regarding picking up the rover again..Just land the copter, then drive the rover under it and grab..
Bravo! That's pretty darn cool. Really enjoying watching the technical progression of the project. Upward and onward.
Cheers!
Nice work Randy!
I think recovering a machine will be possible in the near future. Using PX4Flow for precision ground targeting, and OpenGrab to grab it, you wouldn't have too much trouble with the recovery. As long as you don't "step on it", the OpenGrab would allow more leeway for the grasping operation.
Carl,
Thanks a lot. Dropping the rover after landing on level ground wouldn't be too difficult I think. Picking it up again would be much tougher but mostly because of the accuracy required to ensure that you're right on top of it while also ensuring that you don't step on it....but somehow do-able I think!
On level Ground?
I thought it was pretty cool the way it was . You would not want to risk dinging a prop in the sloped ground . I was just wondering ?" In the future?" could a hex land and take off again after picking up or droping off an object or package like the rover . You are doing Ground breaking stuff! Congratulations
-
1
-
2
of 2 Next