ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

     I've just push ArduCopter-rc4 into the new downloads area and GitHub and it should appear in the MissionPlanner's beta links shortly.

Improvements over 3.0.0-rc3
1) loiter improvements:
     i) repositioning enhanced with feed forward
     ii) use tan to convert desired accel to lean angle
2) stability patch improvements for high powered copters or those with roll-pitch rate gains set too high
3) auto mode vertical speed fix (it was not reaching the desired speeds)
4) alt hold smoothed by filtering feed forward input
5) circle mode fix to initial position and smoother initialisation
6) RTL returns to initial yaw heading before descending
7) safe features:
    i) check for gps lock when entering failsafe
    ii) pre-arm check for mag field lenght
    iii) pre-arm check for board voltage between 4.5v ~ 5.8V
    iv) beep twice during arming
    v) GPS failsafe enabled by default (will LAND if loses GPS in Loiter, AUTO, Guided modes)
    vi) bug fix for alt-hold mode spinning motors before pilot has raised throttle
8) bug fixes:
    i) fixed position mode so it responding to pilot input
    ii) baro cli test
    iii) moved cli motor test to test sub menu and minor change to throttle output
    iv) guided mode yaw control fix

     Hopefully this will be very close to the version that becomes the official 3.0 release in MissionPlanner.  I will likely create a branch for this release shortly so that we can insulate it from other changes that will go into AC3.1.

     Sorry Marco & others, I have not implemented the always-spin-motors-when-armed feature for this release candidate.

-Randy

[Marco Robustini]

Thanks Randy for this exit!
No problem for the "always-spin-motors-when-armed

", i hope developed for the final release.
About the "pre-arming" check: yesterday i've disabled this feature or i can't arming my motors.
I think this feature is nice only if there's a configurable "bit mask" like "LED_MODE":

0 - arming pre-check disabled
1 - pre-arm check for right accel value
2 - pre-arm check for mag field lenght
3 - pre-arm check for gps fix
4 - pre-arm check for board voltage between 4.5v ~ 5.8V

For example with "10" i've all this options enabled.
In my APM dunno why the board voltage after the diode is 4.7 but i can't arm due "board low voltage", but i really need the other auto check and now there's no way to enable/disable all the single option.

Bests, Marco

[Marco Robustini]

My first test at the airfield is really impressive, all work fine, i tune better all the inertial and wp nav parameters for my quad and no issue at the moment.

Marco

On Sunday, June 2, 2013 8:10:27 AM UTC+2, Randy Mackay wrote:

[Randy Mackay]

Marco,

     Before we make it more complex with the bitmask, how about we just relax the board voltage check for everyone a bit?  If your copter is flying ok then perhaps what we have is too strict?  Maybe we should make it 4.3V instead of 4.5V?  I.e. reduce it by 0.2V

     It could be that the internal board voltage that we're reading is not super accurate...maybe we see 4.5 but really the board is at 4.7.

-Randy

---

From: Marco Robustini <robusti...@gmail.com>
To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>
Sent: Sunday, June 2, 2013 4:19 PM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Marco Robustini]

Yes, i think is better, with a 5V bec the voltage level check is too restrictive.

Marco

[Randy Mackay]

     Ok, I've relaxed it to 4.3V.  So the acceptable range is 4.3V ~ 5.8V now.

-Randy

---

From: Marco Robustini <robusti...@gmail.com>
To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Sunday, June 2, 2013 8:36 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Olivier ADLER]

I feel that the best solution would be to be restrictive, perhaps even more restrictive like adviced by craig with a ckeck at 4.8V, but adding a parameter for it so that users will be warned and will have the possibility to override this check lowering the check voltage.

This should give the best of the two worlds, no need for a mask and in spec checking.

Olivier

On Sunday, June 2, 2013 1:15:20 PM UTC+2, Randy Mackay wrote:

[Olivier ADLER]

Marco, there have been reports of brownouts and discussions about this in the past because of those 5V BEC, This was the reason for a new external voltage regulator at 5.4V.

This test is mainly here to warn users about this, those users who did not upgrade to the 5.4V regulator or those who are buying a clone without the 3DR voltage regulator and eventually fitted with out of spec fuses and shottky diodes that could drop down even more the AVR 2560 voltage.


That's why it would be better to rise it again, perhaps at 4.8V according to Craig recommendation, but do allow to have it settable through a parameter so that users can override the check with a lower value.


Olivier

[Steve Ball]

It looks like the ardupilot site is down :-( is there a compiled version on github?

Thanks

Steve

[Olivier ADLER]

This one is working for me :

http://firmware.diydrones.com/Copter/latest/

[Olivier ADLER]

I did test 3.0 RC4 with difficult wind conditions (very instable wind from 0 - 25 km/h) and short distances between waypoints.

the good points :

I'm very satisfied with the results for Auto misions, RTL as well as Loiter and all other modes.

Navigation is now almost perfect, it will be difficult to do it better... Except perhaps changing the GPS for an even better one and adding two X-Y motors for horizontal position adjustments... But who knows...

Position Mode is now working with user position control.



Version 3.0 seems a winner. Thanks to all programmers and testers for all the good work.



Nevertheless this thing worry me for 3.0 release :

- One time I did get accelerometers fully off before arming. I suspect an initialization problem at power on. It is not the first time i see this (perhaps since version 3.0). I had the same problem about 3 times each time at power on.

Disarming and rearming does not change anything. Only a power off clear the situation.

Trying to take off in those conditions result in a ground crash.

I don't know exactly what is causing this. Could it be because i'm moving a bit the copter after battery connection ? Or does this have no influence at all ?

If moving the copter after battery connection has no influence at all on accelerometer initialisation, then we have a communication problem or initialization problem here.

If moving the copter during power on is a problem for accelerometers initialization, then we should do something to avoid this problem, perhaps watch for gyro stability before to initialize accelerometers.


And a safety thing that should be patched before release : see patch #326 and comments (Modes switching, preliminary checks before entering GPS modes, GPS 3D Fix and HDOP < 3 for auto mode).



Other things not really important for 3.0 release :

- Would be nice to get user position input during RTL descend.

- Circle mode speed is fully wrong. It seems that the unit is not good. Entering 10 (m/s ?) inside Mission planner gives about 1 m/s in the field.

- Circle is really better now, but for version 3.1 it would be nice to have a sub mode where we could mix user Yaw input with computed yaw, so that we can adjust the camera target for filming.

- We are missing RC channels 9 - 12 to control all those functions ! A good job for the PX4 !


Olivier

On Sunday, June 2, 2013 8:10:27 AM UTC+2, Randy Mackay wrote:

[DanielB]

Randy, congrats on the new release, Arducopter-RC4.  Speaking of a moving target, this moving at >200mph!! (like driving one of those super cars LOL ;-)

Olivier, Marco.  Your initial tests looks very impressive and promising..

Haven't had the chance to do RC4 as the master download is down but just a quick one:  I generally use 2 sets of batteries: one for the motor/ESC (has the voltage current sensor), and another for the systems electronics, i.e., radio RX/controls/servos/autopilot/FPV (I find this cleaner and not subject to voltage/current glitches and faults). 

So I typically connect-power the systems electronics first then the motor/esc. While haven't had any problem with RC3, would this be an issue now with RC4 voltage check and arming changes?

Thanks.

[Robert Lefebvre]

Is there anything written down anywhere about what we need to do to get going with 3.0?  I'm starting to think about helicopter testing, since it appears that the navigation is quite a bit better than 2.9.1, which could help with AVC.  But I'm nervous testing something new this late in the game.  If I crash this close to the event, won't be good.  I don't want to miss something in the setup that I need to be doing.

Olivier, what exactly are the symptoms of this accel calibration problem?  

I used to get problems like this last summer.  It was weird, sometimes it would just boot up completely strangely.  IIRC, it resulted in extremely sluggish response of the IMU.  Never figured out the cause.

--

[Olivier ADLER]

The symptom is an offseted level, in my case about 30 degrees.

I did try to take off like this, and the propellers did almost touch the ground. So i did stop, try disarming and rearming, but same problem.

I did power off, (battery disconnect), power on and level was again perfect.



I ask myself if this problem could be induced by the copter vibrating or slightly moving after battery connection. When i try to keep it perfectly stable after battery connection, i think that the problem may never occur, but i'm not sure about this assumption.


Olivier.

[Andy Newman]

Hi.

I have installed RC4 from MP and most things are working great.  Loiter is very tight, Circle is a big improvement from 2.9.1b and Alt Hold is working great.

I have noticed a few things that seem odd.

   1. GPS Home position is out by approx 4 metres north from my true home position.  Same exact location with 2.9.1b always had it to within 1 metre.  Possibly bad GPS conditions today but worth noting.

   2. I have noticed a small but noticeable yaw to the right that builds up in stabilize and loiter and alt hold. (not tried other modes that it would be noticeable in) Also sometimes just after switching to Loiter it will yaw to the right about 10 degrees with no input from me.

   3. There is a small kick when going from loiter to circle and back again.

All the above have been repeated across four 7 minute flights.

Other than the above, great work and I for one am very grateful of the time and effort you all put in.

Using RCTimer apm2.5 

ublox gps

External compass

Attopilot 90a

3s 2200mah lipo

HK telemetry radio (3dr clone)

RCTimer 30a esc's

RCTimer HP2212-1000kv motors

Flamewheel clone quad frame

Compassmot reported 10% at full throttle

Vibration very low and well within specs

Andy.

[Olivier ADLER]

Seems like you have a normal GPS error today.

Even with SBAS reception (WAAS or EGNOS) the garanteed absolute position error is 7.6 meters horizontal or vertical.

So your error is well below this threshold.

To get SBAS corrections, you need to wait between 5 - 10 minutes before take off and your location must be in a SBAS coverage area.


Without those corrections, the GPS absolute precision is not better than about +/- 5-15m 95% of the time. With SBAS it is around +/-1-3m 95% of the time with a max value at 7.6 m.


Your Yaw problems seems more like magnetic interferences or mag offset problems.


Olivier.

[DanielB]

Greetings.

On the subject of GPS accuracy, coverage and issues, let me just share this website that I found covers very well the subject.

Thanks for bringing it up, Olivier.

All the best.
Daniel

[Rick Payne]

rc4 flies very well on my hexacopter. 2 comments only. Circle is very slow - what do I tune to increase the speed? RTL is quite steady, but that suites me.

The only issue is that when I go from Loiter->Circle - I get a very big twitch.

Apart from those, I'm loving rc4 on the hexacopter.

Thanks for all the hardwork ;)

Rick

[Olivier ADLER]

This manufacturer is a "low" cost high accuracy GPS manufacturer.

Unfortunately the last time i did check for the price of their L1-L2 receivers it was between 2000 - 3000 $...

Or you could pay eventually  1500 $ / year for an Omnistar G2 subscription. (10 cm realtime precision).


On a similar subject, for those interested, i was able to switch the LEA-6H to GLONASS reception.


Unfortunately the LEA6-H is not able to receive GPS and GLONASS at the same time. You must choose between one of the two constellations. Having GPS and GLONASS at the same time is very good for FIX availability in difficult receive conditions.


Eventually using two LEA6-H, it should be possible to merge their output for a more reliable fix and perhaps smooth a bit more the position.


Olivier

[Steve Ball]

Oliver and all,

I have something very similar which I've never seen before in previous builds or 2.9.1b. 

Spec:

F450 clone

RC timer 30A SimonK firmware

1000kV motors

10X4.5 carbon blades

3DR/RC timer telem 433MHz

90A attopilot

MinimOSD

200mW video transmitter

When I connect my battery to the quad, everything boots up BUT I see the Mav link pulsing via the video link but no live data. The only time I get live data is when I click connect on my 3DR radio then both seem to work fine. When its in this not quite running right state I can arm it and power motors but I haven't tried taking off. The symptom's are it always shows North on the minimOSD and the voltage was completely wrong on a freshly charged battery. I don't know if the 3DR link is a relevant or not or something like Oliver saw.

Other things I've noticed.

Loiter repositioning is now fantastic, works exactly how you'd expect it to, loiter is incredibly locked in.

Auto flies well but I feel the stopping at waypoints and turns at them could be calmed down a bit as they seem abrupt even when the WP_speed is low (400cm).

RTL. I thought the idea was it'd land at the same heading it was at when it was armed, This didn't seem to work for me.

I'm attaching a few telem logs from this evenings flights and a screenshot of how good loiter was.

Keep up the good work all,

Steve

[Olivier ADLER]

Steve, the MinimOSD is asking for mavlink Data through its TX line at power on. But because you have a 3DR radio, this MinimOSD TX line is not connected, hence the behavior you are seeing : missing mavlink stream until you connect from Mission Planner.

This is a known problem with Arducopter. For Arduplane if i'm right, Mavlink requested streams are memorized across reboots so that you don't loose those parameters if you have a MinimOSD and a 3DR radio at the same time.


A solution to that is to put a 2 position hardware switch, to switch between the MinimOSD or 3DR Radio TX lines if you are not using the 3DR radio.

Another simpler solution would be to fix that in the Arducopter firmware.


Olivier

[Glenn McLelland]

The SR0 data rates need to be set in the advanced parameter list to enable the MinimOSD to be updated without connecting to mission planner using telemetry. Below lists SR3 ones too, but I think it is just the SR0 ones that need to be set for arducopter.

[Olivier ADLER]

Ok i understand now why it was not working for me when i did try that. I was trying to set SR3 parameters instead of SR0 ones !

See here :

https://code.google.com/p/arducam-osd/wiki/Troubleshooting

I think we do not have those informations in the Wiki.


Thanks Glenn for pointing this.


Olivier.

[DanielB]

Steve. 

Thanks for sharing your flight.

 I just ran the log (2013-06-02 20-53-23) on your auto flight and looks pretty impressive: lines are straight and on track, wind compensation seems good (you seem to be having a good north wind indicated by the constant tilt against the direction), altitude seems linear with takeoff steady ascent to 20 increasing to 40 for most of the flight legs, and decreasing back to 20 on your final leg, then landing looks pretty good to home (what, couldn't be more than 3 to 4 m off target) and speed is steady across 2 football and 2 moto-x fields (if I'm not mistaken, ...nice place BTW).

Wow. Congrats. (Builds my confidence to go for auto flight, weather permits..;-).

All the best.
Daniel

[Steve Ball]

Daniel and all,

Close, they're RC car tracks :-)

Oliver, I've never noticed that issue in 2.9.1b, it worked regardless of whether the 3DR was linked or not. I really don't want to lug my laptop everywhere just to fly.

Randy, is there anything I can change?

Thanks

Steve

[Steve Ball]

Sorted, I didn't see the post about the SR0 settings until afterwards, I merged my params from 2.9.1B and working perfectly.

Thanks all, this build is looking fantastic the developer's should be proud of their achievements.

Cheers
Steve

[Olivier ADLER]

Something that could explain why i have sometimes my accelerometers fully off after init, is that i'm using a PPM SUM output receiver since a few weeks.

Eventually this could produce AVR 2560 interrupts later or sooner compared to the PPM encoder. My RC receiver boot delay is certainly different compared to the boot delay of the PPM encoder.

This could have an effect during the AVR2560 init causing a problem initializing the accelerometers.


This is pure assumption.


Olivier.

[Heino R. Pull]

Three flights of RC4 on my Jdrones quad (downloaded from MP). Flew all three completely in Loiter and no issues at all.  Solid hold in loiter with 5 mph winds. Repositioning very responsive and improved over RC3. Video transmitter and GoPro onboard with no issues. Tried RTL once and it seemed to go well but I aborted when the quad lowered onto the drifting GPS home position on top of a tree. No weird random horizontal translations - PPM firmware definitely fixed this. Yaw absolutely locked on. Area too small to try auto tests, but quite a bit of FPV flying from GoPro video with absolute confidence in a stable loiter. Best firmware yet - congrats to the developers.

Heino

[Randy Mackay]

Rick,

     The CIRCLE_RATE parameter allows you to adjust the turn rate in degrees/second.  You should be able to make it negative and have it turn in the opposite direction....although now that I think about it..we haven't tested this since Leonard and I made all those fixes a few days ago...making it negative will cause a problem i think.

     You can also set CH6 Opt (on ArduCopter Config page of mission planner) to CH6_CIRCLE_RATE so you can adjust it in flight.

-Randy

---

From: Rick Payne <rap...@gmail.com>
To: drones-...@googlegroups.com
Sent: Monday, June 3, 2013 2:31 AM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

Andy,

     Re the slight yaw...I'm really not sure what that is but it could be that the copter is unable to maintain is yaw maybe because one of the motors is weak or something.  Could you do a level hover in stabilize mode with the MOTORS dataflash logging turned on and then post the dataflash log file here?  We can look at the individual motors and see if two of them are working much harder than the other two.

-Randy

---

From: Olivier ADLER <cont...@nerim.net>

To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Monday, June 3, 2013 3:18 AM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Chester]

Yesterday I tested rc4 on my px4 hexa. All looks almost perfect. I like pre arm checks very much. All settings as before was stock. But noticed one issuse and one almost issue.

Almost issue - alt-hold and loiter become some vertical wobbles. On rc1 haven't got then. The only HW change was I flied without gopro (so about minus 94g of weight)

And the issue I noticed that rtl land speed was much more bigger then 50cm/s that was in settings. I think i was about 1-1.5m/s. That is why my hexa touch the ground and then jump again instead of loitering in 2 m height. There was only one time when it stop descent and hover near the ground. Any way you can see it in logs. On rc1 land speed was ok.

[Randy Mackay]

Daniel,

     I don't think you will have problems with the board voltage check with the way you're powering the system.  Should be a-ok.

-Randy

---

From: DanielB <dber...@gmail.com>

To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Sunday, June 2, 2013 11:56 PM
Subject: Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

Chester,

      There's a feed-forward in the alt-hold now.  It makes it more responsive but it also can cause jumpiness in the alt hold.  Could you try adjust the Alt Hold P down to perhaps 1.0 and see if that helps?

-Randy

---

From: Chester <anton....@gmail.com>

To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Monday, June 3, 2013 12:22 PM

Subject: Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Chester]

Hi Randy,

Thanks you for adwise. I will test it ASAP.

What do you think about second issue about landing speed? Does anyone got this issue too? May be it appers only on px4?

[Randy Mackay]

Chester,

      Do you have foam over the baro on the PX4 or is it possible that it's quite exposed?  The baro alt is moving up and down quite a lot but only when you're near the ground strangely.  I'm guessing that there is a lot of air disturbance as the wash from the props starts blowing back up at the copter....

-Randy

---

From: Chester <anton....@gmail.com>
To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Monday, June 3, 2013 12:31 PM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- alt hold wobbles

[Chester]

Look like you rigth. I have no foam. But all boards covered with half of acrilic sphere. May be it's not enougth. I'll try to add some foam before to lower ALT Hold P and retest if rain stop.

Do you think it can reduce land speed also or this issue have another reason?

[Randy Mackay]

Chester,

     The LAND_SPEED parameter is already at 50cm/s and can only be set as low as 20cm/s.  I don't think reducing it from 50 will help much, better to focus on sorting out why it's climb rate estimates are off (i.e. probably the baro).

-Randy

---

From: Chester <anton....@gmail.com>
To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Monday, June 3, 2013 1:15 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- alt hold wobbles

Look like you rigth. I have no foam. But all boards covered with half of acrilic sphere. May be it's not enougth. I'll try to add some foam before to lower ALT Hold P and retest if rain stop.

Do you think it can reduce land speed also or this issue have another reason?

On Monday, June 3, 2013 9:54:48 AM UTC+6, Randy Mackay wrote:

Chester,

      Do you have foam over the baro on the PX4 or is it possible that it's quite exposed?  The baro alt is moving up and down quite a lot but only when you're near the ground strangely.  I'm guessing that there is a lot of air disturbance as the wash from the props starts blowing back up at the copter....

-Randy

---

From: Chester <anton....@gmail.com>

To: drones-...@googlegroups. com
Cc: Randy Mackay <rmac...@yahoo.com>
Sent: Monday, June 3, 2013 12:31 PM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- alt hold wobbles

[Andrew Chapman]

On 2013-06-02 5:31 PM, Olivier ADLER wrote:
>
> Something that could explain why i have sometimes my accelerometers
> fully off after init, is that i'm using a PPM SUM output receiver
> since a few weeks.
>
> Eventually this could produce AVR 2560 interrupts later or sooner
> compared to the PPM encoder. My RC receiver boot delay is certainly
> different compared to the boot delay of the PPM encoder.
>
> This could have an effect during the AVR2560 init causing a problem
> initializing the accelerometers.

I've hit this quite a few times, and I don't use PPM SUM. These days I
always fly with telemetry and check the HUD is level before takeoff, but
in the past I've had a few scary aborted takeoffs because of it. Novices
would flip in these cases for sure.

Your post reminded me I was going to suggest as another pre-arm check
that it only arms if the copter is within some threshold of level (15
degrees?). That way even if it is confused you're still within range of
manually controlling it back again for a safe landing, whereas I've seen
it arm with more than 45 degrees offset, which means even full stick in
STAB mode won't get it level again if you took off like that.

If we did put this check in we'd need to consider the outlier case of
in-flight disarming. As it only seems to affect the first arming after
power-on, perhaps that's just a state variable to maintain - only do the
pre-arm check if it is the first time we've armed since powering up.

AC.

[Olivier ADLER]

I suspect that the PPM input interrupt is causing that if it is not disabled during sensors init.

I did ask to Tridge to check that, or let me know where to find this in the code.

If we check level before arming, then it will be impossible to take off from a non level surface. In my case, the offset was about 25-30 degrees off. If we did put a safety check at 45 degree this would not have been detected and would have caused a flip for a beginner.

It's better first to find the real cause of this.

This could be as well a power glitch at power on causing a memory corruption in a CPU or sensor.


Do you have a 3DR power module ? I don't have one on this machine.


Olivier

[Graham Dyer]

I just had a quick test fly, very nice! Great to be able to actually fly in Loiter and release the sticks and the quad just stops and 'waits'!

Haven't been following the development closely for a few weeks so a few quick questions, does one still have to do the CH6 declination tuning or is auto-declination sufficient? I left mine on the old tuned setting but did have a little gentle toilet bowling about 3/4 through the flight.

Also I had some gentle uncommanded yaw changes during Loiter, yaw changes on full descent in Alt Hold and one unusual 450 deg rotation which I assume is all DC magnetic interference, so can someone remind me please as to how does one tell what caused them from the tlog?

thanks

Graham

[Robert Lefebvre]

Do you guys have to do any tuning of parameters with 3.0?  Auto/Loiter PIDS?  Or is the upgrade from 2.9.1 pretty much plug and play?

[DaveC]

I'm running the same params as 2.9.1, just check your vibes are acceptable, and use all the new default auto and loiter PID's. You should be fine and dandy. You may want to hardcode slightly faster accelerations in auto, like leonard mentions in his AVC thread. but start with the defaults.

I on the other hand have just totalled my competition machine - doh! Had 4 perfect landings, then the 5th one bounced and turned over - goddam it! 

Oh well I have the technology - and just a bit of time left to rebuild it.

[Randy Mackay]

Graham,

     re the yaw changes during full descent.  I've just found this bug today and fixed it.
             https://github.com/diydrones/ardupilot/commit/c53dca061a9919b9ed345cb75d85804d96621dab

     This and two other small bugs will mean there will be an -rc5 before the big release.  I expect to push out -rc5 soon after sparkfun.

-Randy

---

From: Graham Dyer <graha...@gmail.com>
To: drones-...@googlegroups.com
Sent: Monday, June 3, 2013 8:16 PM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

    As AC suspects, once the pre-arm check passes, it stays passed until the next reboot.  So it's not reset to failed when you disarm.

    I'm happy to add an 'are we level' check.  Is 15degrees about right?

    By the way, now that we've created the branch for AC3.0 this would appear in AC3.1 'cuz I'm planning to only put critical bug fixes into 3.0. Sure, it's a small thing but you know, we need to draw the line somewhere.

-Randy

---

From: Olivier ADLER <cont...@nerim.net>
To: drones-...@googlegroups.com
Sent: Monday, June 3, 2013 5:31 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Robert Lefebvre]

Oh, that's the one I mentioned to you a while back.

Dave, how do I go about getting the new Auto and Loiter PID's without reseting everything?

[DaveC]

Save your param file. Do a full reset and get the new params, then compare back all your old stuff.

There's probably a quicker/better way, but I like doing it like that as you get to check through everything that's different.

[Robert Lefebvre]

Yeah, OK thanks.

Bummer about your crash.  What was the cause?  

Still not sure I should attempt upgrading at this point, but I'm really tempted.  It sounds pretty solid.  And it would be helpful to fly the same waypoint mission as Randy, etc.  I pulled rc4 into my clone and will take a crack at merging in my changes.

Only problem is now there's going to be an rc5, which isn't in trunk, and I don't know how to bring those in to my clone.

[Olivier ADLER]

I'm more concerned by the init bug than trying to solve it by a check.


Do you know how much time is elapsing from APM power on to ahrs.init(); call ?

(ahrs.init(); is called from init_ardupilot() )


Perhaps we should wait a bit (1 seconde) before initilaising the MPU6000 so that power can become perfectly stable.

It could be the cause our problem here.

A small delay before previous inits could be safer as well.


Olivier.

[DaveC]

I think errant gps again, sudden change of position close to the ground. I've moved the GPS right away from everything too, checking logs and installing new one now.

I'm going to have to back off my accelerations in auto, it's just too quick to react to if anything goes wrong low down. I think I'll probably go back to leonards (the defaults) - maybe got a bit over excited there!

[DaveC]

btw i left it armed with a 3dfix for 20 minutes in a clear blue sky in the middle of a field before i took off, but had just 10 sats and HDOP of 1.4. Does this seem poor? I also noticed that i had "gps status 3" does that just mean 3d fix?

[Randy Mackay]

@Rob,

     I think it's quite late in the game to change the software you're going to run but what do I know?  ..but just from looking at the risks I'd say you could fly the code you're familiar with, warts and all..but mostly known warts.  Maybe there's a bit of an advantage on accuracy with the new code but I wonder how much additional time you'd make up with that?  ..and you know we haven't really tested the inertial nav at the kind of speeds your copter can do.  I suspect you're going to be the only traditional heli there which will wow the crowd no matter what.

     ..but if you want to move to master, I'll be merging all the changes from the trunk's ArduCopter-3.0 branch down into trunk's master branch as I do them.  The only issue if you go to master then is you'll pick up a few extra things that haven't been as well tested.  For example the RCMapper has just gone in that will allow moving the input channels for roll,pitch,yaw and throttle around which is required from some JR ppmsum receiver users.

-Randy

---

From: Robert Lefebvre <robert....@gmail.com>
To: drones-discuss <drones-...@googlegroups.com>
Sent: Monday, June 3, 2013 10:16 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

     yes, i think the gps status of 3 just means 3d fix.  2 use to mean 3d fix but we changed it.

     10sats is pretty good.  hdop of 1.4 isn't great but i've seen plenty worse.

-Randy

---

From: DaveC <da...@wylam.co.uk>
To: drones-...@googlegroups.com
Sent: Monday, June 3, 2013 10:26 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Olivier ADLER]

10 sats, HDOP = 1.4 is very good.
gps status = 3 means 3D Fix.

After about 5 minutes you should have a 3D DGPS fix, but that can be seen only with U-blox U-center PC software.

Anyway if you have 10 sats and you can't see sat count changes your position jumps are quite suspect.

Do you have mountains around ? If yes, you could try to rise the satellite elevation angle mask from 5 degrees to 15 degrees and see if this does help. This will avoid low horizon satellites to jump to frequently.


Near the ground, a GPS can be quite unreliable because of ground reflexions.


Do you have the same problems at a couple meters altitude ?

Olivier.

[Robert Lefebvre]

Yeah, that's what I don't know.  It's not worth the risk at this point?  However, there's a risk even with 2.9.1.  That's what caused my last crash.  But I guess if I'm cognizant of the weaknesses...  

I'm wondering if I can set your -rc5 branch and a separate "upstream" and just pull from it.  Because I hate to bring in a bunch of other stuff that's untested from trunk.  Ultimately, I'm thinking maybe what I come up with will become 3.0-heli. So I want it to be clean.  I'll play around with it a bit and see what I can do.

But heck, I don't even know how to compile 3.0 at this point, gotta sort that out.

[Robert Lefebvre]

You might be on to something there... I think when I had these problems in the past, I was using a large external Cap on the board, so the Vcc might have still been ringing a bit when the MPU inited?  I haven't had the problem in a long time, and I haven't used the external cap in a long time.

[DaveC]

In the past 4 days i've had about 10 big gps jumps, some at 15m, some at 7m and some at 3 alt. so not sure about ground reflections, i just looked at one log and it clearly displayed the problem, it knew it was 30m off according to the trace... strange. I'll keep digging. Hard finding the time though, I have too much to get ready! I have a day of rest in denver on thursday, i will nail it by then with any luck.

[Olivier ADLER]

We should try to put a small delay before ahrs.init().

If the problem disappear, then it does come from VCC ringing at power on or perhaps the MPU6000 not yet ready when trying to access it.

If not we certainly have a communication problem, EEPROM read problem or multitasking problem (interrupt jams) during init.



Olivier.

[Graham Dyer]

Any further on the declination, must it be manually tuned or left in auto?

[Rick Payne]

I'm running the same as I had for 2.9.1. Only difference was doing the 'compassmot' and I used ch6 to tune the declination.

[Marco Robustini]

Today i fly this trunk and this is my report sfter intensive test, i haven't found other problems, i mean AC V3 is almost ready to release for me:

1) little vibration (fast oscillations) during Loiter, only in the V3 and absent in V2.9.1, I tried to make a downgrande to verify it, I think they are induced by the controller inertial x/y, I have often pointed out but this thing has never been resolved or verified. It could also be linked to the very reactive response of the ESC's with SimonK firmware, I ask you to verify it on your quad.
2) during alt-hold if you fly too fast, for example with full ALE or ELE stick command the quad proceeds quickly but with powerful kicks to the motors and getting a lot of height, problem already reported several times, Leonard said to have a patch for this, I can not wait to try it. Also during the fast movements the quad does not maintain altitude, as I show in this video. These "motors kick" also occur during Auto missions, especially when the quad is upwind, could also be that the baro (covered with a sponge) is too exposed to pressure changes because I do not have my APM in to box and there is no canopy in this quad.

The video shows that these problems can be viewed on my Youtube channel in 30 minutes at this address: http://youtu.be/NVcuIE2y5AE
I wait your impressions and tests about this, thanks!

Bests, Marco

On Sunday, June 2, 2013 8:10:27 AM UTC+2, Randy Mackay wrote:

     I've just push ArduCopter-rc4 into the new downloads area and GitHub and it should appear in the MissionPlanner's beta links shortly.

Improvements over 3.0.0-rc3
1) loiter improvements:
     i) repositioning enhanced with feed forward
     ii) use tan to convert desired accel to lean angle
2) stability patch improvements for high powered copters or those with roll-pitch rate gains set too high
3) auto mode vertical speed fix (it was not reaching the desired speeds)
4) alt hold smoothed by filtering feed forward input
5) circle mode fix to initial position and smoother initialisation
6) RTL returns to initial yaw heading before descending
7) safe features:
    i) check for gps lock when entering failsafe
    ii) pre-arm check for mag field lenght
    iii) pre-arm check for board voltage between 4.5v ~ 5.8V
    iv) beep twice during arming
    v) GPS failsafe enabled by default (will LAND if loses GPS in Loiter, AUTO, Guided modes)
    vi) bug fix for alt-hold mode spinning motors before pilot has raised throttle
8) bug fixes:
    i) fixed position mode so it responding to pilot input
    ii) baro cli test
    iii) moved cli motor test to test sub menu and minor change to throttle output
    iv) guided mode yaw control fix

     Hopefully this will be very close to the version that becomes the official 3.0 release in MissionPlanner.  I will likely create a branch for this release shortly so that we can insulate it from other changes that will go into AC3.1.

     Sorry Marco & others, I have not implemented the always-spin-motors-when-armed feature for this release candidate.

-Randy

[Marco Robustini]

Another little problem: during autolanding sometime the quad lose the yaw position and star to rotate clockwise very slowly, the maximum error that I got is about 90°, the problem is that this thing is random, many times falls perfectly straight.

Marco

[Olivier ADLER]

Marco, after watching your video i think that i've ever heard the alt_hold problem during fast flight.

I think that it could be caused by an unadapted THR_ACCEL_P gain. THR_ACCEL_P gain is the last stage of altitude control : Converts the difference between desired vertical acceleration and actual acceleration into a motor output.

When the machine is banked a lot, power boost is needed and rise a lot motor power, changing altitude control behavior. I think we need more THR_ACCEL_P gain to get the same altitude control.


A solution would be to dynamically rise THR_ACCEL_P gain proportionally to power boost so that a tight altitude control can be kept.


Olivier

[Craig Elder]

We need to really look carefully at the idea allowing a Vcc of 4.3V

If we are going to endorse arming with that kind of range of Vcc from 5.8V to 4.3V we should at attempt to demonstrate that the board will run with a GPS, a sonar, a RFD900 telemetry radio, an air speed sensor, and a camera gimbal connected.  We already have people doing this:

http://www.youtube.com/watch?feature=player_embedded&v=7A-XVh36vjo

[Olivier ADLER]

I think that this range is too large.

Because this voltage is measured inside the AVR 2560 we should stay in this chip spec at least, 4.5 to 5.5 V, or be a bit more restrictive to keep a safety margin because of other chips, shottky diode, fuse and external devices than can draw a non negligible amount of current and drop voltage.

Powering gimbal servos connected on the APM is definitely a very bad idea and that should be explained on the Wiki. Servos can easily draw 1A or more. Strongest ones can go to about 5A or more at full load...


Technically there is no reason to be permissive, more we are dealing with flying machines.


The point is that if we choose for example 4.7V to 5.3V, this will lock a percentage of users that only 3DR can know approximately how many. I suppose a few thousand users as a first approximation.


This will produce a heavy service load on the forum and 3DR and eventually a commercial impact because of users that will not understand the technical reasons of the lock.


That's why i think that the best solution would be to have one or two parameters, for check limits, so that users can easily override those checks if they want to take the risk.


This seems to me the best solution, users will be warned with a first lock, and they will have the possibility to override the checks if they think they can take the risk to fly out of spec.


Olivier.

[Olivier ADLER]

Another solution would be a two level check :

- first permissive test : 4.4V - 5.4V -> if ok continu, if not lock arming.

- second rigorous test : 4.8V - 5.2V -> if ok do allow normal arming. If not OK delay Arming 30 seconds and forbid Auto / Guided mode.


Like this :

- users with very bad voltages will be locked

- users with acceptable voltage but near limits will be warned by an Arming delay of 30 seconds, and they will not be able to enter Auto and Guided modes

- users with good voltages will be able to fly in all modes and without arming delay.


Olivier

On Tuesday, June 4, 2013 1:12:02 AM UTC+2, Craig@3DR wrote:

[Vinicius Lara]

Forbid users to do something is a complex road.

[Craig Elder]

I think it is worse to say it is ok to do something. i.e. running a 4.301v

On Mon, Jun 3, 2013 at 5:45 PM, Vinicius Lara <sroc...@gmail.com> wrote:

Forbid users to do something is a complex road.

[Randy Mackay]

Marco,

      I found the cause of the yaw control during descent yesterday and fixed it in master and the ArduCopter-3.0 branch.  It happens when the pilot puts the throttle to zero so it would appear when descending hard in loiter or even in Auto modes.  The purpose of that check is to reset the desired heading to the current heading before you take-off.

      I've changed that check so instead of checking the pilot's throttle it now checks whether the motors are spinning or not.

      This fix will go out in -rc5.  Hopefully there won't be much time between -rc5 and the official release.

-Randy

---

From: Marco Robustini <robusti...@gmail.com>
To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>
Sent: Tuesday, June 4, 2013 6:48 AM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

--

[Randy Mackay]

Graham,

     I don't think it's necessary to tune the declination.  "Live" compass calibration + compassmot seems good enough to me at least.

-Randy

---

From: Graham Dyer <graha...@gmail.com>
To: drones-...@googlegroups.com

Sent: Tuesday, June 4, 2013 2:36 AM

Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Randy Mackay]

DaveC,

     Maybe we should bring you a replacement UBLOX GPS and cable for the competition...I'll bring a spare in any case.

-Randy

---

From: DaveC <da...@wylam.co.uk>
To: drones-...@googlegroups.com
Sent: Monday, June 3, 2013 11:27 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

[Meier Lorenz]

We managed to internally fracture the ceramic antenna of two GPS modules in two hard crashes (one was 10m free fall) - did you crash / drop the unit? The typical failure mode is that they still receive something, but with a really bad accuracy, or can't establish lock at all.

-Lorenz

------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

Am 04.06.2013 um 05:15 schrieb Randy Mackay <rmac...@yahoo.com<mailto:rmac...@yahoo.com>>:

DaveC,

Maybe we should bring you a replacement UBLOX GPS and cable for the competition...I'll bring a spare in any case.

-Randy

________________________________

From: DaveC <da...@wylam.co.uk<mailto:da...@wylam.co.uk>>
To: drones-...@googlegroups.com<mailto:drones-...@googlegroups.com>

Sent: Monday, June 3, 2013 11:27 PM
Subject: Re: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

In the past 4 days i've had about 10 big gps jumps, some at 15m, some at 7m and some at 3 alt. so not sure about ground reflections, i just looked at one log and it clearly displayed the problem, it knew it was 30m off according to the trace... strange. I'll keep digging. Hard finding the time though, I have too much to get ready! I have a day of rest in denver on thursday, i will nail it by then with any luck.




On Monday, June 3, 2013 2:38:32 PM UTC+1, Olivier ADLER wrote:

10 sats, HDOP = 1.4 is very good.
gps status = 3 means 3D Fix.

After about 5 minutes you should have a 3D DGPS fix, but that can be seen only with U-blox U-center PC software.

Anyway if you have 10 sats and you can't see sat count changes your position jumps are quite suspect.

Do you have mountains around ? If yes, you could try to rise the satellite elevation angle mask from 5 degrees to 15 degrees and see if this does help. This will avoid low horizon satellites to jump to frequently.


Near the ground, a GPS can be quite unreliable because of ground reflexions.


Do you have the same problems at a couple meters altitude ?

Olivier.


On Monday, June 3, 2013 3:26:26 PM UTC+2, DaveC wrote:
btw i left it armed with a 3dfix for 20 minutes in a clear blue sky in the middle of a field before i took off, but had just 10 sats and HDOP of 1.4. Does this seem poor? I also noticed that i had "gps status 3" does that just mean 3d fix?




On Monday, June 3, 2013 2:23:43 PM UTC+1, DaveC wrote:
I think errant gps again, sudden change of position close to the ground. I've moved the GPS right away from everything too, checking logs and installing new one now.

I'm going to have to back off my accelerations in auto, it's just too quick to react to if anything goes wrong low down. I think I'll probably go back to leonards (the defaults) - maybe got a bit over excited there!



On Monday, June 3, 2013 2:16:18 PM UTC+1, robert.lefebvre wrote:
Yeah, OK thanks.

Bummer about your crash. What was the cause?

Still not sure I should attempt upgrading at this point, but I'm really tempted. It sounds pretty solid. And it would be helpful to fly the same waypoint mission as Randy, etc. I pulled rc4 into my clone and will take a crack at merging in my changes.

Only problem is now there's going to be an rc5, which isn't in trunk, and I don't know how to bring those in to my clone.

On 3 June 2013 09:12, DaveC <da...@wylam.co.uk<x-msg://1008/>> wrote:
Save your param file. Do a full reset and get the new params, then compare back all your old stuff.

There's probably a quicker/better way, but I like doing it like that as you get to check through everything that's different.




On Monday, June 3, 2013 1:59:32 PM UTC+1, robert.lefebvre wrote:
Oh, that's the one I mentioned to you a while back.

Dave, how do I go about getting the new Auto and Loiter PID's without reseting everything?

On 3 June 2013 08:08, Randy Mackay <rmac...@yahoo.com<x-msg://1008/>> wrote:
Graham,

re the yaw changes during full descent. I've just found this bug today and fixed it.

https://github.com/diydrones/a rdupilot/commit/c53dca061a9919 b9ed345cb75d85804d96621dab<https://github.com/diydrones/ardupilot/commit/c53dca061a9919b9ed345cb75d85804d96621dab>

This and two other small bugs will mean there will be an -rc5 before the big release. I expect to push out -rc5 soon after sparkfun.

-Randy


________________________________

From: Graham Dyer <graha...@gmail.com<x-msg://1008/>>
To: drones-...@googlegroups.com<x-msg://1008/>

Sent: Monday, June 3, 2013 8:16 PM

Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

I just had a quick test fly, very nice! Great to be able to actually fly in Loiter and release the sticks and the quad just stops and 'waits'!

Haven't been following the development closely for a few weeks so a few quick questions, does one still have to do the CH6 declination tuning or is auto-declination sufficient? I left mine on the old tuned setting but did have a little gentle toilet bowling about 3/4 through the flight.

Also I had some gentle uncommanded yaw changes during Loiter, yaw changes on full descent in Alt Hold and one unusual 450 deg rotation which I assume is all DC magnetic interference, so can someone remind me please as to how does one tell what caused them from the tlog?

thanks

Graham


--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups. com<x-msg://1008/>.

For more options, visit https://groups.google.com/grou ps/opt_out<https://groups.google.com/groups/opt_out>.




--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups. com<x-msg://1008/>.

For more options, visit https://groups.google.com/grou ps/opt_out<https://groups.google.com/groups/opt_out>.



--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups. com<x-msg://1008/>.
For more options, visit https://groups.google.com/ groups/opt_out<https://groups.google.com/groups/opt_out>.



--

You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.





--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Craig Elder]

Dave you probably need one of these filters on your radio http://www.digikey.com/product-detail/en/CLPFL-0600/744-1362-ND/2339514

or an equivalent for 900 MHz 

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Marco Robustini]

Nice shot Randy, In fact think about it the problem occurred when the throttle was zero.

Marco

[Marco Robustini]

Yes Olivier, is possible, keep in mind that "alt hold" is the mode of flight used by the users, so this problem should be solved completely.
I had already tried playing with those parameters, but I never had any tangible improvements.
The problem of oscillations in Loiter has already been reported by many testers who are trying the V3 and I immediately checked during my first few test and the inertial loiter, I hope that Leonard can understand what it is.
I'm waiting Emile perform the porting of V3 on VR Brain to see if with loops much faster this thing is attenuated, appearance to fit my PX4 until the final version is out, before i want to make it work better with APM.

Bests, Marco

[Olivier ADLER]

Most car manufacturers are locking users if battery voltage is too low. Too much safety concerns with modern car electronics if battery is too low.

We are in the same situation but with flying machines.


Seems like a minimum. Lock the user to warn, and allow to override.


A simple warn in the Wiki will not be sufficient. Experience show that a high percentage of users do not follow rules (for example a lot of users are flying with strong vibrations).


Olivier

[DaveC]

Hi Lorenz, yes it's been crashed several times, it looks ok and behaves on the bench but I wonder if there is some sort of separation going on internally as it always seems to go wrong during a transition of some sort. In other words, yes i think it's knackered.

Craig, is that a filter for the telemetry or my radio gear? I don't suppose you have one lying around do you, or would anyone in the US be able to grab one easily for me that would be greatly appreciated (recompense and beer!) For info I'm using 2.4 radio and 2.4 xbees.

By the way would anyone like me to do anything at DroneCon. I sort of forgot to follow the thread but am happy to help out!

On Tuesday, 4 June 2013 07:01:55 UTC+1, Lorenz Meier wrote:

We managed to internally fracture the ceramic antenna of two GPS modules in two hard crashes (one was 10m free fall) - did you crash / drop the unit? The typical failure mode is that they still receive something, but with a really bad accuracy, or can't establish lock at all.

-Lorenz

------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

For more options, visit https://groups.google.com/groups/opt_out.





--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

[Andy Newman]

Putting restrictions in this tight is asking for problems.  

Oliver have you ever tested the voltage on your apm with a separate good quality dmm?  Also have you checked what the apm thinks the voltage is in the logs VCC?  

Personally I have a voltage of 5.25v into apm confirmed within .03v across three good quality DMM's (one being a Fluke) and the apm in logs reports an average voltage of 5.40v

According to my graph, I would get a lockout.  If this error is across the board then people with 4.65v would pass the full lock test and people with 4.25v would pass the restricted test.

If you are going to implement checks like this then the first thing that needs doing is make sure the apm knows the correct voltage.

[Olivier ADLER]

Yes, actually, i have no 3DR power module on my training / testing copter, i'm powering with the ESCs (3DR hexa B).


ESC voltage (APM output rail) : 5.021 V

APM input rail : 4.651 V

Voltage drop : 0.37 V

APM current consumption : 250 mA (with 3DR radio).

Shottky diode + fuse resistance @ 250 mA : 0.37 / 0.25 = 1.48 ohm.


The APM input rail is the voltage seen by the APM 2560.



Mesured with a Fluke 289. (DC accuracy = 0.025 %)

[Olivier ADLER]

Sorry i did forget the Logged VCC value (measured inside the APM 2560) :

VCC = 4.72.

This is only a 0.07V difference with the real value on APM VCC input rail. So i can trust this value with a confidence level of about 2 %.

Making some forum search on the subject show that reported value is around +/- 2% precision.


Because this measurement is based on the AVR 2560 internal bandgap reference voltage, we can expect a +/- 0.1V error according to Atmel specs.


VBG : Bandgap reference voltage data :

Conditions : VCC =2.7V, TA= 25 ° C

min 1.0V
Typ 1.1V
max 1.2 V



Olivier

[john...@gmail.com]

I know why we have the voltage drop between the the RC input rail and the APM, but it's kinda bad that we are breaking with the long standing R/C standard of using 5V. As an experienced R/C pilot without knowledge about APM, it would never occur to me that connecting 5V could be a problem. A 5.3v UBEC is not standard R/C equipments, and the problem is made worse since the 3DR power-module is not able to drive servos, forcing a dual power setup which is good from a technical viewpoint but hardly common practice.

- JAB

On Tuesday, June 4, 2013 3:38:36 PM UTC+2, Olivier ADLER wrote:

[Meier Lorenz]

JAB,

At the end of the day an autonomous plane is not a RC plane, and so requiring that it will *just work* if you swap the RC receiver out for it and connect power and servos as usual won't give you any decent results.

I agree that requiring 5.3V is counter-intuitive. I however don't see a safe path without dual supply. We've seen so many servo rails being pulled down during flight (at least on fixed wing planes) for shorts amounts of time, there is no alternative to provide the autopilot with a separate, trusted voltage rail. Even if you have a BEC on a multicopter, you don't want to your autopilot being browned out by a TX burst of your FPV setup.

So I think the only solution to this challenge is (for new setups / board revisions) to force people to use the power module, because all other options require luck and are by no means a controllable setup. With PX4 we've already taken that route with IO's internal supply and the expectation that people will connect it.

It occured to me that most other autopilot systems have similar requirements and have their supply either built in or as mandatory peripheral.

-Lorenz


------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

On Jun 4, 2013, at 4:14 PM, john...@gmail.com<mailto:john...@gmail.com> wrote:

I know why we have the voltage drop between the the RC input rail and the APM, but it's kinda bad that we are breaking with the long standing R/C standard of using 5V. As an experienced R/C pilot without knowledge about APM, it would never occur to me that connecting 5V could be a problem. A 5.3v UBEC is not standard R/C equipments, and the problem is made worse since the 3DR power-module is not able to drive servos, forcing a dual power setup which is good from a technical viewpoint but hardly common practice.

- JAB

On Tuesday, June 4, 2013 3:38:36 PM UTC+2, Olivier ADLER wrote:

Yes, actually, i have no 3DR power module on my training / testing copter, i'm powering with the ESCs (3DR hexa B).


ESC voltage (APM output rail) : 5.021 V

APM input rail : 4.651 V

Voltage drop : 0.37 V

APM current consumption : 250 mA (with 3DR radio).

Shottky diode + fuse resistance @ 250 mA : 0.37 / 0.25 = 1.48 ohm.


The APM input rail is the voltage seen by the APM 2560.



Mesured with a Fluke 289. (DC accuracy = 0.025 %)


Olivier





On Tuesday, June 4, 2013 1:16:44 PM UTC+2, Andy Newman wrote:
Putting restrictions in this tight is asking for problems.

Oliver have you ever tested the voltage on your apm with a separate good quality dmm? Also have you checked what the apm thinks the voltage is in the logs VCC?

Personally I have a voltage of 5.25v into apm confirmed within .03v across three good quality DMM's (one being a Fluke) and the apm in logs reports an average voltage of 5.40v

[X]<https://lh4.googleusercontent.com/-6Bk7E3PR4FQ/Ua3LGyRbezI/AAAAAAAAyaI/Q1QOZ5XlWqQ/s1600/vcc+graph.JPG>

According to my graph, I would get a lockout. If this error is across the board then people with 4.65v would pass the full lock test and people with 4.25v would pass the restricted test.

If you are going to implement checks like this then the first thing that needs doing is make sure the apm knows the correct voltage.


On Tuesday, 4 June 2013 00:56:15 UTC+1, Olivier ADLER wrote:

Another solution would be a two level check :

- first permissive test : 4.4V - 5.4V -> if ok continu, if not lock arming.

- second rigorous test : 4.8V - 5.2V -> if ok do allow normal arming. If not OK delay Arming 30 seconds and forbid Auto / Guided mode.


Like this :

- users with very bad voltages will be locked

- users with acceptable voltage but near limits will be warned by an Arming delay of 30 seconds, and they will not be able to enter Auto and Guided modes

- users with good voltages will be able to fly in all modes and without arming delay.


Olivier







On Tuesday, June 4, 2013 1:12:02 AM UTC+2, Craig@3DR wrote:
We need to really look carefully at the idea allowing a Vcc of 4.3V

If we are going to endorse arming with that kind of range of Vcc from 5.8V to 4.3V we should at attempt to demonstrate that the board will run with a GPS, a sonar, a RFD900 telemetry radio, an air speed sensor, and a camera gimbal connected. We already have people doing this:
http://www.youtube.com/watch?feature=player_embedded&v=7A-XVh36vjo

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[DanielB]

Lorenz.

On another angle, wouldn't inserting a single power module introduce a single source of failure? 

I'm just wondering how this may play, as in some of my helis and bigger planes (giant ones from 4m gliders, pattern to gas powered planes), some have as many as 4 UBEC/SBECs (some dual, with y splitters and fail-over components, to mitigate single point of failures, monitored by a separate telemetry system) powered by individual battery sources of varying capacities and with varying outputs, 5, 6, 7 and 12 volts (s) to power receiver (some dual/diverse), flight stabilization, high voltage servos, in cases of gas powered - ignitions systems, etc., as individually isolated as possible and as redundant as possible, in general, relative to the size and weight of the aircraft. 

Using this "diverse power" (sorry if I can't find a better word ;-) system throughout the years in RC has paid off in eliminating voltages related issues and potential crashes and accidents..

Perhaps what I would like to see is the capacity/functionality of APM expanded to support multiple voltage/current monitors (as many 4) with fail-safe options. I consider this as a critical requirement for APM's added value to handle bigger, heavier crafts. 

Just some thoughts.
All the best.
Daniel

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discuss+unsubscribe@googlegroups.com>.

[Meier Lorenz]

Daniel,

Yes, I agree. That's why PX4 will either survive off its internal rail or the external one (and tries to block reverse voltages and overcurrents as good as possible, so for the most obvious combinations (= to us at design time) of a shorting peripheral / supply you're safe). The current design just doesn't enforce that you have both connected, that's something that I would improve in a revision.

-Lorenz

------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

On Jun 4, 2013, at 5:28 PM, DanielB <dber...@gmail.com<mailto:dber...@gmail.com>> wrote:

Lorenz.

On another angle, wouldn't inserting a single power module introduce a single source of failure?

I'm just wondering how this may play, as in some of my helis and bigger planes (giant ones from 4m gliders, pattern to gas powered planes), some have as many as 4 UBEC/SBECs (some dual, with y splitters and fail-over components, to mitigate single point of failures, monitored by a separate telemetry system) powered by individual battery sources of varying capacities and with varying outputs, 5, 6, 7 and 12 volts (s) to power receiver (some dual/diverse), flight stabilization, high voltage servos, in cases of gas powered - ignitions systems, etc., as individually isolated as possible and as redundant as possible, in general, relative to the size and weight of the aircraft.

Using this "diverse power" (sorry if I can't find a better word ;-) system throughout the years in RC has paid off in eliminating voltages related issues and potential crashes and accidents..

Perhaps what I would like to see is the capacity/functionality of APM expanded to support multiple voltage/current monitors (as many 4) with fail-safe options. I consider this as a critical requirement for APM's added value to handle bigger, heavier crafts.

Just some thoughts.
All the best.
Daniel

On Tuesday, June 4, 2013 10:30:09 AM UTC-4, Lorenz Meier wrote:
JAB,

At the end of the day an autonomous plane is not a RC plane, and so requiring that it will *just work* if you swap the RC receiver out for it and connect power and servos as usual won't give you any decent results.

I agree that requiring 5.3V is counter-intuitive. I however don't see a safe path without dual supply. We've seen so many servo rails being pulled down during flight (at least on fixed wing planes) for shorts amounts of time, there is no alternative to provide the autopilot with a separate, trusted voltage rail. Even if you have a BEC on a multicopter, you don't want to your autopilot being browned out by a TX burst of your FPV setup.

So I think the only solution to this challenge is (for new setups / board revisions) to force people to use the power module, because all other options require luck and are by no means a controllable setup. With PX4 we've already taken that route with IO's internal supply and the expectation that people will connect it.

It occured to me that most other autopilot systems have similar requirements and have their supply either built in or as mandatory peripheral.

-Lorenz


------------------------------------------------------
Lorenz Meier
Institute for Visual Computing
ETH Zurich
http://www.inf.ethz.ch/personal/lomeier/

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<javascript:><mailto:drones-discus...@googlegroups.com<javascript:>>.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com<mailto:drones-discus...@googlegroups.com>.

[Gary McCray]

I have just produced a Safety Check page for the new APM:Copter wiki and included a link to Randy's excellent video as well as a textual break out of all of the failures and their solutions that Randy discussed on his video.

Link is here: http://copter.ardupilot.com/wiki/prearm_safety_check/

Please look it over and let me know what needs fixing.

I will be adding some illustrations.

[Olivier ADLER]

You are right John it's breaking the common practice. But...

An autopilot is not something common at all. It needs more redundancy and more safety than a conventional RC system simply because it does allow autonomous flights.

You cannot compare it to a simple RC system. In this regard we can ask a bit more to the users.

Anyway there is a simple solution to overcome the voltage drop : replace the shottky diode and the fuse by a more modern magic diode circuit based on a Mosfet transistor. Then the 1.5 ohm resistance we can see on the shottky + fuse will be reduced to something like 0.01 ohm and the voltage drop will disappear, effectively allowing the use of common 5V voltage regulators.

[Craig Elder]

The filter goes on the radio, and yes I have a couple here I will bring along.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Craig Elder]

Vinicius, we do give everybody the option to choose.  The code is open source code.  Anybody can compile and do what ever they want.

But we have a responsibility to the user and the people within crashing distance of the vehicle to be as safe as possible.  We have people now who under power their vehicles and crash and blame the code.

Having a 5.8V to 4.3V range implies that it is safe to operate between those voltages and that has never been demonstrated.

I would rather there was no qualification at all than to provide some false sense of security that it is safe to operate at 4.3V

We either have a problem with the power supply to the board or a problem measuring the voltage on the board but ignoring a safety warning is not a good plan.

[Craig Elder]

As the manufacturer of the APM 2.5, 3D Robotics does not recommend operation outside of the limits listed here:

http://copter.ardupilot.com/wiki/apm25board_overview/

Power Requirements Summary

Single Supply

Power Options	Nominal	Abs MAX	JP1 status
Power on Output PWM connector	5.37V +-0.5	6V	JP1 connected

Dual Supply

NOTE: if JP1 open, power is required on both Input PWM and Output PWM

Power Options	Nominal	Abs MAX	JP1 status
Power on Output PWM connector	5.00V +-0.5	6V	JP1 open
Power on Input PWM connector	5.00V +-0.25	5.5V	JP1 open

Warning: Do not exceed Abs MAX input voltages when connecting power supply or you will damage your board.

Warning: Connecting USB when you have input voltages at the high end of the range (near Abs Max) can damage the board. Disconnect battery before connecting USB or test input voltages so they are within the normal specified range.

The ideal voltage on the Outputs is 5.37v +/-0.0v and may not be provided by a typical ESC.

Warning: Do not exceed 6.0V DC of power supply input voltage or you will damage your board.

Measured on the 2560, Vcc should be between 4.5 & 5.5 V

[Robert Lefebvre]

You can operate on 5.0V.  Just put it directly on Vcc.  That's what I do.  Take an output from the 5V regulator onto the input rail. Just make sure that your connections are polarized.

[Randy Mackay]

Abdulla,

     In AC3.0 we've combined the loiter and navigation controllers.  So when tuning just focus on the loiter Rate and you can also increase/decrease WPNAV_SPEED, WPNAV_SPEED_UP and WPNAV_SPEED_DN.

-Randy

---

From: Abdulla Shamin <a.sh...@gmail.com>

To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Wednesday, June 5, 2013 5:42 AM
Subject: Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

Have been trying to test the new firmware... both rc3 and rc4. Any idea why my Nav WP in MP is disabled? RTL and auto is not functioning.

[Randy Mackay]

     Looking good.  A new -rc5 user bumped into this this morning so i can promise the page will be useful!

-Randy

---

From: Gary McCray <garyr...@gmail.com>

To: drones-...@googlegroups.com
Cc: Randy Mackay <rmac...@yahoo.com>

Sent: Wednesday, June 5, 2013 1:59 AM
Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

--

[Rick Payne]

So here's a video showing the twitch that I get when going from loiter to circle, and back:

  http://www.youtube.com/watch?v=PN5Xi_5SYpA

Must say that in the gusty swirling winds in the quarry, the performance was really really impressive.

On 2 June 2013 18:31, Rick Payne <rap...@gmail.com> wrote:

rc4 flies very well on my hexacopter. 2 comments only. Circle is very slow - what do I tune to increase the speed? RTL is quite steady, but that suites me.

The only issue is that when I go from Loiter->Circle - I get a very big twitch.

Apart from those, I'm loving rc4 on the hexacopter.

Thanks for all the hardwork ;)

Rick

On 2 June 2013 16:24, Olivier ADLER <cont...@nerim.net> wrote:

The symptom is an offseted level, in my case about 30 degrees.

I did try to take off like this, and the propellers did almost touch the ground. So i did stop, try disarming and rearming, but same problem.

I did power off, (battery disconnect), power on and level was again perfect.



I ask myself if this problem could be induced by the copter vibrating or slightly moving after battery connection. When i try to keep it perfectly stable after battery connection, i think that the problem may never occur, but i'm not sure about this assumption.


Olivier.

Olivier, what exactly are the symptoms of this accel calibration problem? 

[Robert Lefebvre]

Makes me wonder if the Ublox on my heli will still work well.  It probably took a pretty hard hit on the last crash.  It's mounted on the boom, and I had a boom strike.  Destroyed the boom, but the GPS did not take a direct hit.  But still it would have had a high shock force.

To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.

[Jason Short]

I flew rc5 this morning. No issues. I tried to shake it out of the sky and it didn't rise or overshoot. Feel pretty confident for Saturday. Even if I only get 2-3 test flights.

Jason

On Jun 4, 2013, at 8:17 PM, David <saras...@gmail.com> wrote:

Hi everyone,

i have just finished assembly and tuning of a quad-octo with rc5

with the right body and right tuning we got a perfect flight,

i am posting the Flight log, take a look on the last section of the flight and check IMU of the X,Y and Z.

i will be posting some pictures later and a more detailed post later as it's almost 7am here and i need some sleep after working on night on this.

it flies very well (understatement).

David.

--
You received this message because you are subscribed to the Google Groups "drones-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to drones-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

<2013-06-05 05-59 1.log>

[Randy Mackay]

Andreas, Yes, that was a bug that was fixed in -rc5. Thanks for the report..should be fixed now. -Randy Sent from Yahoo! Mail on Android

---

From: bauma...@gmail.com <bauma...@gmail.com>;
To: <drones-...@googlegroups.com>;
Cc: Randy Mackay <rmac...@yahoo.com>;
Subject: Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome
Sent: Thu, Jun 6, 2013 7:52:10 AM

Hi,   I flew RC4 yesterday. On RTL in decent state my copter starts rotating about yaw axis. This behavior was only when I put throttle stick to full down position. If I leave throttle stick in mid (hover) position then the copter hold its yaw position. I put throttle stick in fully down position because of copter should disarm immediately after landing. Decent speed is not influenced by throttle stick position in RTL decent. This behavior was exactly reproducible in all times. It seems that, if throttle stick is in down position, yaw stabilisation is not in function. although horizontal stabilisation works. Would You please check this.   Regards, Andreas.

[Rick Payne]

The yaw issue was fixed in rc5:

ArduCopter 3.0.0-rc5 04-Jun-2013

Improvements over 3.0.0-rc4

...

3) bug fix to heading change in Loiter, RTL, Missions when pilot's throttle is zero

...

--

[Randy Mackay]

Yes. A known issue in -rc4. Fixed in -rc5

Sent from Yahoo! Mail on Android

---

From: bauma...@gmail.com <bauma...@gmail.com>;
To: <drones-...@googlegroups.com>;
Cc: Randy Mackay <rmac...@yahoo.com>;

Subject: [drones-discuss] Re: ArduCopter 3.0-rc4 in the downloads area -- all feedback welcome

Sent: Thu, Jun 6, 2013 7:52:10 AM