Replies to This Discussion

Permalink Reply by Greg on September 30, 2011 at 7:50pm

I managed to get some more time on 2.0.45 today despite a little rain. This time I paid extra care to monitor the gps, but happy to report no issues in stable mode. I decided not to risk Loiter mode again due to earlier GPS issues reported from my last flights a week ago.

Now I have problems with ALT hold. I engaged this and found copter climbed abruptly then seem to stabilize but then flight control was a little erratic. At this point I had to abort the flight some loose material fowling one prop. I had to make a rapid descent and then I found the motors would not stop at zero stick. Perhaps I have mired the manual but in alt hold below a certain point the throttle should be controllable ie I can land and shutdown the motors? I ended up having to flip modes to kill the motors

Is this normal behavior in alt hold mode Sorry if this seems a stupid question.

Another issue I noticed from the flight log is the Baro reading is inverse to the sonar. This does not seem correct? It is like the Baro is reading negative with increasing altitude

• ▶ Reply

Permalink Reply by Martin Szymanski on September 30, 2011 at 9:15pm

Altitude hold will adjust with the throttle position to raise or lower the altitude.

It does not have direct speed control. Stabilization mode does.

I always have my fingers ready to the switches to go to stabilization mode.

Regarding the barometer there are others that can explain better.

In robotics there is what is called a frame. It is like a 3D workbench.

It can be defined in any direction, various angles, even upside down with the cartesian cord system.

Once a frame is made it becomes a constant for positioning programs that are trained with it.

I think the barometer numbers likely are inverted.

Just my guess.

 

• ▶ Reply

Permalink Reply by Greg on September 30, 2011 at 10:49pm

Martin:  Thanks for the clarification on the throttle position.  Lucky, like you I instinctively (heli flying) switched modes in time :-)  But good point I must make sure the next setting on the switch goes to stabilize mode so I don't have to jump over two.

 

I keep forgetting about the frame of reference,  so your explanation about the baro reading makes sense to me.  Appreciate you reply and help.

• ▶ Reply

DeveloperPermalink Reply by jasonshort on October 3, 2011 at 10:18pm

You should have much better luck with 46. I've added some rate error limits and let you tune the outer loop.

Jason

• ▶ Reply

Permalink Reply by Gareth Rens on October 1, 2011 at 4:11am

Loading the code went smoothly. Erased eeprom and went through all setup steps. Xbee telemetry works perfectly.

First test flight of 2.0.45!

 

Alt hold works like silk! With 42, the motors changed pitch quite a bit while maintaining altitude. With .45 they are dead still!

 

Will do some more tests outside with loiter when the hurricane has passed...

 

• ▶ Reply

Permalink Reply by Alex on October 1, 2011 at 8:28am

I tried again today the 2.0.45, the alt hold problem is still there.Is is possible that the baro sensor could be damaged? In addition one time my hexa was going forward slowly even if i was pushing the stick back , to make it return but without succes (log no.6).Why it was not returning ? What could be the cause?  I've added (hopefully this time are really added) the log files. Maybe someone can take a look to see what is happening.

Attachments:

• 2011-10-01 05-55 6.log, 496 KB
• 2011-10-01 05-56 7.log, 590 KB

• ▶ Reply

Permalink Reply by Martin Szymanski on October 1, 2011 at 8:19pm

My build had drifts due to vibrations to the IMU.

After a few hours of wear on new parts I have found some harmonic vibrations that occur with time and wear.

Recently I have added 1/2 inch neoprene rubber gasket material to float the IMU away from vibrations. Before it used silicone rubber.

It is thumbless in stable mode with no wind.

 

• ▶ Reply

Permalink Reply by Greg on October 1, 2011 at 9:01pm

I just did a similar modification using tiny rubber gromets for the APM/ IMU mounting bolts, plus doubled sided rubber tape under the flat surface of the borad itself. Seems to have reduced frame vibration harmonic feedback to the IMU :-) Wish the weather would clear soon to do more 2.0.45 testsing. Two weeks of gusty rainy conditions with only small breaks for quick tests :-( I am still having issues with LOITER and ALT Hold on 2.0.45.

• ▶ Reply

Permalink Reply by afernan on October 2, 2011 at 11:53am

Test on 2.0.46

 

I´ve tested 5 batteries in new fw.46. In general all modes worked very well, including RTL and AUTO. I just have some small issues (I´ve tried to repeat them to verify)

STAB & SIMPLE works perfect as usual.

 

ALT_HOLD works very well (better than ever). But some times it start to behave as before (small thrust peaks). After restarting it´s solved. (Not sure if it´s the code, maybe is my SONAR; but pay attention, in case)

 

LOITER works very well . I´ve tested with medium and light wind and divergences of fw.45 dissapear (using default PIDs). Even I could increase  Nav_P to 2.7 without problems. Tested with medium wind and also wind in calm.

 

RTL. I put   ALT_HOLD_RTl = 4 but sometimes doesn´t come to that heigth, but in most of cases yes.

 

AUTO. I did many checks. I can summarize the following.

- Now ALWAYS do the expected path (in previous fw, not always). So, much better. I repeated 10+ the same path, and always well

- When a Waypoint is reached, the change to the next is very violent. This is good when you plan to do the path very quicly but is not nice for testing.

- Speed is too high between WP. I´ve tried to reduce m/s in "New WP" but it affects only to the "travel" between WP. Once reached is violent.

- I´ve found in the "flight planner" "Loiter radius"=-24 . as default. What does mean?. I´ve changed to 5m.

 

So we can say that this version is close to the end of being "beta"

Some videos comming.

 

 

 

• ▶ Reply

Permalink Reply by u4eake on October 2, 2011 at 12:03pm

I also flown multiple batteries on 2.0.46 now and can agree with afternan.  

Stabilise, simple and althold are very good.  On sonar althold I never got the pulsing motors afternan speaks of.

Loiter flew around in a 10m diameter circle, but that got better when I lowered loiterP a bit. (0.8 in stead of 1.0)

RTL was odd.  About 65% of the time it would work perfect.  The other times it would seem to work ok, returning home as expected, but when it reached home, it would hesitate for a very brief moment and then take off again in the same direction it was travelling to get home.  It would just continue it's course, after a very short hesitation at home position.  I let it go for 30-50 meters, but never any sign of comming back.

 

In auto I also saw the relatively aggressive change when waypoints were reached, but it's not too bad for me, before I had time to get scared the copter was already nice and smoothly on its way to the next waypoint.

I did notice that now the copter seems to wanna land at the next waypoint, instead of the previous one.  Land was my last command, and instead of landing at the last waypoint, it continued to the first waypoint of my mission and wanted to land there.

 

Video is also comming.

• ▶ Reply

Permalink Reply by Heino R. Pull on October 2, 2011 at 12:26pm

Flew 4 packs with light 5mph winds 2.0.46 and pretty good for me also.  Stabilize, simple, and althold all very good. I don't have enough room to test RTL or Auto, so I tried loiter in baro alt hold altitudes (30 to 60 feet). Loiter much improved over 2.0.45 for me also and I'm narrowing down on  a NavP of 2.77 in wind with default I terms on my "dirty" stock quad. No divergence at all, the quad loitered in a 5 meter circle. At sonar altitude alt hold (4 feet), the NavP work well also which wasn't the case for me with 2.0.45 (the wind at this altitude is blocked by the house).

 

Very good for me and I'm now planning some RTL and Auto tests in the country next weekend.

 

Thanks Jason and all.

• ▶ Reply

DeveloperPermalink Reply by Olivier ADLER on October 2, 2011 at 12:52pm

 

I think that an acceleration curve needs to be implemented between waypoints.

 

V =  ( 2 G . X ) -²

 

X is position from start waypoint to mid point

V is instantaneous speed

G is desired acceleration

 

Then limit the speed according to max speed value and reverse the position increment when mid point has been reached.

 

in the end :

 

if position < mid point : V =  ( 2 G . X ) -²

 

if position > mid point : V =  ( 2 G . (Xb - X)  ) -²

 

Xb is end position.

 

 

 

• ▶ Reply

• ‹ Previous
• 1
• …
• 4
• 5
• 6
• 7
• 8
• …
• 13
• Next ›
• Page