30 replies to this topic

[Josh]

I think it would be very useful if the blue light rapidly flashed on power up until the gyros have calibrated, then go to slow flashing. this could also be used as a fault test too - if it wont stop flashing fast your gyros have an an issue type of thing

cheers

Josh

[peabody124]

Problem is mathematically defining what you mean by calibrated or problem.  If you are moving at power up one mans normal is another mans problem.

[Josh]

I guess I just mean like oldie fashioned gyros flash and stuff while they are calibrating when powered up, once done the led goes solid or whatever, people (eg me) may forget the 8 second rule

Edited by Josh, 23 June 2011 - 02:31 PM.

[Kenn Sebesta]

I second this idea. Since there is a roughly 10-second period of "boot-up", let's call it, why not have the LED communicate this? We can avoid the mathematical problems by just having the different blinking be linked to the 10-second initial period, and not the calibration. The individual user can interpret the blinking the way s/he wants to, once s/he has the information in hand.

[dankers]

Kenn Sebesta, on 23 June 2011 - 02:44 PM, said:

I second this idea. Since there is a roughly 10-second period of "boot-up", let's call it, why not have the LED communicate this? We can avoid the mathematical problems by just having the different blinking be linked to the 10-second initial period, and not the calibration. The individual user can interpret the blinking the way s/he wants to, once s/he has the information in hand.

Its a 7 second delay now and I agree 100% as well, faster flash while calibrating.  All heli gyros I know do this also, just shows its in calibrate mode. I would prefer a 2 second delay before calibration starts to let people get the battery in and leave the copter alone as well.

I also think 7 seconds might be a bit long even, I have tested this with 3 seconds and saw no difference, the bias was still corrected, but that is a big change we need test well first on many boards, just in case.

The biggest cause of bad flying copters now is people not knowing they need to let it sit for 7 seconds, or moving it while plugging in the battery. In fact this information is not even that widely known as people just expect it to work.  

Should I create a Jira?

[Gary Mortimer]

I currently power the board via USB, let it work out the bias and then plugin the flight battery. Then outside I just make sure I don't move it although I am never sure if I nudged the airframe too much when plugging in the power so +1 for power on, pause then do its stuff.

[Gary Mortimer]

Either that or I train a dog to growl at me for 10 seconds so I don't move the airframe.

[peabody124]

Yeah Dave make a jira.  I also started working on some code this morning to save the gyro bias.  It's not really necessary but it will help speed up the convergence for some people.  One I have the GCS computing that value for you I'll try and get some volunteers to test this + the stabilization improvements i've made.

[CheBuzz]

I'd suggest flashing the orange LED so that people don't confuse the difference between armed (blue LED flashing) and calibrating (as I suggested, orange LED flashing)

[PT_Dreamer]

Wont that be a little difficult since that LED is tied to Vcc?

edit: better said tied to Vcc and GND

[joecnc2006]

So there is no confusion on flashing, can you have it slow flash when connected, fast flash when calibrating, and solid when ready to fly, Now with the bias already programed and not when armed, it would skip the fast flashing. and go straight to solid blue when armed.

[Gary Mortimer]

Could it flash my name in morse code, or SOS if its not working right ;-)

Once the Android GCS is more common it can of course say...

Calibrating

Ready

Oi don't move me for ten seconds until I finish sorting myself out you clown.

[PT_Dreamer]

Gary Mortimer, on 24 June 2011 - 12:24 PM, said:

Could it flash my name in morse code, or SOS if its not working right ;-)

Sure, send me some LEDs as a donation and I will get that done. Also sometimes its not the user that moves while calibrating but instead is the Universe space/time that shakes with the vision of such a fine peace of HW.

[Berkely]

peabody124, on 23 June 2011 - 09:34 PM, said:

Yeah Dave make a jira.  I also started working on some code this morning to save the gyro bias.  It's not really necessary but it will help speed up the convergence for some people.  One I have the GCS computing that value for you I'll try and get some volunteers to test this + the stabilization improvements i've made.

I think it's necessary for some people, I'm 95% of the time unable to calibrate the gyro's. A saved gyro bias is probably the only thing what would work for me.

[CheBuzz]

PT_Dreamer, on 24 June 2011 - 10:53 AM, said:

Wont that be a little difficult since that LED is tied to Vcc?

edit: better said tied to Vcc and GND

Well, green on CC is sure.  I was thinking orange on the mainboard and spaced that CC only has two LEDs, green and blue.  Scratch my suggestion as that would add a platform dependent behavior, which I always consider something to be avoided.

[alconaft43]

I would prefer MK behavior, when you to do manually throttle-up+left to gyros initialization just before the flight. In this you don't need to worry about making board and vehicle steady after battery powering up.

[Kenn Sebesta]

alconaft43, on 30 June 2011 - 12:50 PM, said:

I would prefer MK behavior, when you to do manually throttle-up+left to gyros initialization just before the flight. In this you don't need to worry about making board and vehicle steady after battery powering up.

I'll second that, esp. for having the ability to calibrate the accelerometers from the joystick, but there seem not to be enough people who prefer this way in order to justify making it SOP.

[osnwt]

Kenn Sebesta, on 30 June 2011 - 01:27 PM, said:

I'll second that, esp. for having the ability to calibrate the accelerometers from the joystick, but there seem not to be enough people who prefer this way in order to justify making it SOP.

For gyros - I do not see much reason to use  throttle-up+left - it will be done automatically when you arm it if you enabled this in the config (no need for extra action).
For accels - it depends... Usually you do that only once, so does not matter if you do that on the desk or on the field. But I agree, it might be useful sometimes.

[Kenn Sebesta]

osnwt, on 30 June 2011 - 01:53 PM, said:

For gyros - I do not see much reason to use  throttle-up+left - it will be done automatically when you arm it if you enabled this in the config (no need for extra action).

I think that there are more than just gyros that users could want to calibrate on start-up: for instance, pressure sensors (in order to establish a baseline) and possibly other sensors and counters you'd like to start at 0. These would all fall nicely under the banner of "calibrate before you go".

osnwt, on 30 June 2011 - 01:53 PM, said:

For accels - it depends... Usually you do that only once, so does not matter if you do that on the desk or on the field. But I agree, it might be useful sometimes.

My field experience in Texas reinforced my feeling that there are and will continue to be in the future plenty of instances where field calibration is necessary. It just comes down to what you're doing and why you're doing it.

[osnwt]

Kenn Sebesta, on 30 June 2011 - 01:58 PM, said:

I think that there are more than just gyros that users could want to calibrate on start-up: for instance, pressure sensors (in order to establish a baseline) and possibly other sensors and counters you'd like to start at 0. These would all fall nicely under the banner of "calibrate before you go".

All this could fall under "reset when arming" condition. Usually you'll do that before take off.
In CC there is no baro and counters. In OP Pro should be scripting which allows you to do this from your script.

Quote

My field experience in Texas reinforced my feeling that there are and will continue to be in the future plenty of instances where field calibration is necessary. It just comes down to what you're doing and why you're doing it.

James will say that you have to list those "why you're doing it" first
If there are real use cases then it might be implemented.