I'm trying to use OMNeT++ version omnetpp-6.0pre15 and sumo 1.11.0 and connecting veins to sumo. My system is MacOS Monetrey.When I run the following:
downloads/veins-master/sumo-launchd.py -vv -c ~/sumo/bin/sumo-gui
it shows a black page while time increases and the stops. My sumo-gui and netedit runs correctly and they both show the simulation. But the black screen rises when I use vein to run sumo-gui, I mean omnetpp.ini file in veins from OMNeT++. Also when I run:
downloads/veins-master/sumo-launchd.py -vv -c ~/sumo/bin/sumo-gui
it shows me the following
Listening on port 9999.
I tried the following command:
cd downloads
cd veins-master
cd bin
python veins_launchd -vv -c ~/sumo/bin/sumo-gui
the above also shows a black screen for sumo-gui after running veins> omnetpp.ini
This is the veins-master I downloaded:
https://github.com/sommer/veins/tree/master/
I appreciate if anyone can suggest me how can I fix it.
Related
So I am trying to get started developing on Fuchsia and I wanted to get the hello world component to run. However, following these steps doesn't work for me. I'm using core.qemu-x64 running on an Ubuntu 20.04 VM with Virtual Box. I have gotten the emulator to run with fx qemu -N but fx vdl start -N hasn't worked for me.
I run fx serve-updates but it just outputs "Discovery..." and never changes. Then I try to run fx shell run fuchsia-pkg://fuchsia.com/hello-world-cpp#meta/hello-world-cpp.cmx but it says "No devices found." It seem like this shouldn't be an issue because with Linux the device finder should automatically pick it up. Regardless I tried following the MAC instructions and setting the device with fx set-device 127.0.0.1:22. That just makes the run command say "ssh: connect to host 127.0.0.1 port 22: Connection refused". I also tried to set it to the device to the nodename outputted by the fx qemu -N command which is "fuchsia-####-####-####" but that just makes the run command say no devices are found again.
I have verified that I actually have the hello-world packages with the fx list-packages hello-world which outputs all the hello-world packages as expected.
Is there any way I can get the device to be discoverable by the shell command? Alternatively, can I run components like the hello-world component from the qemu emulator directly?
Please let me know if I can provide any additional information.
I guess I just wasn't patient enough. I assumed the emulator was done getting setup because it stopped giving console output and it allowed me to input commands but it seems I just had to wait longer. After 50 minutes of the fx qemu -N command running, the terminal that had fx serve-updates going finally picked up the device. Then I was able to execute the hello world component. It would be nice if the documentation at least gave an idea of how long the different commands would take before they'd be usable.
https://i.imgur.com/hYf1Bes.jpgm
I am trying to set up ROS and Gazebo in a VM running Ubuntu.
The goal is that I want to simulate Turtlebot with the open manipulator.
I installed everything without any issues.
Though I am not able to launch the Turtlebot environment on Gazebo (like here: http://emanual.robotis.com/docs/en/platform/turtlebot3/simulation/)
$roslaunch turtlebot3_fake turtlebot3_fake.launch
results in Gazebo staying forever in the state loading your world. After some time, it stops responding.
Launching the empty world however works.
I am using ROS 1 with Gazebo 7.0
My hardware setup:
MacBook Pro 13" 2019 with 16 GB RAM
Parallels VM: 3D virtual. ON, no performance limit, 4 CPU kernels, 12 GB RAM enabled
Thank you so much for your help.
After every change you made source your bash and make sure to run :
catkin make
if you've done this already then check if ros is installed properly by running
roscore
on one terminal and let it stay running.
After that try to launch your turtlebot on another terminal.
If it doesnt work even you have installed all of the needed things, i think the problem is with your VM, id recommend you to run ROS on Ubuntu running USB Stick.
cd ~/.gazebo/
mkdir models
cd models/
wget http://file.ncnynl.com/ros/gazebo_models.txt
wget -i gazebo_models.txt
ls model.tar.g* | xargs -n1 tar xzvf
try this gazebo try to download to packages that's why it waits u need internet for that this may take few mins
I was trying to flash the mendel-enterprise-chef-13 to the Coral EdgeTPU Development Board but got stuck after the command, "bash flash.sh."
The host computer is the MacBook Pro (2018) with macOS Mojave ver. 10 and connected with the Coral EdgeTPU Dev Board.
I have followed the instructions on the Coral Document listed at https://coral.withgoogle.com/docs/dev-board/get-started/.
The process went smooth up to without the problem untill the step 8 and 12.
mkdir -p ~/.local/bin
sudo mv ~/Downloads/platform-tools/fastboot ~/.local/bin/
pip3 install --user mendel-development-tool
and then install the CP210x USB to UART Bridge Virtual COM Port (VCP) driver for Mac.
screen /dev/cu.SLAB_USBtoUART 115200
fastboot 0
fastboot devices
1b0741d6f0609912 fastboot # I did not get this message
cd ~/Downloads
curl -O https://dl.google.com/coral/mendel/enterprise/mendel-enterprise-chef-13.zip
unzip mendel-enterprise-chef-13.zip \
&& cd mendel-enterprise-chef-13
bash flash.sh # Got stuck here.
I want to know how to fix the issues of flashing the mendel image.
this sounds like a problem with the USB-A USB-C cable, or the usb port on your host machine, have you tried a different port?
I am trying to install ROS on Raspberry Pi 3 (Raspbian Jessie).
After invoking following command, I realized that Raspberry Pi is freezing and it is not responding anymore-
sudo ./src/catkin/bin/catkin_make_isolated --install -DCMAKE_BUILD_TYPE=Release --install-space /opt/ros/indigo
I tried to power it off and re-run the above command. However, it got stuck again on the same line. I also tried to use CLI but got in vain. Please see below a picture-
Please see below the output of top command-
Any workaround, please? I want to use ROS Indigo on Raspberry Pi.
Your system is running out of memory. Even your swap is full. You can solve this issue in multiple ways:
Use less jobs to build your application by adding the option --jobs 1 as explained here
Close other memory hungry applications during your build process
Increase the swap partition like so
I know it's possible by using pulse audio on a Linux host system But paprefs is built for linux not mac.
The Docker-for-Mac VM doesn't have any sound passthrough device, so there isn't anything that you could take advantage of from that angle. By contrast, a virtualbox or vmware fusion VM does have the ability to do passthrough audio.
I was able to get pulseaudio installed and working on OSX with the following command:
brew install pulseaudio
I was able to verify this worked by running the following, hearing sound come out of my speakers:
paplay cockatiel.wav
My next step is to find an image that has a copy of paplay. I found jess/pulseaudio, which appears to be intended to be a pulseaudio server, but I should be able to use it as a client as well.
I found the following guide on the Archlinux Wiki discussing setting up pulseaudio network sound: https://wiki.archlinux.org/index.php/PulseAudio/Examples#PulseAudio_over_network
I was able to adapt it to this situation by doing the following. I edited /usr/local/Cellar/pulseaudio/9.0/etc/pulse/default.pa on my mac, and uncommented the following two lines:
load-module module-esound-protocol-tcp
load-module module-native-protocol-tcp
I reran paplay cockatiel.wav on my mac to make sure my changes still worked. the pulseaudio daemon seems to start on demand, and passes its complaints back to paplay to be printed on my screen if I made a typo. I still have sound with those changes to default.pa, so I'm satisfied that my changes didn't break anything.
Next, I ran the pulseaudio client in a container like this:
docker run --rm -v $HOME:$HOME -w $HOME -it \
-e PULSE_SERVER=192.168.10.23 \
-e HOME=$HOME --entrypoint paplay \
jess/pulseaudio $HOME/cockatiel.wav
What this does is run a container with my local home directory as a volume. This serves two purposes. The first is the fact that my cockatiel.wav is located inside $HOME. The second is because both the client and the server need to have a copy of the same ~/.config/pulse/cookie file (per that archlinux wiki guide).
The PULSE_SERVER environment variable is the en0 IP address of my OSX host, so paplay knows what to connect to.
The HOME environment variable is necessary so paplay can find the same ~/.config/pulse/cookie file.
I was able to play sound from a container running on my docker-for-mac via pulseaudio.
As long as you get the ~/.config/pulse/cookie file to appear in the correct location, you should be able to play sound. You don't have to use a host volume to accomplish this-- you could also do a 'docker cp', or even COPY it into an image.
Install PulseAudio on the Mac:
brew install pulseaudio
Run the daemon:
pulseaudio --load=module-native-protocol-tcp --exit-idle-time=-1 --daemon
In your Docker container:
Install PulseAudio, e.g., apt-get install pulseaudio.
set the following environment variable: ENV PULSE_SERVER=docker.for.mac.localhost
When you run it, share your ~/.config/pulse directory with the container for authentication.
You can run a test to see if it's working like this:
docker run -it -e PULSE_SERVER=docker.for.mac.localhost -v ~/.config/pulse:/home/pulseaudio/.config/pulse --entrypoint speaker-test --rm jess/pulseaudio -c 2 -l 1 -t wav