[SOLVED] Scratch for Robots with xRDP doesnt start



I bought the BrickPi a while back. It’s the one with a “on-switch”.
So far i followed the manual. Downloaded the Raspbian for Robots, installed it on the Pi 3,
also installed apg-get update and xrdp, to have a remote desktop.

so far so good… did setup fixed ip adresses and can connect without any hassles.
after that i did the dexterSoftware Update, it updated the firmware and all softwares.

so… first try…

clicked on “Scratch for Robots”. it opens a Scratch Controller, and that was it… no scratch windows gets opened and i cant start coding.


does somebody know how to fix this issue?
the troubleshooter shows all fine so far.

BrickPi3 Troubleshooting Script log

Checking for hardware, and checking hardware and firmware version.
Manufacturer    :  Dexter Industries
Board           :  BrickPi3
Serial Number   :  AC4B95AB515035524E4A2020FF07192A
Hardware version:  3.2.1
Firmware version:  1.4.6
Battery voltage :  8.735
9v voltage      :  9.372
5v voltage      :  4.988
3.3v voltage    :  3.35

Hello @MichaelM

You got pretty far already! Can you tell me which OS you downloaded ?
You mention DexterOS but that one doesn’t work with the BrickPi. I would like to know if you started from Raspbian for Robots, or Raspbian, and which version.

ETA: if you open a terminal window and type in scratch , does Scratch actually start?



Oh you’re right… i installed at first DexterOS, then i did see, that this is not for the brickpi.
Actually i have raspbian for robots installed. latest versions from all of them.

when typing scratch into the terminal, it takes close to 2mins, and then gives this error.
guess it needs scratch 1 installed but it failed or isnt preinstalled on the latest raspbian for robots?



it seems that it has to do something with the tightvncserver as scratch is not possible to start as user : pi and needs to be startet as :root instead.

is it possible to tell the scratch controller, that it should start my scratch with sudo scratch? instead of just scratch? i guess this would solve the issue


This is weird. I have the latest Raspbian for Robots (from April 2019) and I do not have this issue. Did you do something else on the card? Did you run an update?

Scratch shouldn’t need sudo to start.



Nope, just what i said.
downloaded your image for raspbian for robots, installed tightvncserver, xrdp (to headless remote desktop) and update all software.

many people have issues with starting scratch 1 through remote desktop, just because it cannot start in user pi through vncserver, it needs root user.

i can start it with sudo scratch, but your tool (scratch for robots) only starts scratch and i need to have the scratch for robots modified, so that it starts scratch as root.
how can i change that?

scratch2 is no issue, that works with vnc, but not scratch1.


Which VNC viewer are you using? This is news to me as my VNC viewer works just fine, even if I go through a browser.

Oh, I just saw something! If you download Raspbian for Robots, tightvncserver is already installed for you, with proper parameters. I think the issue might be with xrdp as we only support VNC. I’ll investigate that and report back.


If you want to edit the file directly,
go to /home/pi/Dexter/lib/Dexter/Scratch_GUI
and edit the one before last line in scratch_direct

It reads as scratch "$DOCUMENT"
Make it as sudo scratch "$DOCUMENT"

I hope this works for you!


ah, VNC connection is on the image… well… hehe…
ok, it works with VNC.

but it also works now with RemoteDesktop from Windows.
Good thing with remote desk is, bigger image, more workspace :wink:

so… sudo scratch “$DOCUMENT” did fix the xrdp thing

1 Like

I have a preference for xrdp too. Unfortunately, it’s not universally supported (looking at you, MacOS. And chromebooks too). So it’s not something we can officially support.

Glad the sudo worked for you! Side effect of using sudo here is that the scratch files will be saved as root, and not as easy to delete if you want to clean up your SD card. Obviously you can, but students most likely won’t be able to. (and that’s not necessarily a bad thing)