Replies to This Discussion

Permalink Reply by Drone Savant on September 30, 2012 at 7:35am

I *think* you can use AP_ADC_test.pde to see if your Gyros are working properly. http://code.google.com/p/ardupilot-mega/source/browse/libraries/AP_...

• ▶ Reply

Permalink Reply by Raphael Diaz on October 4, 2012 at 7:47pm

when i try to compile AP_ADC_test.pde i get the following error:

AP_ADC_test.cpp: In function 'void show_data()':
AP_ADC_test.pde:-1: error: no matching function for call to 'AP_ADC_ADS7844::Ch6(const uint8_t [6], uint16_t [6])'

anyone else get that?

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on October 5, 2012 at 12:47am

I guess you have to check the parameters for this function. Compare how this function is used in main APM code (that you downloaded from Downloads of arduPlane/arducopter). I think you will resolve it that way. How is this (similar) code working on the main APM (think)!

Btw, I see some examples do not combine.. They have bugs either due to the reason that they were not comipied for(APM1 or APM2)..above solution is preferrable i guess. Let me know if you found out why!

• ▶ Reply

Permalink Reply by Drone Savant on October 5, 2012 at 4:59am

This is possible a mismatch between the librarys you have and the specific link I gave you above. There should be a functional version of AP_ADC_test.pde in with every copy of the source code that you download. I would pull the latest code and use AP_ADC_test.pde from that build tree rather than the link above. 

• ▶ Reply

JDronesPermalink Reply by Jani Hirvinen on October 5, 2012 at 2:02am

Usually if setup get's stuck it means that you have some level of hardware failure. Have you checked that PCB is intact and no other visual sings of damage? Also if you have good soldering / reflow stations you could give heat a bit for gyro / adc chips.

Btw which flight electronics you are using? AMP1x or APM2x ?

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on October 5, 2012 at 3:12am

Hi,

The problem is here:

imu.init(IMU::COLD_START, MavLinkdelay, flash_leds, &adc_scheduler);

Vs

imu.init(IMU::COLD_START, delay, flash_leds, &adc_scheduler);

Apparently, the IMU calibration gets stuck when initialized with just a delay function (pointer) with any value. It needs MavLink.

Someone any idea why this happens??

• ▶ Reply

Permalink Reply by Raphael Diaz on October 5, 2012 at 2:19pm

when i try that on the oilpan test example i get the following:

IMU_Oilpan_test.cpp: In function 'void setup()':
IMU_Oilpan_test.pde:-1: error: 'MavLinkdelay' was not declared in this scope

am i missing something with the oilpan test?

• ▶ Reply

Permalink Reply by Charles Winter on October 8, 2012 at 1:56pm

Hi Shyam.

I have just spent about half an hour trawling through the header files and have finally solved it. The problem lies in the file AP_InertialSensor_Oilpan.c

The values for _accel_scale.x, y and z are declared so as to always return 0. fix this and you should be fine.

Good luck

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on November 13, 2012 at 5:09am

Hi Charles,

I just came back to this issue. I am in the file  AP_InertialSensor_Oilpan.cpp. 

 

I see "_accel_scale.x", but I don't see that they are declared in a way to return 0. Could you please help me out what I will need to change.

 

Thanks in advance. This will help me a long way.

• ▶ Reply

Permalink Reply by Charles Winter on November 14, 2012 at 8:26am

This value is multiplied by the output of the sensors. I'm not brilliant at programming so couldn't figure out why it kept returning 0 for me, guess its something to do with floating points. You could just calculate the value by hand and stick it in when it multiplies the sensor readings, which is a few lines further down I seem to remember. thats what I ended up doing and it works brilliant ever since! 

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on November 19, 2012 at 1:41pm

Hi Charles,

For me, when I checked out the AP_IMU_INS::_init_accel(...) function in AP_IMU_INS.cpp, it shows that it goes to infinity. 

This part is really important to my project, where I am getting stuck. Could you please send me your changes so that I can apply? 

Thanks.  (email: shyambs85@gmail.com)/ via the forum, so that others may find it useful too.

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on November 26, 2012 at 12:55pm

Aha, I resolved it.

The whole issue was so simple actually. The reason is this is a BUG. If you write custom code, (i.e. not use mission planner), then the value from EEPROM are not loaded into the default variable of the classes. It results in the class variables to be 0. Yes, that's true!

What I had to do is to assign (hardcode) those values myself in the constructor, then it works. Earlier I was getting accel. values after calibration to be some -58 in Z direction. After this solution, it gives it around -9.8 under stable condition in Z direction.

Thanks for the directional hint ;)

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page