I am trying to run gym-gazebo on Google Colaboratory.
There is a problem to run gazebo server (gazebo without gui) on Colab.
There was warning on display: Unable to create X window. Rendering will be disabled but I think I fix it.
There also warning about sound card. not sure it related Unable to open audio device,
And there warning about conversion Conversion of sensor type[depth] not supported
Here is an example
Can you help?
In order to run gazebo in a headless mode you need to run gserver executable, instead of gazebo. Not sure which one is used by the gym-gazebo toolkit.
In order to still do rendering in gazebo server (e.g. camera view) you would need to use Xvfb (X Virtual Frame Buffer). It is an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
For your specific colab notebook I have changed last cell by adding
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &')
in order to create virtual display and added DISPLAY=:1.0 to the beginning of the last line, so it looked as follows
DISPLAY=:1.0 python gym-gazebo/examples/turtlebot/circuit2c_turtlebot_camera_dqn.py
DISPLAY=:1.0 tells X Window client used by gazebo to use virtual display we have created instead of default one :0.
A complete installation of Gazebo on colab and running it in headless server mode with rendering capability can be achieved the following way:
!curl -sSL http://get.gazebosim.org | sh # Install gazebo
!apt-get install -y xvfb # Install X Virtual Frame Buffer
get_ipython().system_raw('Xvfb :1 -screen 0 1600x1200x16 &') # create virtual display with size 1600x1200 and 16 bit color. Color can be changed to 24 or 8
!source /usr/share/gazebo-9/setup.sh && DISPLAY=:1.0 gzserver --verbose # Run gazebo and tell X client to use our virtual DISPLAY :1.0
There is also a way to run full gazebo in simulator with gzweb as a head and link to it using ngrok.io explained here as a fully working notebook. https://colab.research.google.com/drive/1A-miW8cTRKzs7B0m1m4enfiFySzBhsgN
You would need to authenticate to ngrok using your auth token which can be created at ngrok.com in order to connect, because it is lunch as background and doesn't print to cell
!./ngrok authtoken <token>
Related
I'm running a udev rule on my 3D printing server to automatically create easily identifyable symlinks to some attached microcontroller boards, which worked perfectly fine on ubuntu 20.04.
The rule triggers on the usb vendor and product ids and runs a python script via the PROGRAM directive. The script connects to the Microcontroller boards and reads it's init sequence to get the board's 'name'. It then outputs a string like "aaaaaaa b cccccc" and only the first block (containing the name) is used in the udev rule.
However, it seems like the whole PROGRAM directive is not executed at all anymore, since I updated my system to ubuntu 22.04.1.
My udev rule currently looks like this (While debugging. Regularly it just contained lines 1 and 3. I added #2 for testing purposes because the hook in line 1 works and that script is executed):
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", RUN="/bin/su me -c \"/opt/me/deviceReg.py -d %k -a %E{ACTION}\""
KERNELS=="ttyUSB*", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6001", ENV{ID_SERIAL_SHORT}!="AI046A0Q", ACTION=="add|remove", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}!="AI046A0Q", PROGRAM="/opt/me/serialUdev.py -s %s{serial} /dev/%k", SYMLINK+="%c{1}", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QXPRV7", SYMLINK+="tty_MainSwitch", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9QOIMJ6", SYMLINK+="tty_Cooler", GROUP="dialout", OWNER="me", GOTO="script_end"
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ATTRS{serial}=="A9PTMHGV", SYMLINK+="tty_CurrentTransformer", GROUP="dialout", OWNER="me", GOTO="script_end"
The python scripts write to some logfiles which clearly indicate that only lines 1 and 4, 5 or 6 are executed.
Is there anything in line 3 that isn't supported anymore in the latest udev version? As I said, line 3 worked perfectly before I updated the system.
The last 3 lines are my current workaround. They work fine but that's not what I want to achive with this whole naming system at all.
The python script in lines 2 & 3 runs perfectly fine, either if called as standard user or as root. It would also deliver valid output if the '-s ' input data is not matching the uc board, is missing or is random garbage.
Does anyone have an idea why the script omits any line with a PROGRAM statement?
Ok, I was able to solve the issue.
I set udev's log level to debug too see what's actually happening when the device is handled. The script actually IS invoked but immediately failed during importing needed modules: The pyserial module could not be found.
The module is installed though, but obviously in a way it could not be imported.
However, I checked the python script again and changed the first line from #!/usr/bin/env python3 to #!/usr/bin/python3 and now it works again.
So my problem actually wasn't related to udev at all, it was just my python script.
I am using following code: It works good on local system and one unix server, but fails on another server. Any idea what I might need to do
> library(chromote)
> set_default_chromote_object(
Chromote$new(browser = Chrome$new(args = "--no-sandbox"))
and I am getting following error:
Chrome debugging port not open after 10 seconds.
Two things you can check:
On the server in question, start chrome and go to chrome://version/ . Search the Command Line: section and make sure --enable-logging is in there.
Strat R on the server in question, and do:
library(chromote)
debug(chromote:::launch_chrome)
Now run that R-code in as normal and when it stops and waits for input, hit n and then enter and repeat hitting enter until you get to the lines you link to on github. After line 87 when output gets defined, type output on the terinal and hit enter. Inspect the output and make sure that it actually conatins the lines DevTools listening on ws:// . If it does not, see if there are other ways that logging text identifies the port it listens to. If so, I would git clone that package, go in and change the way it discovers the port number and modify the package that runs for that server.
Running Chrome without X server
There are two viable options here:
vnc
X.org dummy driver
Here is the VNC recipe:
1: VNC
a. sudo dnf install tigervnc-server (for centos 8), sudo yum install tigervnc-server (for centos 7)
b. vncserver :1 (or some other suitable number)
c. DISPLAY=:1 R # and run R code to launch chrome etc.
Now you can connect from your client and see that chrome runs as it should:
vncviewer centos.ip.address:1
2: X.org dummy
I have never done this myself, but in theory it should be straight forward if you read docs and follow a tutorial.
I would like to run Nvim-R on a remote machine via putty when I try to open a *.R file the remote machine returns an error message:
Please set the variable g:R_term_cmd in your vimrc. Read the plugin
documentation ...
According to the documentation, the R_term_cmd should be used in the following manner:
If |R_in_buffer| = 0 and the X Window System is running and tmux is
installed, then R will run in an external terminal emulator. The
plugin uses the first terminal emulator that it finds in the following
list:
1. gnome-terminal,
2. konsole,
3. xfce4-terminal,
4. Eterm,
5. (u)rxvt,
6. aterm,
7. roxterm,
8. terminator,
9. lxterminal
10. xterm.
If Vim does not select your favorite terminal emulator, you may define
it in your vimrc by setting the variable R_term, as shown below:
let R_term = "xterm"
If your terminal emulator is not listed above, or if you are not satisfied with the way your terminal emulator
is called by the plugin, you may define in your vimrc the variable
R_term_cmd, as in the examples below:
let R_term_cmd = "xterm -title R -e"
let R_term_cmd = "xfce4-terminal --icon=/path/to/icons/R.png --title=R -x"
However, this variable does not appear to be utilised by the sample configuration files available through the Vim-R-Tmux: An Integrated Working Environment for R. Furthermore, the settings in vimrc:
" start R with F2 key
map <F2> <Plug>RStart
imap <F2> <Plug>RStart
vmap <F2> <Plug>RStart
" send selection to R with space bar
vmap <Space> <Plug>RDSendSelection
" send line to R with space bar
nmap <Space> <Plug>RDSendLine
<LocalLeader> settings
The suggested <LocalLeader> settings not appear to work as pressing F2 does not launch connected R session.
Software versions
tmux 2.3
VIM - Vi IMproved 8.0
You have two options
Use Tmux, which you apparently are
This way, Nvim-R can actually use a tmux pane to start an R console.
Please refer to section 9.21 Integration with Tmux in the documentation.
You need to put the following in your vimrc:
let R_in_buffer = 0
let R_applescript = 0
let R_tmux_split = 1
Or just use NeoVim
NeoVim has a builtin terminal, which actually just works with the Nvim-R plugin.
I am currently working on a project which aims to find out what the system is doing behind a series of user interaction on the android UI. For example, if user click send button in Facebook Messenger, the measured response time for such action is 1.2 seconds. My goal is to figure out what the 1.2 seconds consist of. My friend suggested that I should take a look into 'Systrace'.
However, when I tried systrace on my HTC one M8, I have encountered some problems:
First, error opening /sys/kernel/debug/tracing/options/overwrite - no such file or directory. I solved this problem by building up the support of the kernel following http://opensourceforu.com/2010/11/kernel-tracing-with-ftrace-part-1/ and mount -t debugfs none /sys/kernel/debug. Then I could find the tracing directory. Besides, I set ro.debuggable=1 in file default.prop within Ramdisk and burn the boot.img into my phone.
Now I encounter another problem: when I run - python systrace.py --time=10 -o mynewtrace.html sched gfx view wm, the following error(19) pop up: error truncating /sys/kernel/debug/tracing/set_ftrace_filter: No such device (19). I don't know if the way my building up kernel support for systrace is incorrect or anything is missing.
Could anyone helps me out with this problem, please?
I think I have worked out the solution. My environment is Ubuntu 16.04 + HTC one M8. I will write the steps as followed:
open terminal and enter: $adb shell
(1) $su (2) $mount -t debugfs none /sys/kernel/debug. Now you should be able to see many directories under /sys/kernel/debug/. (You may cd into /sys/kernel/debug to confirm this)
New a new terminal and enter: dd if=/dev/block/platform/msm_sdcc.1/by-name/boot of=/sdcard/boot.img to generate the boot.img kernel image from your device.
Use AndroidImageKitchen to unpack the boot.img and find the default.prop within Ramdisk folder. Then change ro.debuggable=0 to ro.debuggable=1. Repack the boot.img and flash boot it to your device.
Once the device boot, under terminal, enter: adb root and message like: restarting adbd as root may pop up. Disconnect the USB and connect again.
cd to the systrace folder, e.g. ~/androidSDK/platform-tools/systrace and use:
python systrace.py --time=10 -o mynewtrace.html sched gfx view wm
Now you may able to generate your own systrace files.
I've built a simple test app with clutter: A stage with two ClutterText actors to display two words. It works OK when I run it from within gnome but running it from the tty (not gnome-terminal or xterm) with xinit my_app_binary I get an error:
failed to create drawable
Unable to initialize Clutter: Unable to select the newly created GLX context
Window manager error: Unable to initialize Clutter
If I run xinit gnome-terminal from the same tty everything works, gnome-terminal shows up in a black screen. That's the same I want to do with my app.
Is there anything I can do to overcome this error?
All the above are tested in Linux Mint 12. After normal boot I switch to a tty (ALT-F1) and stop lightdm (sudo /etc/init.d/lightdm stop).
Thanks!
EDIT: running as root everything works, so the question is: how to run it as a regular user?
Be sure to set the DISPLAY-var - add it in front of your command
DISPLAY=:0.0 /path/to/myapp
Sometimes this is an access-rights problem - the app should be started with the user who started the X-server
su user-started-x -c 'DISPLAY=:0.0 /path/to/myapp'