PWM control with the Raspberry Pi

[Arto Bendiken]

We should have found these benchmarks at the previous hackathon, so as
to know our limits:

http://codeandlife.com/2012/07/03/benchmarking-raspberry-pi-gpio-speed/

On the RPi1, shell scripting can produce a square wave at ~3 kHz (via
the Linux GPIO sysfs), while Perl/Python/Ruby bindings of GPIO
libraries can reach up to 70 kHz, and DMA from pure C comes out an
order of magnitude beyond, at up to 22 MHz.

http://codeandlife.com/2015/03/25/raspberry-pi-2-vs-1-gpio-benchmark/

The RPi2 "is generally 2-3 times as fast in GPIO operations [as] its
predecessor", with pure C now able to produce a square wave at up to
~42 MHz.

--
Arto Bendiken | @bendiken | http://ar.to

[Alexander Biersack]

Great that you found these benchmarks.

Questions over questions:

So RC PWM has a base frequency of 50 Hz (i.e. new pulse every 20ms) with pulses of 1ms to 20ms.

That means if you can get 3kHz from the shell with "echo * > /sys/class/gpio/*" that should be enough to run a servo which needs about 1kHz.

Servos should be tolerant if you send a pulse every 15 to 25ms instead of the 20ms. So a lower frequency should work too.

I don't know how much you can overclock them, because I think 50Hz is a little bit on the low end to track a fly - I am just guessing, I did no math.

If you used wiringPi gpio and you got any useful movement of the servo, well done.

Question 0) Are we just going to use C native library with 22MHz for highest precision and forget about all the others?

Question 1) Are 50Hz fast enough for what we want to do? Are there servos that we can control faster without PWM?

Question 2) In the benchmark text he claims to be using pin 4 but the code shows "gpio mode 7", that is pin 7?! Same in a later example:
#define PIN RPI_GPIO_P1_07 // GPIO 4

or in the next C example:

pinMode(7, OUTPUT);

Is 7 somehow pin 4?

Question 3) Should we write a benchmark to test our servos to see how fast they can actually follow a given signal? Manufacturers make claims but how fast they move end to end or things like that, but a test would be good to see actual performance.

I am thinking like randomly generate a sequence of positions and see how fast a servo can actually get there from the previous random position.

--
You received this message because you are subscribed to the Google Groups "Consensus Reality" group.
To unsubscribe from this group and stop receiving emails from it, send an email to conreality+...@googlegroups.com.
To post to this group, send email to conre...@googlegroups.com.
Visit this group at http://groups.google.com/group/conreality.
To view this discussion on the web visit https://groups.google.com/d/msgid/conreality/CAE7aNuS6b10Fq9Odh3Z3ZQ0MwDvayKPUnkdHWWuyx5PeoWBpeQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Alexander Biersack]

Answer to question 2: Seems gpio 7 corresponds to pin 4 and wiringPi does a renumbering.

His conclusion is interesting to note:

What is not evident from the snapshots, however, is that due to multitasking nature of Linux, the GPIO manipulation is constantly interrupted for short periods when the CPU is doing something else, such as receiving or sending data over network, writing log files, etc. Only a realtime OS is suitable for timing-critical stuff, or using the hardware level support for I2C, UART and such. A good alternative is an independent add-on board with a microcontroller, such as Arduino or several other alternatives. Communicating over UART is simple with such devices.

Which brings the APM 2.6 hardware back into the game. I was thinking about how to get the gyros, accelerometers, GPS, pressure sensors, magnetometer etc. They are all already integrated and packaged nicely on the APM2.6 (http://copter.ardupilot.com/wiki/common-apm25-and-26-overview/) And the code to read the sensors and write to the PWM outputs is there and fully tested.

Perhaps we should read the sensors on the APM board and send them over to the Pi to do the processing and then send the intended gyro positions back over to the APM and let it do the PWM stuff.

Buying all these sensors separately for the Pi would cost more and create a nice birds nest of wires and connectors. And would be more error prone than just one connection between the Pi and the APM.

One drawback is that the APM has only 8 PWM output connectors, 8 analog inputs and a few digital outputs (plus of course uart, i2c, spi...) This may be a limitation.

The next generation is the pixhawk, which has 6 extra outputs which is good if you want to control gimbals and more.

An alternative is to use the Pi and output an analog signal and some hardware to turn that into a PWM signal. But that still does not give you the sensors and the software to read them all.

Alex

[Alexander Biersack]

s/send the intended gyro positions back/send the intended servo positions back

[Arto Bendiken]

On Wed, Nov 25, 2015 at 8:49 AM, Alexander Biersack
<a.bie...@googlemail.com> wrote:

> Questions over questions:
> So RC PWM has a base frequency of 50 Hz (i.e. new pulse every 20ms) with
> pulses of 1ms to 20ms.
>
> That means if you can get 3kHz from the shell with "echo * >
> /sys/class/gpio/*" that should be enough to run a servo which needs about
> 1kHz.

Modulo significant timing jitter when executing on a non-realtime
system, which suffices to ruin things as it turns out.

> Servos should be tolerant if you send a pulse every 15 to 25ms instead of
> the 20ms. So a lower frequency should work too.

The SG90 servos [1] we have in Bratislava have more precise timing
requirements than this [2]. We do need sub-millisecond precision.

> Question 0) Are we just going to use C native library with 22MHz for highest
> precision and forget about all the others?

The initial DMA driver (currently in development) will be pure OCaml
to the extent possible, with minor bits of C++ glue as needed.

> Question 1) Are 50Hz fast enough for what we want to do? Are there servos
> that we can control faster without PWM?

2D/3D-axis brushless gimbals, at least, could be controlled very
precisely with the STorM32-BGC controller. More research will be
needed for various types of servos.

> Question 2) In the benchmark text he claims to be using pin 4 but the code

> shows "gpio mode 7", that is pin 7?! Same in a later example: [...]

> Is 7 somehow pin 4?

There are at least two different numbering systems for the GPIO pins,
the RPi numbering and the Broadcom numbering [3, 4].

> Question 3) Should we write a benchmark to test our servos to see how fast
> they can actually follow a given signal? Manufacturers make claims but how
> fast they move end to end or things like that, but a test would be good to
> see actual performance.

We have a hardware-based servo tester [5] in Bratislava that will slew
the servos at their maximal rates. The current pan/tilt frame and its
servos don't impress much (the datasheet's 0.12s/60° seems a bit
optimistic); we'll need to get better components.

[1] http://www.servodatabase.com/servo/towerpro/sg90
[2] http://akizukidenshi.com/download/ds/towerpro/SG90.pdf
[3] http://elinux.org/RPi_Low-level_peripherals#Referring_to_pins_on_the_Expansion_header
[4] http://elinux.org/RPi_BCM2835_GPIOs
[5] http://www.amazon.de/gp/product/B00BSUGB90

[Arto Bendiken]

On Wed, Nov 25, 2015 at 9:34 AM, Alexander Biersack
<a.bie...@googlemail.com> wrote:
> Which brings the APM 2.6 hardware back into the game. I was thinking about
> how to get the gyros, accelerometers, GPS, pressure sensors, magnetometer
> etc. They are all already integrated and packaged nicely on the APM2.6
> (http://copter.ardupilot.com/wiki/common-apm25-and-26-overview/) And the
> code to read the sensors and write to the PWM outputs is there and fully
> tested.
>
> Perhaps we should read the sensors on the APM board and send them over to
> the Pi to do the processing and then send the intended gyro positions back
> over to the APM and let it do the PWM stuff.

Perhaps you might bring an APM to Bratislava for the next hackathon,
and we could see what it can do.

[Alexander Biersack]

I tried to find the APMs in my old apartment today, but couldn't. I was planning to bring them. I don't have much hope right now. Maybe I have them in Brandenburg, will check this weekend, but I think that is unlikely, can't remember bringing electronics there.

a

[Alexander Biersack]

If I get my new apartment ready for the party on Friday and I have some time I will do a more thorough search, but right now I have no clue where to look. Might have left them with Jacob, the mechanic, with whom I build the drone I have now. I know I left a box of stuff there, but he also moved his whole shop, so I will have to see if he knows where the box is. I could rip the one off the drone, but I think it is glued on and the cable connectors might break if I try to remove them, they get stuck pretty hard. Probably a good thing, because you don't want to loose connections due to vibrations during flight. I remember removing one because there was some problem and the socket got ripped right out with it from the board. So I don't know.

I will let my subconscious work on it.

a

[Arto Bendiken]

On Nov 25, 2015 9:17 PM, "Alexander Biersack" <a.bie...@googlemail.com> wrote:
>
> I tried to find the APMs in my old apartment today, but couldn't. I was planning to bring them. I don't have much hope right now. Maybe I have them in Brandenburg, will check this weekend, but I think that is unlikely, can't remember bringing electronics there.

Hope you find one, would be great to have it.