Hello,
I didn't manage to load the sys_mon module to my configuration, the compilation fails: is it compatible with lisa m board 1.0?
About telemetry: to see if the bytes rate is too high, I suppose it can be verified by checking the field "rx_err" in the message "downlink status"? Should be close to zero?
@Felix, which airframe .xml configuration file that uses int_cmpl_quat is a good reference for settings ?
@Simon: the "strange throttle behavior" fix was this command for lisa <define name="I2C_TRANSACTION_QUEUE_LEN" value="10"/> ?
I changed a few things at one time and haven't been able to get airborne again to test out one at a time, but I think it was this that made the difference:
<define name="PHI_PGAIN" value="-300"/> <!-- was -400 -->
<define name="PHI_DGAIN" value="-200"/> <!-- was -300 -->
<define name="PHI_IGAIN" value="-100"/>
<define name="THETA_PGAIN" value="-300"/> <!-- was -400 -->
<define name="THETA_DGAIN" value="-200"/> <!-- was -300 -->
The other changes I made at the same time were the I2C_TRANSACTION_QUEUE_LEN as you point out and:
<define name="HOVER_KP" value="-200"/> <!-- was -500 and it would not stop flying when throttle was off -->
<define name="HOVER_KD" value="-100"/> <!-- was -200 -->
<define name="HOVER_KI" value="0"/> <!-- was -100 -->
Though this, as Felix pointed out, has no effect if you in AP_MODE_ATTITUDE_DIRECT mode as I was.
Simon
Thanks
Loïc
Le 21 février 2012 15:45, Loic Drumettaz
<address@hidden> a écrit :
Yes, i meant just check. I will add the sys_mon module to my configuration. Other than delay on the motor, I had also some bugs with my Lisa M board: the board freezes with all leds on, and the motor stops (happenned in flight only once!). This seems to happen more often when i set the telemetry message to "attitude". Is it possible that when the telemetry rate is too high, the board stops?
Hi Loic,
Thank you for updating the wiki. I had a strange behaviour using the int_cmpl_quat: there was some delay in the thrust command when reducing throttle. So I went back to int_cmpl_euler but I think i need to do more testing with int_cmpl_quat.
Commanded thrust has nothing to do with attitude estimation...(unless you run into lower/upper motor command limits with supervision).
Maybe this problem was related to the level of vibration I had before balancing motoprops...
About the running frequency of the algorithms: is it possible to make sure that the calculation is not too long compared to the sample time? Is it possible that the MCU gets overloaded?
You can't make sure that everything get's computed in time.. or if you meant to just check:
The sys_mon module gives you some information about the timing of the periodic tasks. It will give you a rough average (over 1 sec) cpu load, perdiodic time, periodic cycle time and min max of these. So your max should not be over the periodic time, otherwise in at least one cycle it took longer to calculate everything and the next one was slightly delayed...
Cheers, Felix
_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel