search

MegaPirateNG / ardupilot-mpng

MegaPirateNG
GNU General Public License v3.0
117 stars 105 forks source link

Board hang when increasing throttle (Auto disarm) #3

Closed SirAlex closed 10 years ago

SirAlex commented 11 years ago

If your board hang when you increasing Throttle in armed state (Looks like motors switch off when you pass 30-40% of throttle). Please, post here this information:

  1. MPNG version:
  2. Board type (RCT Crius v1,v2, HK... etc):
  3. ESC type
  4. RC Receiver type and how you connected it to board (PPMSUM, PWM):
  5. How you power board(ESC, BEC...):
  6. What also you connected to board (OSD, modem...)
  7. If any logs(I'm prefer from board if available), video available, please post it here:
icsss commented 11 years ago

Is there a way to disable the on-board compass by code in 3.0.1 R2?

SirAlex commented 11 years ago

You may try R3 or use MPU6000_I2C file from it. In MPU6000_I2C driver you can find define which disables internal MAG. Latest R3 code available here at GitHub: https://github.com/SirAlex/ardupilot-mpng/tree/mpng-3.0.1-r3

hoppa123 commented 11 years ago

SirAlex

You very well may be right. Because with my 4 crashes yesterday which lost my copter in lots of pieces it was all back related to the Mag field. Also when i installed the firmware the board didnt want to arm because the MAG parameters were wrong. May i ask did you change alot in the library's of the magnetic field ?

claytonc2001 commented 11 years ago

I'm not understanding why this wouldn't be a problem in 2.9 but is in 3.? Surly this can be fixed without having to restructure/rewire the quad.

hoppa123 commented 11 years ago

Ofcourse it can be fixed. it isnt a hardware issue. its a software issue. that is why i was asking if there is alot changed in the mag code so i can take alook too.

claytonc2001 commented 11 years ago

Maybe you can compare the code from 2.9 and 3.0.1 R2 and see if you can find the issue. SirAlex has done one hell of a job on MegapirateNG and looks as though he may be spreading himself a little thin so any help you can provide would surely be appreciated by all of us.

hoppa123 commented 11 years ago

The problem is that it is all related code. Its quite a haystack to dig in to. I have already start working on analysing the code. but its indeed a hell of a job that mr SirAlex did ( very appreciated piece work of art )

c-bob commented 11 years ago

One other thing to get the vibration relation supported: Yesterday I had a broken prop in air (around 20m) but many luck to get my hexa landed. BUT as I had it on the ground I forgot to disarm in all the excitement and because of the adrenalin - after a few seconds the motors starts to spin up (I did not touch the RC!) without the possibility to slow them down via the RC. The only thing was to get to the battery connector to disconnect them but because of a broken leg it was very difficult to hold the whole copter with one hand down and reaching the connector with the other hand. Finally I managed it :) I think it can be because of the hard landing an the extreme vibrations because of one missing prop-wing.

Maybe the logs from this flight can bring more light into this bug. I'll send them to @SirAlex later the day

hoppa123 commented 11 years ago

Its strange. because if the board would hang the PWM signal to the ESC's will not be there anymore. as they are generated by software as far as i know. This would mean a total diffrent problem if your copter descides to take off. i had this however before nearly lost the quad, found it after search for 2 days. when i looked into that exact problem as you telling me it was the reciever which had died on me. it was a cheap DSM reciever. I assume your board was still alive seeing the LED's

hoppa123 commented 11 years ago

It must be more far in the software than its a magnetic issue. I was be able to trip the board in a test setup by running the board at 40 percent throttle and then switch to loiter back to manual and back to loiter and then suddenly the board tripped.

I hope tomorrow to get a dump of this issue and post it

SirAlex commented 11 years ago

Sorry for delay, I'm was in little trip in Vilnus.

I'm think, the main problem is CPU power is not enough to process all code. Look like board hang when code take more time to calculate something than expected. For example, switching between modes, compassmot... The main symptom to detect when CPU is running out of resources - when telemetry stop or very slowly refresh. It's because sending telemetry has low priority in Scheduler so CPU just skip it to run High priority task like stabilization. This problem not related to MPNG. The APM has this problem too. But since his sensors running on SPI bus, it work faster than MPNG. In order to get same bug, you must use Octo configuration and enable Mount or other code which consume CPU power. APM team known about this problem and talked abou it here:https://groups.google.com/forum/?fromgroups=#!topic/drones-discuss/xhJAD9SEO2w

So, I think, it's not really possible to maintain code same with APM, we just has not power to run it. Maybe we must cut some unused features in order to offload CPU...

Regarding this bug. Some users can reproduce problem with just fixed magnet. So its 100% related to magnetic field. I'm trying to find solution, but my problem as always - I cannot reproduce it.

hoppa123 commented 11 years ago

I have came to the same conclusion as i looked into the code. i have measured yesterday with a milliamps measurement when i flash the CPU with code which is stress it at 100 percent the same amount of power is used as when the 3.0.1 code goes to arm mode. You might be able to free some resources by putting several non essential codes in wait for a few clock ticks which can free the cpu. also what might help is to pipe several instructions in line so they are not causing too many interrupts to the cpu.

i think personally when the board crash we have a stack overflow or something like that. logs must clear this up.

c-bob commented 11 years ago

After some research on my crash on staurday I found out, that something is wrong with my Rx ( @hoppa123 ) - it is not bind to my transmitter anymore and I can not rebind it - so far just for information. But on the other hand: why did it spin up after some seconds as it was landed and motors stoped before (not disarmed as far as I remember)??

Well and to the cpu-power-problem: isnt it the time to switch over to a new processor? Well arduino is a nice piece of hardware, but ... for a flying machine with a bunch of features maybe it is not powerfull anymore... And other cpu's are as cheap as the atmegas (like the stm32 e.g.)

Ah, another question came to my mind as I've read @SirAlex statement: what leads to the decision to use only i2c and not spi on crius? Do you know it? As far as I remember a while ago you wrote in RCgroups, you know the developer well - so whats his statement?

SirAlex commented 11 years ago

@c-bob About STM32: 3DRobotics(DIYDrones) working on it's STM32 platform: PX4/Pixhawk/Iris. So there is already STM32 version of ArduCopter. Some Russian guys developing alternative STM32 board. I hope we will have ability to run ArduCopter(MPNG) code and MultiWii(baseflight), and maybe other code. Currently the board in development so I'm not announce it.

CRIUS: I2C selected since board developed not only for MPNG, it must run MultiWii too, but it's not support sensors on SPI bus. I'm cannot contact with Crius developer since Jan 2013... so looks like this board is dead (I mean no more versions will be).

So, It's time to go to STM32 world. But I'm still trying to fix issues in AVR code and to release new versions.

c-bob commented 11 years ago

Well stm32 seems to be the base for many other projects. Timecop made his naze32 (with ported multiwii code iirc); the openpilot guys are doing their board, taulabs is the alternative to it; uavpNG are switching to stmf4 (btw: there is only one codebase for all their hardware revisions - 5 different boards atm); 3dr has its pixhawk etc.

Unfortunately I can not evaluate how big is the effort to port the mpng code to a stm-platform...

Hehe, my wish is, that all the hardware specialists are working together - as they are using almost the same sensors - to get a "standard" stabilized navigation platform. The firmware can be made on different ways - so every project can develop and follow its own ideas and ways. But thats just the wish ;)

AndyBorg commented 11 years ago

Please, post here this information:

  1. MPNG version: 3.0.1 R2
  2. Board type RCT Crius v2
  3. ESC type Turnigy opot 20R
  4. RC Receiver type and how you connected it to board : Graupner Hot PPMSUM MX 16
  5. How you power board : BEC
  6. What also you connected to board : Externel Compass on S3 ; BlueTooth Modul; 3DR GPS;
  7. If any logs(I'm prefer from board if available), video available, please post it here:

I flew with my Quadrocopter in loiter mode, then I just flew in Stable mode. First, the rear of Motor stops. (Plus configuration). Then the whole copter crashed.

i use a external compass...

I have a log file. how can I upload the ZIP File ? Update: I have sent you the log to your email address..

c-bob commented 11 years ago

Well, maybe there could be seen something in the logs but it seems to me like a esc failure or a motor failure (maybe a short in the coils...)

c-bob commented 11 years ago

@SirAlex : have you seen: https://groups.google.com/forum/#!topic/drones-discuss/VCC14ZTrdCc

hoppa123 commented 11 years ago

@c-bob This looks very promising. I think this patch can easily be put into the code of MegapirateNG

SirAlex commented 11 years ago

@c-bob Thanks for info. I will implement this fix in MPNG asap.

Actually, current R3 works faster than R2 and I hope, with this fix we well solve issues with CPU overruns.

hoppa123 commented 11 years ago

@SirAlex

This would be f*cking brilliant. Do you have a DL link of the current source snapshot so i can take a shot and patch this myself as well ? as matter of test

SirAlex commented 11 years ago

R3 beta available here at GitHub: https://github.com/SirAlex/ardupilot-mpng/tree/mpng-3.0.1-r3 (On right side, you can find "Download ZIP" button)

hoppa123 commented 11 years ago

Thanks for the prompt reply. I will pull the code ,patch this one and let it run in the simulator to see if i can get it to crash again.

I will post the results here during this week !

c-bob commented 11 years ago

Nice Alex! Thanks!

chsw commented 11 years ago

Since I reconfigured my quad to a hexa, I haven't been able to fly properly in loiter. It's been very responsive in stabilize, reasonable in althold (jerky climbing) and almost unable to climb in loiter.

I tried 3.0.1r3 with the scheduler-patch above, and suddenly, I could control altitude in loiter with no problems at all.

There was some jerkiness to it, and it took its time to come to a halt in loiter, but I suspect its just a matter of tuning. I had fiddle a lot with the tuning before this patch to be able to have some degree of control over altitude in loiter, so I suspect I need to re-tune it now when it performs as it should.

c-bob commented 11 years ago

Seems to be too much vibrations. Do you have mounted your fc on a vibration dampening base? Do you have balanced your props and motors well?

AndyBorg commented 11 years ago

Today I have made ​​ my first flight experience with the new 3.0.1r3 with the scheduler-patch above. I could fly two battery charges without problems.I am very often changed between the flugmodis. Loiter / RTL / Stabi. It looks like a good version. Great Job

SirAlex commented 11 years ago

Thank you for feedback. But R3 has no this scheduler-patch. I'm made some other performance optimizations. I'm decide to freeze development on R3 due to high differences with current 3.1 and to dont doing porting twice. So I'm started to port 3.1-rc4 with all optimizations mentioned above.

But yes, looks like R3 good version.

chsw commented 11 years ago

I downloaded the latest R3 (as of yesterday) and applied the scheduler-patch myself. Just to see if it was the performance-fix my hexa needed. Since your changes to r3 in combination with the scheduler patch made my hexa work again, I'm looking forward to 3.1.

sosko71 commented 11 years ago

Can you give link for that patch please.

chsw commented 11 years ago

It isn't really a patch. I just copied the ap_scheduler files from the ardupilot repository to my mpng-copy and compiled/uploaded.

JamesxL commented 11 years ago

when talking about "the patch code", if i understand correctly, is to replace mpng scheduler with this one from official source code? [code] static const AP_Scheduler::Task scheduler_tasks[] PROGMEM = { { throttle_loop, 2, 450 }, { update_GPS, 2, 900 }, { update_nav_mode, 1, 400 }, { update_batt_compass, 10, 720 }, { read_aux_switches, 10, 50 }, { arm_motors_check, 10, 10 }, { auto_trim, 10, 140 }, { update_toy_throttle, 10, 50 }, { update_altitude, 10, 1000 }, { run_nav_updates, 10, 800 }, { three_hz_loop, 33, 90 }, { compass_accumulate, 2, 420 }, { barometer_accumulate, 2, 250 }, { update_notify, 2, 100 }, { one_hz_loop, 100, 420 }, { gcs_check_input, 2, 550 }, { gcs_send_heartbeat, 100, 150 }, { gcs_send_deferred, 2, 720 }, { gcs_data_stream_send, 2, 950 },

if COPTER_LEDS == ENABLED

{ update_copter_leds,   10,      55 },

endif

{ update_mount,          2,     450 },
{ ten_hz_logging_loop,  10,     260 },
{ fifty_hz_logging_loop, 2,     220 },
{ perf_update,        1000,     200 },
{ read_receiver_rssi,   10,      50 },

ifdef USERHOOK_FASTLOOP

{ userhook_FastLoop,     1,    100  },

endif

ifdef USERHOOK_50HZLOOP

{ userhook_50Hz,         2,    100  },

endif

ifdef USERHOOK_MEDIUMLOOP

{ userhook_MediumLoop,   10,    100 },

endif

ifdef USERHOOK_SLOWLOOP

{ userhook_SlowLoop,     30,    100 },

endif

ifdef USERHOOK_SUPERSLOWLOOP

{ userhook_SuperSlowLoop,100,   100 },

endif

};

[/code]

SirAlex commented 11 years ago

@JamesxL , No, you need to replace AP_Scheduler entire folder

JamesxL commented 11 years ago

Is RC4 port has this in place already? On Oct 18, 2013 4:13 PM, "Aleksey Kharlanov (Sir Alex)" < notifications@github.com> wrote:

@JamesxL https://github.com/JamesxL , No, you need to replace AP_Scheduler entire folder

— Reply to this email directly or view it on GitHubhttps://github.com/SirAlex/ardupilot-mpng/issues/3#issuecomment-26630231 .

SirAlex commented 11 years ago

3.1-RC4 not yet finished. I'm made technical commit to not lost work. Please do not try it.

JamesxL commented 11 years ago

acknowledged, i flew it a bit earlier, it felt alright. but I will revert to older version per instruction. which commit is safe to revert to?

On Fri, Oct 18, 2013 at 4:21 PM, Aleksey Kharlanov (Sir Alex) < notifications@github.com> wrote:

3.1-RC4 not yet finished. I'm made technical commit to not lost work. Please do not try it.

— Reply to this email directly or view it on GitHubhttps://github.com/SirAlex/ardupilot-mpng/issues/3#issuecomment-26630737 .

claytonc2001 commented 11 years ago

3.1 RC4 is working on my board! It fixed every problem I was having (no calibrations working). My radio not working problem was to disable ppm.

Thank you so much @SirAlex! , I wont fly until you approve the new build. Motor starting when armed is a very welcome feature IMO. YES!!!

ksanislo commented 11 years ago

For anyone wanting to try the recent AP_Scheduler patch against previous versions, it's literally just adding two lines. I'll be trying it out tomorrow against 3.0.1 R2, but in case anybody else doesn't feel like waiting for me to get back from the field with the results, here's the link.

https://github.com/diydrones/ardupilot/commit/0f4da25e682f69e9b897fe63157fa1bc31765157#diff-dc724695c1c8ec3cf4c2d24011a22fe8

edit: Patching looks like it might be a bit more complicated than just using that diff on the prior versions. Other things need to be backported a bit to use it. That's a shame, at first glance it looked like it would be nice and simple to use.

JamesxL commented 11 years ago

My attempt resulted the same AIOP 2 quad. On Oct 19, 2013 12:14 AM, "ksanislo" notifications@github.com wrote:

For anyone wanting to try the recent AP_Scheduler patch against previous versions, it's literally just adding single line. I'll be trying it out tomorrow against 3.0.1 R2, but in case anybody else doesn't feel like waiting for me to get back from the field with the results, here's the link.

diydrones/ardupilot@0f4da25#diff-dc724695c1c8ec3cf4c2d24011a22fe8https://github.com/diydrones/ardupilot/commit/0f4da25e682f69e9b897fe63157fa1bc31765157#diff-dc724695c1c8ec3cf4c2d24011a22fe8

— Reply to this email directly or view it on GitHubhttps://github.com/SirAlex/ardupilot-mpng/issues/3#issuecomment-26643692 .

ksanislo commented 11 years ago

JamesxL: You mean the same, as in the board hung while flying even after replacing the AP_Scheduler folder entirely?

JamesxL commented 11 years ago

Yes.. The board did not hang. But it behaves such that the MCU is overloaded and resulting in erratic motion On Oct 19, 2013 12:34 AM, "ksanislo" notifications@github.com wrote:

JamesxL: You mean the same, as in the board hung while flying even after replacing the AP_Scheduler folder entirely?

— Reply to this email directly or view it on GitHubhttps://github.com/SirAlex/ardupilot-mpng/issues/3#issuecomment-26643888 .

ksanislo commented 11 years ago

With the replaced AP_Scheduler folder, R2 is flying fine for me. Or at least no problems apparent so far...

edw00d4711 commented 11 years ago

Hi Alex, do you continue to make "3.0.1 R2" stable or do you now focus only on "3.1-rc4"?

SirAlex commented 11 years ago

I'm focused on 3.1, but I think I will release last 3.0.1 R3 with AP_Scheduler replaced.

SirAlex commented 11 years ago

I'm just updated mpgn-3.0.1-r3, please try it. I replaced AP_Scheduler with new one from 3.1 and fixed bug with GPS port speed selection in APM_Config.h.

HSPalm commented 10 years ago
  1. MPNG version: 3.0.1 R2
  2. Board type: Crius V1
  3. ESC type: hobbywing 4-in-1 silabs type
  4. RC Receiver type: Turnigy 9X stock receiver PWM
  5. How you power board: BEC
  6. What also you connected to board (OSD, modem...): nothing
  7. If any logs(I'm prefer from board if available), video available, please post it here: sorry...

Btw, no GPS, telemetry or OSD. Have had it airborne two times and it dropped twice. Experienced multiwii pilot, but haven't had the chance to adjust PIDs here yet.

Yup, just read the entire thread and saw a solution to the problem. Will try R3 now!

Qle63 commented 10 years ago
  1. MPNG 3.0.1R2
  2. Hobby King "Multiwii and Megapirate AIO Flight Controller w/FTDI (ATmega 2560) V2.0"
  3. Turnigy Multistar 30 Amp Multi-rotor Brushless ESC 2-4S
  4. OrangeRx R620 Spektrum/JR DSM2 Compatible Full Range 6Ch 2.4Ghz Receiver w/Failsafe (now running Spectrum ar6210 with remote rx unit)
  5. TURNIGY 3A UBEC w/ Noise Reduction
  6. UBLOX LEA-6H GPS Module w/Built-in Antenna 2.5m Accuracy V1.01, Multiwii MWC FC Bluetooth Module Programmer (Android compatible)
  7. Sorry no logs

define SERIAL_PPM SERIAL_PPM_DISABLED

Comment: When throttle up, Motors cut out, RX stops responding (or board ignores it, this is why i swapped it out with a Spectrum ar6210, but same issue)

When using Multiwii 2.3, i do not have this issue (am i allowed to say that?)

Any word if R3 has fixed issue?

SirAlex commented 10 years ago

Nobody reported this issue on 3.0.1 R3 - so I'm assume it was fixed.

edw00d4711 commented 10 years ago

Alex please update the mainsite (http://www.megapirateng.com/) about the R3. First post only mentions R2. Nearly every user will install R2. Thank you!