I got attracted here by the DCM implementations. Really appreciate the developers' gratitude to put the codes in open source. I am trying to understand the DCM code so that I could use it on our IMUs. But I got some questions with the union usage in PI_feedback() of rmat.c. No experiences with DSP programming at all.
I understand that with union, we could easily access the lower or upper 2 bytes of a long variable. But I don't understand why there are ">>3" after the multiplication and in the final assignment.
---------------------For example---------------------
union longww CorrectionIntegral[] = { { 0 } , { 0 } , { 0 } } ;
CorrectionIntegral[0].WW += ( __builtin_mulss( errorYawplane[0] , KIYAW )>>3) ;
omegacorrI[0] = CorrectionIntegral[0]._.W1>>3 ;
------------------------------------------------------------
KIYAW = 32; so what I should expect from omegacorrl[0]? Can anybody help with this?
I just received my board and did some tests. (great fun...) :-)
Just curious if there is a demo application for the IMU with PC connection (rotating cube or similar on-screen demo)?
I tried the RollPitchYaw demo, seems to work very well. However moving the board several times in conical circles it cumulates some position error. (it removes the error after the movement in calm position, it takes a few seconds)
Maybe it's because of the not perfect gyro sensitivity? The acceleratin sensor feedback deals with the gyro sensitivity calibration, or it just trims out the cumulated position errors?
I am thinking about writing some OSD code for this board. Software only, using the spi port and interrupts. Unfortunately no dma, so must handle the spi interrupts in every 1.5 ... 2 usec. The processor loading is not too high, however I am not sure if there are periods in the current software when interrupts disabled for more then about 1 usec? It so, such sw OSD can't co-exist.
I just received my board and did some tests. (great fun...) :-)
Just curious if there is a demo application for the IMU with PC connection (rotating cube or similar on-screen demo)?
I tried the RollPitchYaw demo, seems to work very well. However moving the board several times in conical circles it cumulates some position error. (it removes the error after the movement in calm position, it takes a few seconds)
Maybe it's because of the not perfect gyro sensitivity? The acceleratin sensor feedback deals with the gyro sensitivity calibration, or it just trims out the cumulated position errors?
I am thinking about writing some OSD code for this board. Software only, using the spi port and interrupts. Unfortunately no dma, so must handle the spi interrupts in every 1.5 ... 2 usec. The processor loading is not too high, however I am not sure if there are periods in the current software when interrupts disabled for more then about 1 usec? It so, such sw OSD can't co-exist.
Say you have a 12 bit ADC resolution and a full scale range of +/-8 g (just for illustration). That gives a GRAVITY value in A/D digits of 256 digits/g.
When the accelerometer is 100% vertical an ideal world accelerometer would read 256 digits on the Z axis due to gravity. If a plane rolls to the right this reading will decrease with a corresponding amount. Similarly, a decrease will also be seen when the plane rolls to the left.
If the accelerometer leans a little to one side during calibration it may read 245 for instance, the offset then being 11.Say the accelerometer leaned to the right during calibration and the plane performs a right roll, the raw value will decrease and so will the corrected value. But, and this is the problem, if the plane rolls to the left, the raw value will increase first (and so will the offset corrected value) until it reaches the full scale A/D value and only then start to decrease as it should.
From the code I can see that there is no compensation for the above and would expect it to introduce a bit of instability - specifically during roll maneuvers which centers about this incorrectly increasing window. From all the successes I read about in this forum I can only guess the the effect of this is minimal, but I would love to hear your take on this.
I have some questions about the code CORNER:
- what means this and what exactly happen in the navigation when I define CORNER?
- are there other code like this (something to define a circle, with radious and direction, or a selectable angle of turn)?
yesterday I made 4 more flights.
During the first two flights the plane, in wp mode, made anything else than I programmed, to the point I thought I was wrong again with the wp programmation.
During the 3th and 4th flight the plane made the sequence without mistakes.
I have to say that I also made two fpv flights, with another plane, and during the second I lost the gps lock (from 7 sats). The plane, equipped with a Remzibi osd, was no more able to get gps lock in flight. It only got a lock several minutes after landing.
Could this be the issue with wp sequence issue too?
Btw, I take care to set the calibrations at the best I can do, and the stabilisation was awesome (I like wery much how the imu lock the plane when going up at 45 deg and full power).
I changed the gains to have tighter turns in wp mode (Yawkp from 0.07 to 0.1, Rollkp from 0.25 to 0.15 and Rollkd from 0.125 to 0.1). The plane turn very tight but it need a bit more elevator.
I wasn't able to find the value to change this.
Do I have to change the pitch gains (I don't think so, pitch stabilisation and recover are good, until now)?
Is there another value to set right elevator vs.banking?
Would this be simply solved using altitude hold (but for this I need a new ESC, mine does not arm, do you remember?)?
in the meantime I have another question (ok, a couple :)).
How does the plane know where is South? I guess this is the reason you say to fly the plane at least two minutes before enter in WP mode.
The question is: is it the same in wich direction? Is it just enough to circle over head or is it better to fly straight? Is the same from wich direction you start the wp sequence?
Sorry, but I would like to understand the better I can how this device work.
- first flight a lot of drift. I forgot to wait for the board to fit the external temperature!!!
- the waypoint sequence had a strange behaviour. It begin in the right way but it does not execute the right sequence (no CROSSTRACKING). I already had a look at the code and I guess it is correct. I think N-E-S-O do have the same positive negative value here in Europe too, is that true?
- if I pause the sequence and start it again would it begin from the last wp? It seem so. I tryed to toggle the switch 5 times and it seems that it begin the sequence from start. Could you confirm this please?
- when the model reaches the first wp (home) it begin to dive. I fly with altitude hold disabled and half throttle. Is it possible that the plane search to hold the altitude from throttle position?
- in the last flight drift appair again, stabilisation was not working well: mystery!?
Replies
http://www.rcgroups.com/forums/showthread.php?p=13917366#post13917366
I got attracted here by the DCM implementations. Really appreciate the developers' gratitude to put the codes in open source. I am trying to understand the DCM code so that I could use it on our IMUs. But I got some questions with the union usage in PI_feedback() of rmat.c. No experiences with DSP programming at all.
I understand that with union, we could easily access the lower or upper 2 bytes of a long variable. But I don't understand why there are ">>3" after the multiplication and in the final assignment.
---------------------For example---------------------
union longww CorrectionIntegral[] = { { 0 } , { 0 } , { 0 } } ;
CorrectionIntegral[0].WW += ( __builtin_mulss( errorYawplane[0] , KIYAW )>>3) ;
omegacorrI[0] = CorrectionIntegral[0]._.W1>>3 ;
------------------------------------------------------------
KIYAW = 32; so what I should expect from omegacorrl[0]? Can anybody help with this?
Haiyang
Just curious if there is a demo application for the IMU with PC connection (rotating cube or similar on-screen demo)?
I tried the RollPitchYaw demo, seems to work very well. However moving the board several times in conical circles it cumulates some position error. (it removes the error after the movement in calm position, it takes a few seconds)
Maybe it's because of the not perfect gyro sensitivity? The acceleratin sensor feedback deals with the gyro sensitivity calibration, or it just trims out the cumulated position errors?
I am thinking about writing some OSD code for this board. Software only, using the spi port and interrupts. Unfortunately no dma, so must handle the spi interrupts in every 1.5 ... 2 usec. The processor loading is not too high, however I am not sure if there are periods in the current software when interrupts disabled for more then about 1 usec? It so, such sw OSD can't co-exist.
Jozsef
Just curious if there is a demo application for the IMU with PC connection (rotating cube or similar on-screen demo)?
I tried the RollPitchYaw demo, seems to work very well. However moving the board several times in conical circles it cumulates some position error. (it removes the error after the movement in calm position, it takes a few seconds)
Maybe it's because of the not perfect gyro sensitivity? The acceleratin sensor feedback deals with the gyro sensitivity calibration, or it just trims out the cumulated position errors?
I am thinking about writing some OSD code for this board. Software only, using the spi port and interrupts. Unfortunately no dma, so must handle the spi interrupts in every 1.5 ... 2 usec. The processor loading is not too high, however I am not sure if there are periods in the current software when interrupts disabled for more then about 1 usec? It so, such sw OSD can't co-exist.
Jozsef
Thanks
Looking at the offset correction in the MatrixNav code:
zaccel.offset = zaccel.value - 2*GRAVITY ; // GRAVITY is measured in A-D/2 units
and
gplane[2] = ( zaccel.value>>1 ) - ( zaccel.offset>>1 ) ;
... the following struck me.
Say you have a 12 bit ADC resolution and a full scale range of +/-8 g (just for illustration). That gives a GRAVITY value in A/D digits of 256 digits/g.
When the accelerometer is 100% vertical an ideal world accelerometer would read 256 digits on the Z axis due to gravity. If a plane rolls to the right this reading will decrease with a corresponding amount. Similarly, a decrease will also be seen when the plane rolls to the left.
If the accelerometer leans a little to one side during calibration it may read 245 for instance, the offset then being 11.Say the accelerometer leaned to the right during calibration and the plane performs a right roll, the raw value will decrease and so will the corrected value. But, and this is the problem, if the plane rolls to the left, the raw value will increase first (and so will the offset corrected value) until it reaches the full scale A/D value and only then start to decrease as it should.
From the code I can see that there is no compensation for the above and would expect it to introduce a bit of instability - specifically during roll maneuvers which centers about this incorrectly increasing window. From all the successes I read about in this forum I can only guess the the effect of this is minimal, but I would love to hear your take on this.
Best regards,
Elardus
I have some questions about the code CORNER:
- what means this and what exactly happen in the navigation when I define CORNER?
- are there other code like this (something to define a circle, with radious and direction, or a selectable angle of turn)?
Thank you and best regards.
Ric
yesterday I made 4 more flights.
During the first two flights the plane, in wp mode, made anything else than I programmed, to the point I thought I was wrong again with the wp programmation.
During the 3th and 4th flight the plane made the sequence without mistakes.
I have to say that I also made two fpv flights, with another plane, and during the second I lost the gps lock (from 7 sats). The plane, equipped with a Remzibi osd, was no more able to get gps lock in flight. It only got a lock several minutes after landing.
Could this be the issue with wp sequence issue too?
Btw, I take care to set the calibrations at the best I can do, and the stabilisation was awesome (I like wery much how the imu lock the plane when going up at 45 deg and full power).
I changed the gains to have tighter turns in wp mode (Yawkp from 0.07 to 0.1, Rollkp from 0.25 to 0.15 and Rollkd from 0.125 to 0.1). The plane turn very tight but it need a bit more elevator.
I wasn't able to find the value to change this.
Do I have to change the pitch gains (I don't think so, pitch stabilisation and recover are good, until now)?
Is there another value to set right elevator vs.banking?
Would this be simply solved using altitude hold (but for this I need a new ESC, mine does not arm, do you remember?)?
Thank you very much!
Ric
in the meantime I have another question (ok, a couple :)).
How does the plane know where is South? I guess this is the reason you say to fly the plane at least two minutes before enter in WP mode.
The question is: is it the same in wich direction? Is it just enough to circle over head or is it better to fly straight? Is the same from wich direction you start the wp sequence?
Sorry, but I would like to understand the better I can how this device work.
Thank you!
Ric
I just went from flying field.
On 4 flights I noticed that:
- first flight a lot of drift. I forgot to wait for the board to fit the external temperature!!!
- the waypoint sequence had a strange behaviour. It begin in the right way but it does not execute the right sequence (no CROSSTRACKING). I already had a look at the code and I guess it is correct. I think N-E-S-O do have the same positive negative value here in Europe too, is that true?
- if I pause the sequence and start it again would it begin from the last wp? It seem so. I tryed to toggle the switch 5 times and it seems that it begin the sequence from start. Could you confirm this please?
- when the model reaches the first wp (home) it begin to dive. I fly with altitude hold disabled and half throttle. Is it possible that the plane search to hold the altitude from throttle position?
- in the last flight drift appair again, stabilisation was not working well: mystery!?
Best regards.
Ric
-
3
-
4
-
5
-
6
-
7
of 11 Next