Arducopter 2.0 first impressions
2.0.14 is my first Arducopter code. My previous experience has been with MultiWiiCopters and I built and flew several quads with this software.
Wanting to try out UAV/GPS features, I built an APM and today I swapped out the electronics in an existing quad with APM hardware.
I am using a non-standard frame, but the quad flew in STABILIZE mode without any PID changes. So far I have only tried out SIMPLE, ACRO and STABILIZE modes – mainly because I have been test flying in my basement (no GPS signal, and also the available space is smaller than the LOITER radius :-)).
I really liked the Mission Planner, which made code download and setup very easy. Though I had to reverse the Elevator control in my Tx after realizing it was reversed in the first test “hop”. It wasn’t very obvious in the Radio Panel in the configurator that this control needed to be reversed.
Arming: It was a bit disconcerting that arming the motors is almost un-noticeable. I had to stare at the APM to figure out that a previously green LED had now started blinking. The MultiWii code spins the props (at low RPM) at all times when the motors are armed. This is a very useful safety feature and it would be great if ArduCopter adopted this too. The manual states emphatically that the props won’t spin, but I am not sure the reason behind it.
ACRO: after bumping up the P values, and turning up Expo on the Aileron and Elevator controls in my Tx, I was able to fly in ACRO mode. Interestingly, even a small non-zero “I” value made it completely unstable.
The ability to update PID via XBEE is very nice since it makes it easy to experiment with various parameter values.
The next two modes worked better with the expo settings removed for aileron/elevator (back to linear).
SIMPLE: it seems to work, although I have a question about which heading it locks on to. When I overrode the heading with the yaw stick, it didn’t appear to aggressively come back to the original heading. Does it latch on to a new heading after the override? BTW, I do have a compass sensor.
STABILIZE: I found this the easiest to fly with and so far I haven’t changed the PID values. I’ve seen comments that the yaw problem has been fixed in this release. However, I found the yaw very sluggish – almost as though I was fighting heading-hold. I checked more than once to make sure I wasn’t in SIMPLE mode. Also, after it begins to yaw, it tends to overshoot. Then if I center the yaw control, it slowly turns back a little. Next I plan to tweak the Yaw PID to see if it fixes this sluggishness.
Of course, the raison d’etre for Arducopter 2.0 are the UAV/GPS/GCS/Mavlink features and I am looking forward to testing these in the next few days.
Replies to This Discussion
-
Permalink Reply by Wessie on -
Thanx rob will get started on that Right away.
Seen some threads where ppl say that only one of the lights behave right, is this an issue, or is it sorted? Regardless, I will test it tonight and report back.
Wessie
By the way, I have not officially congratulated Chris, Jani, and EVERYONE on this project for a stunning job selfishly done. I am having SOOOO much fun, it just aint legal. I dabbled in open source ideas before, and definitely getting that "heal the world" feeling back again. LOL
-
-
Permalink Reply by Limebear (Rob) on -
Wessie,
I constructed my LED interface slightly differently from the linked guide. Rather than a flying lead attached to the 5 pins of the IMU, I soldered a miniature 5-way female header connector directly to the 4 o/p pins, at right angles to the IMU, and the fifth (ground) pin with a wire. I can now plug my LEDs cable directly into the side of the IMU. Make sure you don't have a nylon leg in the way, mine was close.
I also made up a little 5 x 5 veroboard square with the four 22 ohm resistors recommended by the build guide, which connects the four LED pairs to the 5 wires to the IMU.
I went for high brightness LEDS, red to port, green to starboard, white to front and rear. The rear should flash.
I haven't seen any reports yet that all the LEDs work. Can anyone confirm?
Rob
-
-
JDronesPermalink Reply by Jani Hirvinen on -
LED's are activated on those extra ports but there seems to be some misbehavior how they work. We need to rethink a bit how to put those due this LED code is coming from old ArduCopter NG code.
But yes you can connect leds and 3 are lit, 1 blinks on current software.
-
-
Permalink Reply by Wessie on
-
OK Jani as you said, only one light blinks. Before I ask for features already in the works, what is the intended plan for the lights? Is it going to be ANYTHING like my first post? If there is nothing concrete may I suggest the above "sequences"? It makes it really nice if :
a. you are on the ground, and you can immediately see if you have or not have GPS, ARMED, BATTERY VOLTAGE, and what MODE you are in. I think these are the most impotrant ones.
b. When you are flying in STABLISE mode, all led's will be solid on, and a flashing motor led will quickly tell you if something is wrong. If you fly other modes, the rear led will flash accordingly, which is fine.
I would also suggest you guys make the front Led BLUE like we did. not only does it match the GPS led (hint hint), but it looks really cool, and makes it really easy to distinguish front from back when flying towards you. (for those who dont know their port from their starboard.) ;-)
With 4 different colours on the motors, fast piro's at night look really awesome!!
-
Permalink Reply by Kristian on -
No spinning when armed!
I want to be able to cut engines fast, when screwing up, before it hits the ground or a person!
I usually catch my quad in hand when landing. Not being able to cut engines makes this a problem!
The only real excuse I can think of to make the engines spin when armed, is that it keeps the quad stable if accidentaly moving throttle to minimum during flight. This can be accomplished by just trimming throttle negative during calibration, so you can adjust the throttle trim a few clicks up after arming to make the engines spin. Or just flip flight mode or dualrate on transmitter after arming.
-
Permalink Reply by Sebastian Gralla on -
then just disarm? lower disarm time and you'll be safer than before
-
Permalink Reply by Kristian on
-
Lower disarm time is a really bad idea! Maybe not when just hovering steady around, but if you fly aggressive you might accidentaly disarm in flight. I personally deactivate the disarm function by setting dualrate on yaw after arming, so it's not possible to disarm in flight. I understand the need for arming before flight, but forced spinning propellers when arming, and disarming function that activates to quickly is not safe!
-
DeveloperPermalink Reply by jasonshort on -
In the current code it's user selectable - But compile time only. I don't want to burden the mission planner with too many options. Just download via SVN and set the option in APM_Config.h. Everybody wins!
- ‹ Previous
- 1
- 2
- 3
- 4
- Next ›
Social Networking
Top Content
Contests
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.A list of all T3 contests is here.
Groups
-
Terrain/Surface Mapping
115 members
-
ArduRover User Group
183 members
-
ArduCopter User Group
1280 members
-
ArduCopter Italian Group
87 members
-
ArduPlane User Group
673 members
Advertisement
© 2013 Created by Chris Anderson.
Powered by
