Replies to This Discussion

Permalink Reply by Jose Angel on October 17, 2011 at 1:25am

DJI Wookong-M does not provide navigation features at the moment, but I'm not sure if these features can be upgraded just with firmware or if they plan to release a new board with additional hardware.

Right now gps hardware (including the cortex) is only used to loiter.

• ▶ Reply

Permalink Reply by Balloon on October 17, 2011 at 5:52am

This's my auto mode. It's pretty good. I like it. But, Loiter mode is some oscillate move circle about 3 - 4 m. tomorrow, I will new test and tuning PID loiter.

 

• ▶ Reply

Permalink Reply by u4eake on October 17, 2011 at 7:31am

Did some more testflights yesterday with 2.0.48 but this time without any wind.  Automatic mission performance was definitely much worse then with 2.0.46, I again aborted the mission.

I also noticed that engaging RTL while the hexa was slowly descending, kept it descending in stead of returning it home keeping the same altitude.  I had to abort the RTL about 2m above ground and bring it back in stabilise with simple engaged.

Engaging simple with chan7 works very nicely.

Also tried circle mode.  It didn't resemble a circle at all, just looked like a 'dancing quad', seemingly randomly rotating around its vertical axis.  Loiter makes a much better circle.

I did the above test mainly to rule out the influence of wind on my previous results and also because I haven't had time yet to add my led modifications to 2.0.49 and upload it to the apm.

 

Balloon, which version did you use for that mission ?  That looks pretty good, I had similar results on 2.0.46, but not on 2.0.48.  Did you use standard navP of 4.0 ?

 

Nice video Jason !!  Fun isn't it ? :-)

• ▶ Reply

Permalink Reply by Balloon on October 17, 2011 at 7:32am

This's version 2.0.49. I used nav_P 3.0 and loiter_P 0.3

• ▶ Reply

Permalink Reply by druckgott on October 17, 2011 at 11:23am

Which version do you have at the moment 48 / 49??

• ▶ Reply

Permalink Reply by Balloon on October 17, 2011 at 11:30am

I used version 49.

• ▶ Reply

Permalink Reply by Willy Swart on October 17, 2011 at 7:22am

I'm flying a Y6 configuration consisting of APM, PAN, campass, sonar, Xbee, Turnigy Plush 25A, RCTimer 2836 kv750, APC 11x4.7. I started with version 2.0.38 about three months ago. It flew well. I tried to upgrade to 2.0.41 but could not get it operational.

In the end of August I crashed the Arducopter due to a malfunctioning motor. Last month I build a new one and started to fly with 2.0.46. Last week 2.0.48 and since this morning 2.0.49.

It took me some time to get the Arducopter flyng with 2.0.46/48. Reason: somewhere after 2.0.38 the rotation directon of some motors was changed.

After adjusting direction of the motors de Arducopter was operational again. Behaved correctly on pitch and roll, but not on yaw. Turning to the left is OK. But turning to the right starts with an uncontrolled turn to the left. Giving more right yaw input makes the Y6 turn to the right at last. But small correctional commnds tot the right cannot be given. 

This morning I changed the 2.0.38 code to support the prop directions of 2.0.49 and loaded it in the Arducopter. Test flying: no problem with yaw..

The difference between the code of .38 and .49 is that in .38  the power of the top motors is decreased to 92% (0,92) of the power of the bottom motors. This factor is now disappeared.

Entering this factor in the code againg solved the yaw problem alsmost. In fact, for my configuration 90% (0.90) is the correct factor.

Yaw to the right is somewhat slower than to the left but I am not longer surprised with a Y6 turning the wrong way.

 

Was there a reason for removing this top-bottom factor in a Y6 configuration?

• ▶ Reply

Permalink Reply by Matt Gaige on October 17, 2011 at 8:25am

Willy, I have the same issue with a Scorpion Y6.  The Yaw issue has made 48 unusable for my Y6.  42 does well though.  But I do not understand the code solution you mentioned.  I hope Jason and others will look at this issue soon.  What file did you edit for this factor?

 

Mat

• ▶ Reply

Permalink Reply by Willy Swart on October 17, 2011 at 10:07am

I modified motors-y6.

I downloaded 42 and compared it with 49. I don't see any difference apart from a code clean-up. So another part of the code has been changed also,

So probably the issue is introduced between 43 and 46.

I shall make an issue report.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on October 17, 2011 at 10:18am

 

This is interesting. I will check in the GIT logs to see when this up / low ratio code has been removed. This seems to me a merge error somewhere.

 

I suppose that it is with 2.0.46.

 

 

• ▶ Reply

DeveloperPermalink Reply by jasonshort on October 17, 2011 at 10:42am

Max has been the only Y6 tester i've been in contact with. He sent along the Y6 Mix based on the MultiWii mix. It's slightly different than our mix which is commented out below the MW mix. 

 

He said it flew better and eliminated his issues with the earlier mix. 

Jason

• ▶ Reply

Permalink Reply by Willy Swart on October 17, 2011 at 11:36am

In 42 I see in motors-y6 the new code. Mat (above) reports its working. The same code is in 46. In 49 it is the same code also, but cleaned up. The old commented code is removed. Form at least version 46 the issue exists, So I assume somewhere else in the code something has changed.

The fix I made in motors-y6 removes the worst behaviour , but is not the correct one I think. Yaw is now is influencing nick a bit.

As I stated in the issue report (265) I am willing to test this issue. To me it looks as if somewhere a value boundery is exceeded.

A tip were to start digging in the code will help.

• ▶ Reply

• ‹ Previous
• 1
• …
• 6
• 7
• 8
• 9
• 10
• …
• 34
• Next ›
• Page