paparazzi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Paparazzi-devel] PPM radio woes


From: Gerard Toonstra
Subject: Re: [Paparazzi-devel] PPM radio woes
Date: Mon, 14 Jan 2013 11:08:11 -0300


ok, the initialization config change is very easy.
The data transmission needs a bit of extra thinking to get right, but also doable using the same mechanism.

Not sure when I have time for these changes, but I have it noted here.

Rgds,

Gerard


On Mon, Jan 14, 2013 at 9:47 AM, Felix Ruess <address@hidden> wrote:
Hi Gerard,

Ok. Good to know it works.
It might also make sense to implement the basic w5100 functionality as a re-usable peripheral.
I started refactoring some of the peripherals and imu drivers in the peripherals_imu_refactor branch (see issue 345).
You could take a look at https://github.com/paparazzi/paparazzi/blob/peripherals_imu_refactor/sw/airborne/peripherals/adxl345_spi.c as an example on how to do this without busy loops.

Cheers, Felix



On Sun, Jan 13, 2013 at 8:57 PM, Gerard Toonstra <address@hidden> wrote:
ok, thanks. I'll use master then.

There was an old thing I was asked to test, message from 13/11/2012:

Btw, made some changes to the SPI slave selection and fixed some typos...
Could you please also check if the SPI devices you are using (w5100) are working as expected in master?
Thx!

I tested this yesterday on master and it works as expected. the implementation does need work though, because
it still uses busy wait loops and transfer a whole buffer in one iterative loop, potentially delaying more
important processing. It's therefore not yet ready for prime-time, but I'm getting some ideas on how to improve
this for the future through the use of the callback mechanism.

Rgds,

G>


On Sun, Jan 13, 2013 at 3:35 PM, Felix Ruess <address@hidden> wrote:
Hi Gerard,

thanks a lot for the fixes, they are merged.

Testing of the master branch would really be appreciated. And if you want to work on new features, master is the one to use.
In master we completely switched to libopencm3, in v4.2 the libstm is still used...
v4.2 is actually the pretty old v4.0 branch plus some additional backported features/fixes (e.g. energy control).

Cheers, Felix


On Sat, Jan 12, 2013 at 9:38 PM, Gerard Toonstra <address@hidden> wrote:
Hi all,

I was on holiday and busy setting up my company. Now that's almost finished and I'm back working out some pending issues before flight testing.

I'm flying using the ppm system and the ezuhf configuration I made and there have been two issues I was unhappy about:

1. When a couple of channels would go to the minimal position (operating a switch, banking left), the servo's locked up. I worked around this by flipping an unused channel to 1920us.
2. The first channel was never recognized and skipped for some reason, so I had to copy ch. 1 to ch.6 to get a readout.

The good news is that both issues are fixed now and pull requests submitted.

1.  The first is due to a fixed frame timing on an 8ch. receiver with 7 ch. radio. Only the ppm's of the 7 channels are received, resulting in an end-of-frame marker that's a bit longer than usual. The fix was to set the sync_max to 14940, which is essentially 22500-(7*1080). The usual setting would be 13500 or so, which means that ppm frames were considered invalid since the marker went over this setting.

2. The second took me a while, but eventually tracked down to the fact that the ppm_arch.c code on stm32 doesn't do anything with the pulse_type setting. It always assumes rising edge triggering. I've added the code to determine the edge triggering based on the radio file and lo-and-behold... the first channel appeared in the readouts.



From what I gathered, energy control is now available on v4.2. Should I use the stable branch or is it recommended to still use master for that?


I'm only getting started with the settings here, but this post suggests that 4 gains are sufficient to make it work?:

http://lists.nongnu.org/archive/html/paparazzi-devel/2012-12/msg00084.html

does this mean it should suffice if I set:

<define name="ENERGY_TOT_PGAIN"                value="0.35" />
    <define name="ENERGY_TOT_IGAIN"                value="0.25" />
    <define name="ENERGY_DIFF_PGAIN"            value="0.30" />
    <define name="ENERGY_DIFF_IGAIN"            value="0.20" />

and leave all the rest out?

G>




_______________________________________________
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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]