Re: [Paparazzi-devel] Libopencm3 - STM32-F1 change interrupt priority Backstepping for Multirotor basic stabilisation.

[Prof. Dr.-Ing. Heinrich Warmers]

Hi,
i have found that of the point of view for the feed back control system is it not necessary  to run  the IMU with 1kHz.
You generate much numerical noise if you run it with 1kHz.
Inside the rate sensors we have filters  (< 200, < 100 Hz).
By using the backsepping (direct  multiplying the rates  with a factor and use them direct for motor control  50 to 100Hz)  the navigation  and AHS can run with 20 to 50Hz without any problems.
But paparazzi is not  using  the backstepping. This  is also the best choice  for multirotor basic stabilization.  Look to the literature: Oliver Meister Jan Wendel.
Backstepping work as the best and has no so much noise like a PD controller.
The point is that no angle  is needed  to stabilize the multirotor. And therefore no comparison   of a generated angle is needed.
It would be nice  to compare the different  methods  im paparazzi.
Heinrich

 





Hector Garcia de Marina schrieb:

Hi Michael, since the scheduling is static, the best way is to trigger one electric signal at the beginning and at the end of the task. Then observe this signal with an oscilloscope, from this information you can compute the time with nice accuracy and therefore you can estimate the limit of your system.

I am afraid that the F1 will not support a high rate with floating point operations since it does not have floating hardware unit. Why do you need 1KHz? Are you testing aerobatics or something similar?

On 23 Aug 2013 20:19, "Michal Podhradsky" <address@hidden> wrote:

Hi Felix,

thanks for the explanation about the sys_mon, now it makes more sense:)

I ran a couple of quick tests (just looking at the telemetry data and sys_mon module, no data logging):

A) rotorcraft running @512Hz + GX3 as ahrs @500Hz + int_euler for stabilization -> runs just fine (master 5.0)

B) rotorcraft running @512Hz + GX3 as ahrs @500Hz + float_euler for stabilization -> VERY BAD timing (probably because of the floating point calculations at high rate?) (master 4.9)

C) rotorcraft running @512Hz + GX3 as ahrs @125Hz + float_euler for stabilization (master 4.9) -> OK(!), note that floating point calculations runs at the same rate as in B), there is just 4x more UART traffic...

Maybe rotorcraft code is written in a way it can handle the tasks and timing better?

M

As for yesterday tests w. fixedwing, here is the configuration for aspirin:
  <firmware name="fixedwing">
    <target name="ap"             board="lisa_m_2.0"/>
    <configure name="FLASH_MODE" value="JTAG"/>

    <define name="AHRS_USE_GPS_HEADING"/>
    <configure name="PERIODIC_FREQUENCY" value="500"/>
    <define name="MODULES_FREQUENCY" value="500"/>

    <subsystem name="control"/>

<!-- Communication -->
    <subsystem name="telemetry"     type="transparent"/>

    <subsystem name="radio_control" type="ppm">
       <configure name="RADIO_CONTROL_PPM_PIN" value="UART1_RX"/>
    </subsystem>

<!-- Sensors -->
    <subsystem name="imu"      type="aspirin_v2.2"/>
    <subsystem name="ahrs"      type="int_cmpl_quat"/>
    <subsystem name="gps"       type="ublox"/>
    <subsystem name="navigation" type="extra"/>
    <subsystem name="ins" type="alt_float" />
  </firmware>

<!-- Modules -->
  <!--modules main_freq="500"-->
  <modules>
    <!-- Airspeed Sensor -->
    <load name="airspeed_adc_adv.xml">
    </load>

    <!-- System Monitor -->
    <load name="sys_mon.xml"/>
    <load name="battery_monitor.xml"/>

    <!-- UGEAR BLACKBOX -->
    <load name="ugear_blackbox_uart.xml"/>
  </modules>

On Fri, Aug 23, 2013 at 8:15 AM, Felix Ruess <address@hidden> wrote:

Hi Michal,

I added some more information to http://paparazzi.enac.fr/wiki/Module/System_monitor. I hope that answers your question about the periodic_cycle...

Nice job on the testing/plotting so far ;-) We clearly need to have a closer look at this...

I didn't observe any variations like that in my setups so far (will check again tonight when I have access to the hardware again).

There are quite a number of reasons why this could happen...

E.g. if have an algorithm that takes a lot of time, it could delay the next periodic function. As we don't have any preemption (yet) this is some sort of cooperative scheduling.

It could be triggered by an event like new gyro data and hence run in the event loop, or be one of the autopilot periodic functions like running guidance (e.g. if you try to run that in float without a floating point unit it will probably take too long)

What configuration (stabilization, ahrs, ins, etc..) were you using for the aspirin tests?

Cheers, Felix

On Fri, Aug 23, 2013 at 2:50 AM, Michal Podhradsky <address@hidden> wrote:

Hi Felix,

so I looked into it a bit more. First test with system monitor, using fixedwing with GX3 at 500Hz, and PERIODIC_FREQUENCY=500Hz.

The periodic time is an average, so it is exactly at 2ms. The max periodic cycle is however over the periodic time -> something is going on there.

Although I am not sure how to interpret the periodic_cycle. The average is 1.25ms, which represents 800Hz, but I am not aware of any loop going that fast.

I made a simple logger module to monitor system time on the autopilot. It runs at the same frequency as the periodic frequency, and sends through UART current system time  (get_sys_time_usec() from arch/stm32/mcu_periph/sys_time_arch.h). I ran couple of tests with different configurations.

Test 1: -> data1.png

Aspirin IMU, 60Hz periodic frequency. Just to get the baseline.

After first 80sec I plugged in GX3 configured to just output data @500Hz (loads of data on UART). The data from GX3 weren't processed any further though.

I calculated difference between the received timestamps and converted that to frequency. Data1 shows the result. You can see that most of the data come with frequency between 58 and 62Hz, which is +-3% around the defined periodic frequency. It is not great, but sufficient for now. Then every half second you get a timestamp at 56.6/64Hz (that is +-6% which is not acceptable precision).

At T=~80sec I plugged in GX3 and you can see that the frequency of timestamps starts to oscillate. Not much, but it definitely observable.

Test 2: -> data2.png

GX3, 60Hz periodic frequency. GX3 configured to output attitude data @125Hz which is slightly higher, but its only effect is a higher load on CPU. See data2

Most of the time the measured frequency is right 60Hz, but every 250ms the loop gets delayed (you can see the frequency drops to 58Hz and then jumps to 62Hz (probably the next loop is somehow faster).

So at lower frequencies everything works just fine.

Test3 -> data3a.png and data3b.png

GX3, 500Hz periodic frequency, GX3 @500Hz.

Now the things starts to be messy. You can see that the system frequency is all over the place, and there is some periodicity in the behaviour. The mean is still 500Hz, but the actual frequency is between 400Hz and 600Hz.

Test4 -> data4.png

Aspirin @500Hz, basically the same behaviour as with GX3.

Since the problem with timing is the same with Aspirin as with GX3, it probably wont be UART/SPI drivers/isr routines.

Any idea which other part of code could delay the loop like that?

Cheers
M

On Wed, Aug 21, 2013 at 2:34 AM, Felix Ruess <address@hidden> wrote:

Hi Michal,

That's rather bad... I don't have any timing problems here, but then I'm not blowing heaps of data through UART...

You can also use the sys_mon module [1] to check if the timing of your main periodic is ok.

The priorities should probably be configurable.... can you make some tests if this helps or if it is something else?

[1] http://paparazzi.enac.fr/wiki/Module/System_monitor

Cheers, Felix

On Wed, Aug 21, 2013 at 1:02 AM, Michal Podhradsky <address@hidden> wrote:

Hi all,

I have a question about timing on Lia 1.1 (stm32f1). I recently noticed that the timing on the MCU is not solid.

I made a simple module with a periodic function which toggles an LED, ran it at PERIODIC_FREQUENCY and then plugged in a scope to see if the LED switching has a constant frequency.

I am using PERIODIC_FREQUENCY=512Hz, and the frequency moves around 30%, and occasionally bounces down to ~300Hz. If necessary, I can post video from the scope if needed.

Seems to be caused by interrupt priorities (e.g. excessive traffic on one of the UARTS can delay the main loop etc). The function nvic_set_priority() which mentioned Esden is used (master) only on a few peripherals (i2c, spi, adc, ppm), most often setting the priority to 0.

According to Cortex M3 programming manual, "If software does not configure any priorities, then all exceptions with a configurable priority have a priority of 0."

if all the configurable interrupts have the same (highest) priority, then there is no way to move the more important interrupts (e.g. UART with lots of data coming through) any higher.

The possible solution seems to be to set explicitly isr priority on each peripheral (maybe an issue for github?).

What do you think of that? Did you have similar issues with the timing?

Regards
M

On Mon, Apr 22, 2013 at 10:14 AM, Michal Podhradsky <address@hidden> wrote:

Hi Esden,

thanks for clarification!

M

On Fri, Apr 19, 2013 at 4:01 PM, Piotr Esden-Tempski <address@hidden> wrote:

Hi Michal,

I think you are mistaking the vector table slot numbers there for priorities. These are the positions of the function pointers inside the vector table. If you change those numbers then things will obviously explode.

(just for reference, here the defines get their weak functions assigned: sw/ext/libopencm3/lib/stm32/f1/vector_nvic.c, and here the vector is being put together: sw/ext/libopencm3/lib/cm3/vector.c)

IRQ priorities are set using the NVIC_IPR register, or using nvic_set_priority function.

I hope this helps.

Cheers Esden

P.S. both files nvic.h and vector_nvic.c are generated using the sw/ext/libopencm3/scripts/irq2nvic_h from sw/ext/libopencm3/include/libopencm3/stm32/f1/irq.yaml so you should not edit those files by hand.

On Apr 19, 2013, at 2:12 PM, Michal Podhradsky <address@hidden> wrote:

> Hi folks,
>
> I have a question about interrupt priorities for STM32F1 chip (Lia 1.1/Lisa_M 2.0).
>
> In sw/ext/libopencm3/include/libopencm3/stm32/f1/nvic.h are defined priorities for user interrupts. However, if I try to change the priority for example for NVIC_USART2_IRQ (let's say make it higher priority than NVIC_USART1_IRQ), the  code compiles, but then the program hangs up instantly in usart_isr interrupt routine (debugged with JTAG).
>
> Can the priorities be set somewhere else or is it a feature to have "hardcoded" priorities?
>
> Thanks
> Michal

> _______________________________________________
> Paparazzi-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/paparazzi-devel


_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel

_______________________________________________
Paparazzi-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/paparazzi-devel