Replies to This Discussion

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

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

Permalink Reply by Charles Winter on November 29, 2012 at 9:46am

Nice one. Apologises for not getting back to you, the notification slipped through my net.Your fix sounds a lot more permanent; I just did mine on the fly! 

Good job.

• ▶ Reply

Permalink Reply by Shyam Balasubramanian on November 29, 2012 at 10:53am

Thanks Charles. I think I must report it as a ticket on APM board, as other users may face this issue sometime, if they plan their own project using some files of APM (i.e. without using Mission Planner).

Thanks for the clue.. it helped me deal with this issue well. Btw, in GCSMavlink.pde (top line of the file), states clearly that we must use MaVLinkDelay to avoid infinite calibration (this is another small mystery though) ;)

Thanks again!

• ▶ Reply