The Red Pitaya boards offer an SCPI server over an TCP/IP Socket connection. The makers describe how to use it. But instead of using plain pyVISA, they provide their own SCPI class.
That’s fine, because that class also provides handy functions to set the various in-built applications (signal generator and the likes).
But it is unnecessary complicated for a blinky example. And in my case, where I only needed some scriptable DIOs, it was quite cumbersome.
So, here is the blinky re-written in plain pyVISA:
import pyvisa as visa
from time import sleep
rm = visa.ResourceManager()
rp = rm.open_resource("TCPIP::169.254.XXX.XXX::5000::SOCKET",
read_termination="\r\n",
write_termination="\r\n"
)
print(rp.query("*IDN?"))
while True:
rp.write("DIG:PIN LED0,1")
sleep(.5)
rp.write("DIG:PIN LED0,0")
sleep(.5)
The magic lies in the read and write terminations. They have to be set to '\r\n'(in that order), or else the communication simply won’t work and time out.
Make sure you install a reasonably recent pyVISA and pyVISA-py (from pip) or libvisa (from your distro’s repository) before you start. For me (Ubuntu) this works as follows:
Breadboard with connected breakouts: ESP32 NodeMCU, microSC card slot, NEO-M8M GPS module with antenna, Sparkfun battery babysitter with battery and two 3.3V capable HC-SR04 ultrasonic range sensors
Breadboard with connected breakouts: ESP32 NodeMCU, microSC card slot, NEO-M8M GPS module with antenna, Sparkfun battery babysitter with battery and two 3.3V capable HC-SR04 ultrasonic range sensors
The annoyance by pavement and walkways blocked by parked cars has been rising again when I went back to parental leave with our second child. On the mere 900m from home to childcare, I was regularly blocked by parked cars despite the buggy only being 55cm wide.
The idea to measure and track the remaining width after motorists left their junk on/in my way grew already back in 2019. But there were always parts or time missing. Now finally, I am plugging together a little contraption that should be able to do what I want it to do: show and quantify how little space is left for pedestrians and how much of an obstacle this is to people who rely on small carts to help them move: parents, but also elderly with a walker or people in wheelchairs.
First things first: This is basically a remake of the famous OpenBikeSensor, which should – with a different firmware – totally work for this purpose, too. This is not about remaking the OBS. It’s rather a little write-up of what the process is about. And, of course, the proposal to use OBS or similar hardware to use for pavement width tracking (PWT, I guess I need a fancy three-letter shorthand 🤣).
The Sociopolitical Problem
For decades the city council of Darmstadt has simply tolerated parking on pavements. So much so that it is a very common sight in the city. This holds for many other German cities, too. But it causes trouble for pedestrians: You cannot walk next to each other, you can pass oncoming people only awkwardly (even more so during the pandemic), and finally if you’re trying to walk your baby to sleep or simply get somewhere with her or him, it’s close to scratching the sacred shiny finish of a car (Heil’ges Blechle) at best.
This is considered totally normal in Darmstadt: The pavement measures about 1.6-1.8 m but at least 50 cm of this width is occupied by wheeled sheet metal 23 hours a day. Such nicely cut green to the left is not the standard, by the way.You shall not pass: mailboxes, electrical and utilities boxes, parking ticketing machines (ironically), e-scooters or mere idiots inapt of proper parking block the way.
While the latter is an obvious problem (you’re blocked and have to cross the street or walk there), reporting such cases is a nuisance: call the #Unordnungsamt and if you’re lucky and someone picks up, they may come days later and instead of removing the car just fine the holder (the blocking car on the left was left in place for three days, the one in the middle for at least eight days). You can also report the car to the authorities. If you do that more often and happen to live in Bavaria, you risk a fine based on (imho grossly abused) data protection legislation (often being 8 times in the particular case). And then there are reports of city councils not going after the offenders even if presented with full evidence (at least this cannot be said for Darmstadt).
But the first, the constant abuse of pavement for parking, is indeed a problem. We have two push vehicles for our kids: one is a buggy (55 cm wide), one is a two seated bike trailer that works as buggy too (85 cm wide). Those are not excessive widths. The latter is about 15 cm wider than a wheelchair – though bear in mind that you need your hands to move the wheels, so 90 cm is consider the minimum passage width.
The hypothesis I want to prove with the BabyRanger (or any modified OBS) is: A large part of the public space is being obstructed by parked cars because pavement parking is tolerated.
The Technical Problem
Measuring distances ain’t easy. Estimating the distance between two obstacles left and right in a straight line, ideally perpendicular to either (at least one of) the obstacles’ surfaces, the walking direction and/or the footpath path direction is a different story still.
Other problems I can think of: Deciding which side of the street you are on. Whether you are blocked and have to change sides or simply wanted to cross the street. How to detect if the sensors are misplaced. How to install the system on the various kinds of carts there are. And so on…
Mapping those data in a geographically meaningful way without disclosing the whereabouts and routes of the user of the system, and how to visualise the whole thing, is a yet another story.
What I’m Currently Doing
At the moment all I am struggling with is the GPS module. I chose NeoGPS as framework and it’s powerful, but pretty easy to get lost in. At the moment, UART is doing its thing, the logic analyser can read meaningful data at the chosen settings too, and NMEA sentences are transmitted.
However, they only fill the buffer but don’t produce any fixes let alone position data.
So: I’m in between tinkering a little more or switching to a different framework.
[Update 2022-10-15]
Well, the 3.3V SD card breakouts arrived yesterday, so let’s go for a walk. Roughly 20 minutes (i.e. ~1200 seconds) and guess what this beauty scribbled to flash drive:
Measured distance between left and right walls during a 20 minutes walk with the BabyRanger v0.1. And yes, I hate myself too for plotting this in LibreOffice Calc.
So, even though I would say it’s been a very tidy situation on the pavements (judging from experience in the street I walked down), here we go: Below 100 cm almost half the time and towards the end down to 50 cm. To be taken with a huge pinch of salt though until stuff like alignment, stability, unexpected obstacles etc. are properly taken care of.
[End of Update 2022-10-15]
Invitation
While I will be able to devote only limited time on this, I invite anyone with an OBS to see what solution they could think of. And to contact me if you’re interested to work on this issue ☟
As discussed in [Insanity4004]’s excellent blog post, Xilinx packages their ISE and SDK suite with the necessary libraries (like Qt4 for example). Unfortunately, some seem to be missing and cause errors that are rather cryptic for the lay(wo)man.
In addition to providing libpng and libfreetype, I’ve noticed that in order to start the SDK (xsdk, part of the EDK package), you need to provide an older version of libcairo as well.
With the standard installation, starting xsdk results in:
[...]/EDK/bin/lin64 $ ./xsdk
Xilinx Software Development Kit
Xilinx EDK 14.7 Build EDK_P.20131013
Copyright (c) 1995-2012 Xilinx, Inc. All rights reserved.
Eclipse:
An error has occurred. See the log file
[...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/1655967348948.log.
[...]/EDK/bin/lin64 $ cat [...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/1655967348948.log
!SESSION 2022-06-23 08:55:48.743 -----------------------------------------------
eclipse.buildId=Release 14.7 Build SDK_P.20131013
java.version=1.6.0_21
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
Command-line arguments: -os linux -ws gtk -arch x86_64
!ENTRY org.eclipse.osgi 4 0 2022-mm-dd hh:mm:ss.605
!MESSAGE Application error
!STACK 1
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
[...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/org.eclipse.osgi/bundles/243/1/.cp/libswt-pi-gtk-3836.so: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates
no swt-pi-gtk in java.library.path
Can't load library: [...]/.swt/lib/linux/x86_64/libswt-pi-gtk-3836.so
Can't load library: [...]/.swt/lib/linux/x86_64/libswt-pi-gtk.so
[...]/.swt/lib/linux/x86_64/libswt-pi-gtk-3836.so: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:331)
at org.eclipse.swt.internal.Library.loadLibrary(Library.java:240)
at org.eclipse.swt.internal.gtk.OS.<clinit>(OS.java:22)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
at org.eclipse.swt.widgets.Display.<clinit>(Display.java:133)
at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:695)
at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:154)
at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:96)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
at org.eclipse.equinox.launcher.Main.main(Main.java:1414)
The reason is not too hard to find, but the error message is a mouthfull. The important bit is
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
[...]
/lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates
Which basically means: I am looking for libcairo, found it on your system, but the symbol (call, function, whatever) named FT_Get_Var_Design_Coordinates does not exist there.
I have not investigated the reasons for this further. I assume, this function got renamed, moved, dropped since 2013. So I followed the recipe proposed in the blog post mentioned in the beginning:
Move it to your [...]/EDK/lib/lin64 folder. In my case this is /opt/Xilinx/14.7/ISE_DS/EDK/lib/lin64.
I fear I might run into these issues again and again since we’re stuck here with a Virtex-6 device. I wonder if SymbiFlowF4PGA are working on a 6-series toolchain. That’d certainly create some resilience against the future.
Small side note I: The 6-series system here is supposed to replace an analogue RF control system that was in service for 30-something years. People were reluctant to switch to digital because of fears of this (what you see above): Toolchains being very complex and not working anymore after only a couple of years, vendors dropping support (well, Xilinx technically did not drop it entirely, but they’ve certainly not fixed library dependencies or checked that they ship their programmes with the old versions).
Small side note II: The fact that I can just (1) go to a trusted repository of old packages (Ubuntu’s Launchpad), (2) grab a package file, (3) extract an old shared library file, and (4) drop it in place without breaking my whole system, is a pretty awesome feature of Linux systems. I know for a fact that other platforms (yeah, looking towards the Seattle area) struggle with steps 1 and 4.
Post scriptum I: Trying to start xilhelp revealed three more libraries missing. libXp.so.6 (get it here), libXm.so.4 (run apt install libxm4) and libstdc++5 (you’ll have to go back to Ubuntu 14.04 Trusty for that). But ended in a SEGFAULT *sigh*.
Post scriptum II: Way more is broken than I had estimated! All Tcl-based scripts (that is: all IP Core generators) need libtcl8.4, obviously, duh! So, well get libtcl8.4.so from Ubuntu 16.04. At least, now the license wizard is opening up. But that causes all sorts of other problems with Tcl. I suppose it’s because no packages are installed in any way. Let’s say: ISE 14.7 is severely broken on newer systems. Way out 1: A VM with Ubuntu 14.04 or 16.04 (yikes!). Way out 2: F4PGA, maybe!?
