for incremental encoder inputs changing up to 15 kHz.
</p>
+<h2 id="background">Background</h2>
<p>
+The goal was to prove that working control can be achieved with
+<a href="http://lintarget.sourceforge.net/">Embedded Realtime Linux Target for Simulink</a>
+(<em>ert_linux</em>) on this low cost hardware which provides option for broader
+community to play with this control task taught during the
+<a href="http://support.dce.felk.cvut.cz/psr/" target="_blank">real-time operating
+systems programming course</a> at our university. The final task
+<a href="http://support.dce.felk.cvut.cz/psr/cviceni/semestralka/" target="_blank">assignment</a>
+targets industrial like PowerPC MPC5200-based board running VxWorks system.
+But Raspberry Pi (RPi) is much cheaper and common in broad community.
+The initial idea has been implemented in a frame of Radek Mečiar's
+bachelor thesis with controller and monitor web server implemented
+directly in C-language. The experiment has been improved and combined
+with <em>ert_linux</em> project to allow teach controller design with Simulink.
+</p>
+
[[!img rpi-mc-wwrap-schema.png size="300x" align=right alt="Diagram of Interconnection of RPi and DC Motor"]]
-The DC motor is connected to RPi GPIO pins.
-The diagram of wire-wrapped interconnection is available in
-<a href="rpi-mc-wwrap-schema.pdf">PDF</a> and
+<h2 id="hardware">Hardware</h2>
+<p>
+Since the RPi (and its BCM2835 SoC) is not intended for motion control applications,
+there is no hardware support for incremental encoder inputs (IRC)
+and the RPi connector has only one pulse width modulation (PWM) output.
+That is why most of signal and control processing is done in software
+with minimal HW support. In order to be able to rotate the motor in both
+directions, the only available PWM signal is demultiplex to two
+sides of power H-bridge by using four NOR gates (SN74HCT02)
+where direction is controlled by an additional GPIO output (DIR).
+The incremental encoder signals are connected directly to the RPi and
+processed only in software. The diagram of wire-wrapped interconnection
+is available in <a href="rpi-mc-wwrap-schema.pdf">PDF</a> and
<a href="rpi-mc-wwrap-schema.svg">SVG</a> formats as well.
</p>
+<h2 id="irc">IRC processing</h2>
+<p>
+The IRC signal processing is the most demanding part of our solution
+since the frequency of the IRC signal can go up to 21 kHz,
+when maximal voltage is applied to the motor. To achieve reasonable
+performance, a kernel driver has been implemented for this purpose.
+It uses four GPIO pins — two for each IRC channel.
+One of these two pins is configured to generate interrupts for
+rising edges and the other for falling edges. Motor position is
+derived from the order of interrupts and applications can read it via
+<tt>/dev/irc0</tt>.
+</p>
+<p>
+This solution has an interesting property that it works even when the
+processing of one (or few more) interrupt(s) is delayed due to other
+activities in the system. In preempt_rt, the interrupt handlers run
+in dedicated threads, which can be preempted by threads with higher
+priority. Thanks to the fact that the scheduler run queue is a FIFO
+queue, the IRQ threads are activated in the same order as the original
+interrupts and our position calculation works even in the case of
+a delay. The alternative approach, where the position is calculated from
+the actual IRC signal levels read in the interrupt handler would fail,
+because the level read in a delayed handler might be different from
+the level at the time when the corresponding IRQ was generated.
+</p>
+<p>
+Even better performance could be probably achieved by processing the
+IRC signals in ARM's fast interrupt requests (FIQ), but this solutions
+would not be portable to other architectures. Other option is to
+design more sophisticated hardware but minimal HW solution is
+excellent for teaching.
+</p>
+
+<h2 id="model">Simulink model</h2>
+<p>
+Simulink model of the motor controller is depicted in Figure.
+The
+<a href="https://github.com/ppisa/rpi-rt-control/blob/master/simulink/sfIRCInput.c" target="_blank"><em>IRC0</em></a>
+and
+<a href="https://github.com/ppisa/rpi-rt-control/blob/master/simulink/sfPWMwDir.c" target="_blank"><em>PWMwDir</em></a>
+blocks are so called C MEX S-functions. The former reads the motor position
+from <tt>/dev/irc0</tt>, the latter controls the PWM and DIR signals
+by directly accessing the GPIO registers via <tt>mmap()</tt>ed <tt>/dev/mem</tt>.
+The actual motor control is performed by a proportional-sum-derivative (PSD)
+controller enhanced with an anti-windup technique. Setpoint <em>w</em>
+is generated either manually or by a simple trajectory generator.
+Sampling period of the whole model was set to 1 ms. The source code
+of the S-functions as well as the model are available from
+<a href="https://github.com/ppisa/rpi-rt-control" target="_blank">Github</a> repository.
+</p>
+<p>
+The <em>ert_linux</em> target was configured to use an ARM C cross-compiler.
+The generated binary was copied to the target RPi board by the
+<tt>scp</tt> command and ran there. Simulink <em>external mode</em> was
+used to tune certain model parameters on-line as well as to see the
+actual signal values in the scope windows.
+</p>
+
+<h2 id="evaluation">Performance evaluation</h2>
+<p>
+The Linux kernel used for our experiments was the official
+Raspberry Pi rpi-3.12.y Linux kernel version 3.12.28 patched with Steven
+Rostedt's stable preempt_rt patch (patch-3.12.26-rt40) and with Junjiro R.
+Okajima's aufs3.12.x 20140512. The latencies measured by the <tt>cyclictest</tt>
+tool when the system was loaded by TCP communication and SD card accesses are as
+follows. The maximal latency was 170 μs, average about 40 μs. When
+graphical desktop was run the maximal latencies increased to 280 μs
+(probably caused by contention on the system bus generated by the
+VideoCore GPU). This observation is in same range as
+more serious examination and long term performance monitoring
+on better tuned RT-kernel kernel executed by
+<a href="https://www.osadl.org/" target="_blank">Open Source Automation Development Lab</a>
+and documented in their
+<a href="https://www.osadl.org/Profile-of-system-in-rack-7-slot-3.qa-profile-r7s3.0.html" target="_blank">Quality assurance Farm</a>.
+</p>
+<p>
+System load caused by running an unoptimized (soft-float only) model
+was about 2%. The USB connected Ethernet controller (a part of RPi) generated
+load of about 10%. The highest load was generated by the software IRC
+signal processing — up to 95%, i.e. the limit for RT tasks. This
+happened during fast motor rotation (e.g. when maximal input voltage
+was applied) and the interrupt frequency was 8 kHz per each channel
+(32 kHz in total). As can be seen, processing of the IRC signal at
+full speed (21 kHz) is above capabilities of the Linux kernel on this
+hardware. As mentioned above, the use of FIQ (or raw interrupts) could
+help here. For lower speeds, our simple solution works flawlessly and
+can be used as a great tool for control education and experiments.
+</p>
+
+<h2 id="links">Links</h2>
+<dl>
+ <dt>Bachelor thesis of Radek Mečiar: Motor control with Raspberry Pi board and Linux (Czech language only), 2014</dt>
+ <dd>Available <a href="https://support.dce.felk.cvut.cz/mediawiki/images/1/10/Bp_2014_meciar_radek.pdf" target="_blank">online in PDF format</a>
+ </dd>
+ <dt>Michal Sojka, Pavel Píša: Usable Simulink Embedded Coder Target for Linux at 16th Real Time Linux Workshop, 20+4</dt>
+ <dd><a href="https://www.osadl.org/?id=2018" target="_blank">Paper abstract</a> at <a href="https://www.osadl.org/RTLWS-2014.rtlws-2014.0.html" target="_blank">16th Real Time Linux Workshop</a> site.
+ </dd>
+ <dt>RPi RT Control Support</dt>
+ <dd><a href="https://github.com/ppisa/rpi-rt-control" target="_blank">https://github.com/ppisa/rpi-rt-control</a>
+ <br>GitHub Repository with RPi IRC kernel module and Simulink model and RPi blocks sources.
+ </dd>
+ <dt>Fully preemptive kernel sources for RPi (kernel-3.12.28-rt40+)</dt>
+ <dd><a href="https://github.com/ppisa/linux-rpi/tree/rpi-3.12.y-aufs-rt-ppisa" target="_blank">https://github.com/ppisa/linux-rpi</a>
+ <br>GitHub repository with branch rpi-3.12.y-aufs-rt-ppisa containing Linux kernel sources
+ with Steven Rostedt's stable preempt_rt (patch-3.12.26-rt40) and with Junjiro R. Okajima's aufs3.12.x 20140512
+ patches applied.
+ </dd>
+ <dt>Simulink Embedded Coder target for Linux</dt>
+ <dd><a href="http://rtime.felk.cvut.cz/gitweb/ert_linux.git" target="_blank">http://rtime.felk.cvut.cz/gitweb/ert_linux.git</a>
+ <br>Repository with core templates for Linux hosted, Linux cross architecture targetted
+ Simulink code generation templates and configuration.
+ </dd>
+ <dt>Auxiliary utilities for Raspberry Pi</dt>
+ <dd><a href="https://github.com/ppisa/rpi-utils" target="_blank">https://github.com/ppisa/rpi-utils</a>
+ <br>The repository includes RAM based root overlay support to protect SDcard against wearing and tearing
+ and keep root filesystem intact when experiments are download and run on system or even crash it.
+ </dd>
+</dl>
+
</div>
</body>
projects / ert_linux_web.git / commitdiff