DistRap wiki - User contributions [en]

File:MiniRig.jpg

2019-10-17T16:39:47Z

Srk:

File:Can4disco.jpeg

2018-01-24T20:11:00Z

Srk:

File:Stackdrv.jpeg

2018-01-24T20:10:05Z

Srk:

File:Stampstack.jpeg

2018-01-24T20:06:42Z

Srk:

File:Encbreakout.jpeg

2018-01-24T20:02:33Z

Srk:

File:Stmstamp.jpeg

2018-01-24T20:01:04Z

Srk: V1

File:Devboard.jpeg

2018-01-24T19:58:25Z

Srk:

File:Drvbase.jpeg

2018-01-24T19:56:51Z

Srk:

Main Page

2017-09-30T00:20:43Z

Srk: rename FAQ

Welcome to the DistRap wiki. This wiki collects documentation and
resources related to distributed control developments.

== About ==

Goal of this project is to develop distributed control system for various robotics
and industrial automation scenarios. We are currently targeting CAN and [[CANOpen]] fieldbus
for interconnecting nodes. Node functions range from simple digital I/O, various sensors and motion
controllers implementing specific CANOpen profiles. This allows building complex machinery with isolated
parts performing specific functions.

This project also explores the possibilities of high assurance embedded software development
by using [http://ivorylang.org/ Ivory Language] - an eDSL for safe systems programming. You can think of Ivory as a safer C, embedded in Haskell.

=== Community ===

* #distrap channel on irc.freenode.net
* https://github.com/distrap/
* public mailing list https://lists.distrap.org/mailman/listinfo/pub

== Projects ==

* [[Hardware]]
* [[Software]]

== Resources ==

* [[GettingStarted]]
* [[CANOpen]]
* [[FrequentlyAskedQuestions]]

FrequentlyAskedQuestions

2017-09-30T00:20:43Z

Srk: rename FAQ

== Why CAN? ==

CAN bus uses differential signaling to provide noise resistant communication between nodes.
This is a critical requirement for our applications as they may use high power motor drivers
and motors producing lots of EMI. The other reason is the availability of the CAN peripheral
on STM32 ARM MCUs which means only adding CAN transceiver like SN65HV is necessary.

== Why CANOpen? ==

Rather than reinventing our custom protocol we're using [[CANOpen]] protocol which is designed
for industrial applications. This also allows us to stay compatible with wide range of already
existing manufacturers.

== Why Ivory Tower? ==

Due to Ivory being embedded in Haskell it reduces a lot of headache associated
with maintaining larger codebase as it allows to share code between various firmwares
and catch most errors during compilation time. Additional safety provided by Ivory
also helps in mission critical deployments such as robotics applications.

Tower allows us to compose code on even higher level and allows us to write
concurrently safe programs by providing communication channels which are used
to exchange data between various components called "towers".

On the backend side of things Ivory/Tower supports GCC ARM toolchain with either
FreeRTOS or EChronos realtime operating system. POSIX backend allows us to
run similar code on POSIX and MCU which is quite handy for testing or development
without actually using MCU itself (especially handy for protocols related development).
Additional backends for verification tools are also provided allowing
for verification of critical parts of the code.

== Why STM32? ==

* natively supported by ivory-tower-stm32
* supported by EChronos
* CAN peripheral

Also core clock speeds, high amounts of flash (1Mb quite common on F4 MCUs),
advanced timers for 3 phase PWM generation, hardware encoder interfaces, multiple ADCs
for simultaneous sampling or sampling of large number of channels in sequence,
checksummed parts of SRAM, battery backed parts of SRAM. Good toolchain support and
debugging options as well - possibility to use GCC ARM toolchain and
GDB directly with Black Magic probe enabled programmer.

FAQ

2017-09-30T00:20:42Z

Srk: rename FAQ

[[Category:Deleted]]

GettingStarted

2017-09-30T00:18:44Z

Srk: minor: missing to

== Required equip ==
* Linux computer
* F4 Discovery board
* [[CAN4DISCO]] board
* STLink programmer(s)
* Slave nodes

== Software stack ==

You can build the complete stack according to instruction on [https://github.com/distrap/distrap-build distrap-build] repository.

=== UDev rules ===

For persistent device names you should create udev rules files in ''/etc/udev/rules.d/''. For example
to create rules for your F4 Discovery board flashed with Black Magic probe firmware you can use the following
template:
{{cmd|code=
# F4 Discovery
SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Black Sphere Technologies", ATTRS{serial}!="E3C09CF4", GOTO="f4_bmp_end"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic GDB Server", MODE="0660", GROUP="dialout", SYMLINK+="f4gdb"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic UART Port", MODE="0660", GROUP="dialout", SYMLINK+="f4uart"
LABEL="f4_bmp_end"
}}

Make sure to set correct ''serial'' number, this can be found by running ''dmesg'' after the board is plugged in.
Create similar file as ''/etc/udev/rules.d/48-distrap.rules'' and run
{{cmd|code=
udevadm control -R
}}
to reload UDev daemon. Next time you plug in your device two nodes should be created
* /dev/f4gdb - for attaching GDB
* /dev/f4uart - UART2 pass-through

== Hardware ==

=== Flashing ===
=== Debugging ===
==== Black Magic Probe ====

== CAN ==

Either you Linux computer or single board computer like Raspberry Pi or BeagleBone Black
can be used as CAN master. For development purposes powerful computer is better
due to shorter compilation time, for production BeagleBone Black or ODROID XU4 is a good choice.

=== Bringing up SLCAN bridge ===

Assuming you are using [[CAN4DISCO]] as UART2CAN bridge you can bring up CAN network
with following commands:
{{cmd|code=
modprobe can
modprobe can-raw
modprobe slcan
slcand -F -s8 -S115200 /dev/f4uart can0 # CAN speed 8 -> 1Mbit
ip link set can0 up
}}

Script to initialize SLCAN can be found in [https://github.com/distrap/dumpster/blob/master/canscripts/setup distrap/dumpster].

=== Brining up native interface ===

=== Using virtual CAN interface ===

Virtual CAN interface can be started with following commands:
{{cmd|code=
modprobe can
modprobe can-raw
modprobe vcan

ip link add type vcan
ip link add dev vcan0 type vcan
ip link set vcan0 up
}}

Script to initialize vcan0 can be found in [https://github.com/distrap/dumpster/blob/master/canscripts/setup_vcan distrap/dumpster].

=== Monitoring CAN traffic ===

candump utility can be used to dump traffic on the CAN interface:
{{cmd|code=
candump can0
# or
# candump vcan0
}}

=== Sending CAN messages manually ===

Use cansend utility, for example to send LSS identify uncofigured devices command:
{{cmd|code=
cansend can0 7E5#4C
}}

If you have such unconfigured node connected you should see its reply in candump:
{{cmd|code=
# candump can0
can0 7E5 [1] 4C
can0 7E4 [8] 50 00 00 00 00 00 00 00
}}

=== Running CANOpen node on POSIX ===

Build canopen-posix-test
{{cmd|code=
cd distrap-build/canopen/
make canopen-posix-test
}}

As root create virtual terminal pair (linking /dev/ttyS0 with /dev/ttyS1) and start SLCAN on one side and
POSIX node on the other side (POSIX node utilizes SLCAN on its side as well
to convert SLCAN traffic to CAN traffic internally). To do so start the
following commands as root:
{{cmd|code=
socat -d -d pty,link=/dev/ttyS0,raw,echo=0 pty,link=/dev/ttyS1,raw,echo=0
# start slcand on one side
slcand -F -s8 -S115200 /dev/ttyS0 can0

ip link set can0 up

# start canopen-posix-test on the other side
# for that go to the canopen folder you've used in previous step to build
# a binary as this needs to be started by root (or use su -c ".." as a normal user)
./build/canopen-posix-test/tower_init <> /dev/ttyS1 > /dev/ttyS1
}}

Now the node is running and should respond to messages. It first needs to be configured
(node ID is set during LSS phase) and then it can be used for testing fully featured
CANOpen communication. Try talking to it as described in section [[#Sending CAN messages manually]].

GettingStarted

2017-09-30T00:15:24Z

Srk: init GettingStarted

== Required equip ==
* Linux computer
* F4 Discovery board
* [[CAN4DISCO]] board
* STLink programmer(s)
* Slave nodes

== Software stack ==

You can build the complete stack according to instruction on [https://github.com/distrap/distrap-build distrap-build] repository.

=== UDev rules ===

For persistent device names you should create udev rules files in ''/etc/udev/rules.d/''. For example
to create rules for your F4 Discovery board flashed with Black Magic probe firmware you can use the following
template:
{{cmd|code=
# F4 Discovery
SUBSYSTEMS=="usb", ATTRS{manufacturer}=="Black Sphere Technologies", ATTRS{serial}!="E3C09CF4", GOTO="f4_bmp_end"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic GDB Server", MODE="0660", GROUP="dialout", SYMLINK+="f4gdb"
ACTION=="add", SUBSYSTEM=="tty", ATTRS{interface}=="Black Magic UART Port", MODE="0660", GROUP="dialout", SYMLINK+="f4uart"
LABEL="f4_bmp_end"
}}

Make sure to set correct ''serial'' number, this can be found by running ''dmesg'' after the board is plugged in.
Create similar file as ''/etc/udev/rules.d/48-distrap.rules'' and run
{{cmd|code=
udevadm control -R
}}
to reload UDev daemon. Next time you plug in your device two nodes should be created
* /dev/f4gdb - for attaching GDB
* /dev/f4uart - UART2 pass-through

== Hardware ==

=== Flashing ===
=== Debugging ===
==== Black Magic Probe ====

== CAN ==

Either you Linux computer or single board computer like Raspberry Pi or BeagleBone Black
can be used as CAN master. For development purposes powerful computer is better
due to shorter compilation time, for production BeagleBone Black or ODROID XU4 is a good choice.

=== Bringing up SLCAN bridge ===

Assuming you are using [[CAN4DISCO]] as UART2CAN bridge you can bring up CAN network
with following commands:
{{cmd|code=
modprobe can
modprobe can-raw
modprobe slcan
slcand -F -s8 -S115200 /dev/f4uart can0 # CAN speed 8 -> 1Mbit
ip link set can0 up
}}

Script to initialize SLCAN can be found in [https://github.com/distrap/dumpster/blob/master/canscripts/setup distrap/dumpster].

=== Brining up native interface ===

=== Using virtual CAN interface ===

Virtual CAN interface can be started with following commands:
{{cmd|code=
modprobe can
modprobe can-raw
modprobe vcan

ip link add type vcan
ip link add dev vcan0 type vcan
ip link set vcan0 up
}}

Script to initialize vcan0 can be found in [https://github.com/distrap/dumpster/blob/master/canscripts/setup_vcan distrap/dumpster].

=== Monitoring CAN traffic ===

candump utility can be used to dump traffic on the CAN interface:
{{cmd|code=
candump can0
# or
# candump vcan0
}}

=== Sending CAN messages manually ===

Use cansend utility, for example to send LSS identify uncofigured devices command:
{{cmd|code=
cansend can0 7E5#4C
}}

If you have such unconfigured node connected you should see its reply in candump:
{{cmd|code=
# candump can0
can0 7E5 [1] 4C
can0 7E4 [8] 50 00 00 00 00 00 00 00
}}

=== Running CANOpen node on POSIX ===

Build canopen-posix-test
{{cmd|code=
cd distrap-build/canopen/
make canopen-posix-test
}}

As root create virtual terminal pair (linking /dev/ttyS0 with /dev/ttyS1) and start SLCAN on one side and
POSIX node on the other side (POSIX node utilizes SLCAN on its side as well
to convert SLCAN traffic to CAN traffic internally). To do so start the
following commands as root:
{{cmd|code=
socat -d -d pty,link=/dev/ttyS0,raw,echo=0 pty,link=/dev/ttyS1,raw,echo=0
# start slcand on one side
slcand -F -s8 -S115200 /dev/ttyS0 can0

ip link set can0 up

# start canopen-posix-test on the other side
# for that go the canopen folder you've used in previous step to build
# a binary as this needs to be started by root (or use su -c ".." as a normal user)
./build/canopen-posix-test/tower_init <> /dev/ttyS1 > /dev/ttyS1
}}

Now the node is running and should respond to messages. It first needs to be configured
(node ID is set during LSS phase) and then it can be used for testing fully featured
CANOpen communication. Try talking to it as described in section [[#Sending CAN messages manually]].

Main Page

2017-09-30T00:15:24Z

Srk: init GettingStarted

Template:Cmd

2017-09-29T23:52:53Z

Srk: init

<noinclude>
Helper template for rendering command line commands.

Usage: <nowiki>{{cmd|git clone test.repo}}</nowiki> (defaults to bash). Different lang: <nowiki>{{cmd|lang=cpp|code=x ^= 1337</nowiki>.

If using special characters and not getting any result <nowiki>code=</nowiki> is required: <nowiki>{{cmd|code=a=2*b&c}}</nowiki>

* [https://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi#Supported_languages supported lang(s)]
</noinclude>
<div class="b48mw-cmd">
{{#tag:syntaxhighlight|{{{code|{{{1}}}}}}|lang="{{{lang|{{{2|bash}}}}}}"}}
</div>

FAQ

2017-09-29T22:14:20Z

Srk: init FAQ

Software

2017-09-29T22:14:20Z

Srk: init Software

== Firmware ==

* can4disco - firmware for [[CAN4DISCO]] (UART2CAN and various utilities)
* lambdadrive - BLDC driver firmware

== Client side ==

=== liveplot ===

* https://github.com/distrap/liveplot

Live plotting with OpenGL. This Haskell library allows feeding live data via Pipes to OpenGL plots.

== CANOpen ==

=== cidl ===

* https://github.com/distrap/cidl

Cidl (for CANOpen Interface Description Language) is a simple IDL for
describing CANOpen dictionaries. It generates native Haskell code and
Ivory/Tower code to be used with in conjunction with ivory-tower-canopen.

=== ivory-tower-canopen ===

* https://github.com/distrap/ivory-tower-canopen

CANOpen protocol implementation in Ivory/Tower.

Implements [[CANOpen#LSS]], [[CANOpen#NMT service]], [[CANOpen#SDO service]],
[[CANOpen#PDO]] services.

== Ivory/Tower ==

=== ivory-tower-base ===

* https://github.com/distrap/ivory-tower-base

Various utilities for Ivory/Tower. Includes debugging towers, UART, CAN and GPIO
related definitions and shortcuts. Also contains utility functions like puts, putc, putHex.

Hardware

2017-09-29T21:34:04Z

Srk: add can4disco

== Index ==

* [[CAN4DISCO]]
* [[DISTRAP Connector Specification]]

CAN4DISCO

2017-09-29T21:34:04Z

Srk: add can4disco

== CAN4DISCO ==

UART2CAN bridge (with kernel support via SLCAN protocol) and CAN development board/firmware.

This is a base board for F4 Discovery development board exposing both CAN interfaces
with SN65HVD230DR CAN transcievers. Bunch of other ports are also exposed for testing
peripherals - advanced timer, UART, I2C, ADC, DAC.

Board is designed to be PCB milling friendly and has low part count - two SN65HVD230DR transcievers,
two CAN termination resistors (120R) and a bunch of pin headers.

As this board provides two CAN interfaces it can also be used for CAN driver development or testing
by simply interconnecting these two basically creating a loopback device.

* Design files https://github.com/distrap/can4disco-hw
* Firmware https://github.com/distrap/can4disco

Main Page

2017-08-26T22:52:16Z

Srk: init

CANOpen

2017-08-26T22:52:13Z

Srk: init

= CANOpen =

CANopen is a communication protocol and device profile specification for embedded systems used in automation.

* https://en.wikipedia.org/wiki/CANopen
* specifications https://www.can-cia.org/
* mirror http://overpof.free.fr/schneider/CAN%20&%20CANopen/CANopen/%A9CiA%20CANCANopen%20CD%20V5.1/index.htm

== Object dictionary ==

Object dictionary encapsulates all of the CAN exposed variables and allows reading or writing to
sections specified by index and subindex. All variables have types and complex types are allowed - records and arrays.

Two major parts of the object dictionary are defined - communication profile area in range ''0x1000-0x1FFF''
and application profile area (Standardised Device Profile Area) in range ''0x6000-0x9FFF''. Communication
profile parameters are used internally by CANOpen stack (e.g. heartbeat period, pdo parameters) while application profile area defines application
parameters (e.g. target velocity, control word).

* Specification is part of CiA 301

=== Layout ===

Object dictionary sections:

<pre>
0000 not used
0001-001F Static Data Types
0020-003F Complex Data Types
0040-005F Manufacturer Specific Complex Data Types
0060-007F Device Profile Specific Static Data Types
0080-009F Device Profile Specific Complex Data Types
00A0-0FFF Reserved for further use
1000-1FFF Communication Profile Area
2000-5FFF Manufacturer Specific Profile Area
6000-9FFF Standardised Device Profile Area
A000-BFFF Standardised Interface Profile Area
C000-FFFF Reserved for further use
</pre>

== NMT service ==

Network management services allows controlling node state transitions. Also provides heartbeat functionality.
On boot, CANOpen node automatically enters pre-operational NMT state, where node configuration usually takes place.
After configuration, node can be switched to operational state where PDO services are available. NMT also defines
initialising state, stopped state and two states for resetting object dictionary values - reset application
and reset communication for resetting respective parts of object dictionary.

* Specification is part of CiA 301

== SDO service ==

Allows reading or writing to variables in object dictionary. Device can implement multiple SDO services
but generally only one service (default SDO) is provided that allows object dictionary variable access.

SDO Upload -> Read register from device:

# rs-canopen-sdo-upload vcan0 05 6000 01

vcan0 605 [8] 40 00 60 01 00 00 00 00

SDO Download -> Write register to device:

# rs-canopen-sdo-download vcan0 05 6000 01 13

vcan0 605 [8] 2F 00 60 01 13 00 00 00

* Specification is part of CiA 301.
* COB-ID for default SDO tx (transmitted from node) - '''0x580 + node ID'''
* COB-ID for default SDO rx (received by node) - '''0x600 + node ID'''

== PDO ==

PDO or Process Data Objects allow communication without protocol overhead. PDO allows mapping of single or multiple variables
into one CAN message with specific ID. This allows usage of all 8 bytes of CAN message data and allows writing or reading
multiple variables at once.

There are two kinds of PDOs: transmit and receive PDOs (TPDO and RPDO). Transmit PDOs are used to read data from node
and receive PDOs are used for writes.

For example RPDO for servo controller can contain mapping to two variables - ''control word'' and ''target velocity''. Both of these
are 32 bit values

* ''control word'' unsigned int32 at address ''0x6040''
* ''target velocity'' signed int32 at address ''0x60FF''

This fills up full 8 bytes of CAN data.

In similar manner, TPDO can be used for monitoring the drive, example mapping can look like this:

* ''status word'' unsigned int32 at address ''0x6041''
* ''velocity actual'' signed int32 at address ''0x606C''

Specification is part of CiA 301.

== SYNC ==

Node synchronization is accomplished with the help of SYNC message. This can be used to either sample
current sensor values at SYNC time or apply buffered SDO data to all variables at once.

* Specification is part of CiA 301
* COB-ID used by SYNC message is '''0x80'''

== LSS ==

Layer Setting Services and Protocol allows configuration of node ID and CAN baudrate.
This protocol runs prior other CANOpen services as they require node ID to be configured.

Typically used when adding new nodes to the system. Non-configured node boots into LSS mode indicated
by both LEDs blinking rapidly. Node ID and baudrate can be configured and configuration stored in
non-volatile memory for next boots. If node ID is valid device skips LSS mode and goes straight into
pre-operational state.

* LSS is defined in CiA 305
* COB-ID used by NMT is '''0x0'''

Main Page

2017-06-02T22:22:19Z

Srk: init

Hello world!