Replies to This Discussion

Permalink Reply by Simone Chiaretta on June 18, 2012 at 8:42am

What does exactly "Copter LEDs" means? I mean, I know what LEDs are :). Just wondering if it had some standard hookup diagram and/or sequence.

Or has this code been included into the "core" (http://diydrones.com/profiles/blogs/u4eake-s-showleds-arming-and-lo...)

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on June 18, 2012 at 11:56am

Robert Lefebvre has ported and consolidated various LED code bits and it is all now in the "core". Here's the relevant section in the code:

https://code.google.com/p/ardupilot-mega/source/browse/ArduCopter/l...

/////////////////////////////////////////////////////////////////////////////////////////////

//      Copter LEDS by Robert Lefebvre

//      Based on the work of U4eake, Bill Sanford, Max Levine, and Oliver

//      g.copter_leds_mode controls the copter leds function via bitmath

//      Zeroeth bit turns motor leds on and off:                                                                00000001

//      First bit turns GPS function on and off:                                                                00000010

//      Second bit turns Aux function on and off:                                                               00000100

//      Third bit turns on Beeper (legacy Piezo) function:                                              00001000

//      Fourth bit toggles between Fast Flash or Oscillate on Low Battery:              00010000                (0) does Fast Flash, (1) does Oscillate

//      Fifth bit causes motor LEDs to Nav Blink:                                                               00100000

//      Sixth bit causes GPS LEDs to Nav Blink:                                                                 01000000

//      This code is written in order to be backwards compatible with the old Motor_LEDS code

//      I hope to include at least some of the Show_LEDS code in the future

//      copter_leds_GPS_blink controls the blinking of the GPS LEDS

//      copter_leds_motor_blink controls the blinking of the motor LEDS

//      Piezo Code and beeps once on Startup to verify operation

//      Piezo Enables Tone on reaching low battery or current alert

/////////////////////////////////////////////////////////////////////////////////////////////

• ▶ Reply

Permalink Reply by Rui Manuel Cravo Marques on June 18, 2012 at 9:25am

Power comsumption is always a problem. When you add LED stripes you'll have to analyze correctlly if you have the necessary amps to power it up without disrupting the APM. Most LED stripes are 12v and there are also some 5v, however I came across an alternative wich seems to me very very good. It consumes a lot less power, and gives a "neon like" effect. During the day it will be hard to see but at night I think it will be wonderfull. I've been opening one of them and the electronics is very simple. I will try to put it in my hexa and let you know how it went. 2 small very bright LED per circuit, powered by a cr2032 3V battery and a piece of transparent silicone flexible tube :D http://www.ebay.co.uk/itm/260759349970?var=560026434652&ssPageN... 

check in here if you'd like to try some

• ▶ Reply

Permalink Reply by Joakim M on June 18, 2012 at 11:01am

After upgrading from 2.5.5 to 2.6 I can't see the remaining battery percent in Mission Planner correct anymore. This is with Attopilot 90A volt and current sensor and APM2. It starts at 23% and end at 10%. Never start at 100% as before. "Status"  display in Mission planer also tells "battery_remain 0,230". Volt is displayed correct. Anyone else have this same problem? Suggestions? I tried to load back firmware 2.5.5 and it was ok again. And same problem when going back to 2.6.

 

Today I got loiter mode to work well! This has never worked on my standard 3DR frame before! This was with stock 2.6 parameters. Problem was disturbance of compass and gps.

 

Yesterday I aligned the model straight north by comparing with a compass. In Missionplanner I could see the compass was not heading north. After several compass-learn flights I saw the offset-parameters were different each time.

I decided to move APM2 from bottom plate on frame and up to next floor in the stack to get distance from power wires. After a compass-learn flight 3DR Quadrocopter now loiter nice. I also get much faster 3D fix at the GPS. I know placing APM2 sensor out of center can have negative effects also but getting loiter to work is great!

Thank you for your work all developers and contributers!

 

 

• ▶ Reply

Wiki NinjaPermalink Reply by Gary McCray on June 18, 2012 at 11:52am

I have a problem with GPS wander which shows up when hooked up to a laptop in the flight data window.

Sometimes GPS show is correct, but usually over time it will wander around up to several hundred feet form its actual position, sometimes stopping, sometimes just continuing to wander.

Your experience certainly makes me wonder if sitting right over power distribution board could be a problem.

I am going to try additional spacing and probably a grounded sheet of copper between the APM2 and the Power Dist board.

I will post results.

• ▶ Reply

Wiki NinjaPermalink Reply by Gary McCray on June 18, 2012 at 4:58pm

Added Aluminum tape on intermediate fiberglass board between Power Dist board and APM (covered also with acrylic tape) and preliminary results are encouraging.

First sub 2 minute GPS lock ever (5-10 normal).

Too windy to fly right now, but so far it definitely seems to have improved things.

More to come.

From what Iv"e seen, 2.6 has a few issues, bet your working on 2.6.1 as I speak.

• ▶ Reply

DeveloperPermalink Reply by Andreas M. Antonopoulos on June 18, 2012 at 11:58am

Can you please make this an "issue" (bug report)?

If you can replicate the problem in 2.6, but it works in 2.5.5, please document the issue so we can fix it.

• ▶ Reply

Permalink Reply by Andrew Fernie on June 18, 2012 at 2:19pm

Joakim,

The battery remaining issue is that the scaling with Mavlink 0.9 was 1000=100%, whereas with Mavlink 1.0 it is 100=100%. The AC code wasn't updated, so overflows the 8 bit parameter provided (was a 16 bit value in mavlink 0.9). I  raised it as an issue yesterday.

If you are working with the source code, check GCSMavlink.pde and search for 1000. It will be clear what needs to change (sorry, don't have the code in front of me). However, if you make the change, you will find that the mission planner starts showing 10% and counts down 1% for every 10% of usage. A fix will likely need coordinated changes in the AC code and the mission planner.

Andrew

• ▶ Reply

Permalink Reply by Ozan Aktaş on June 18, 2012 at 2:24pm

Hi Joakim,

i had also the same issue today, uncorrect battery life percent status. It starts from %23 even i tried to change capacity of battery in mission planner. Is there a way to fix this bug?

best

ozan

• ▶ Reply

Permalink Reply by James Roney on June 19, 2012 at 12:28pm

Hi,

I also am only getting a reading of 23%, have you found a fix for this as yet?

Regards,
Solo.

• ▶ Reply

Permalink Reply by airmamaf on June 18, 2012 at 1:50pm

With arducopter 2.5.5 I managed to read Analog Pin A7, with Arducopter 2.6 impossible to read Analog Pin from A9 to A4.

I need at least one Analog Pin  to get RSSI informations, and with Arducopter 2.6, it's actually impossible

• ▶ Reply

DeveloperPermalink Reply by Randy on June 20, 2012 at 10:06am

airmamaf,

    hm...i can't think of anything that we've changed between 2.5.5 and 2.6 that would stop that from working.  Can you be more specific about what code you're adding and where?  Presumably you're using an APM2?

• ▶ Reply

• ‹ Previous
• 1
• …
• 19
• 20
• 21
• 22
• 23
• …
• 68
• Next ›
• Page