I am running ros kinetic in Ubuntu 16.04 on Oracle VM Virtual Box.
I am launching gazebo with:
roslaunch turtlebot_gazebo turtlebot_world.launch
I then try to echo the /scan topic with: (I have checked that it's being published):
rostopic echo /scan
It outputs:
WARNING: no messages received and simulated time is active.
Is /clock being published?
/clock is indeed being published.
And then gazebo crashes with the following:
gzserver: /build/ogre-1.9-mqY1wq/ogre-1.9-1.9.0+dfsg1/OgreMain/src/OgreRenderSystem.cpp:546: virtual void Ogre::RenderSystem::setDepthBufferFor(Ogre::RenderTarget*): Assertion `bAttached && "A new DepthBuffer for a RenderTarget was created, but after creation" "it says it's incompatible with that RT"' failed.
Aborted (core dumped)
[gazebo-2] process has died [pid 8979, exit code 134, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode /opt/ros/kinetic/share/turtlebot_gazebo/worlds/playground.world __name:=gazebo __log:=/home/joshua/.ros/log/409e3080-4711-11e9-abe9-0800270fc685/gazebo-2.log].
log file: /home/joshua/.ros/log/409e3080-4711-11e9-abe9-0800270fc685/gazebo-2*.log
I have tried setting my VM to accelerate 3D graphics, create my own rosnode that subscribes to /scan and look at help threads I can find yet I still cannot solve this issue. Any assistance would be great.
Additional note:
I can rostopic echo /clock perfectly fine, and control the turtlebot with teleop perfectly fine as well.
To solve this issue I was required to update gazebo:
Step 1:
sudo sh -c 'echo "deb http://packages.osrfoundation.org/gazebo/ubuntu-stable `lsb_release -cs` main" > /etc/apt/sources.list.d/gazebo-stable.list'
Step 2:
wget http://packages.osrfoundation.org/gazebo.key -O - | sudo apt-key add -
Step 3:
sudo apt-get update
Step 4:
sudo apt-get install gazebo7
Accessing the /scan topic with rostopic echo /scan now works as intended.
Related
I tried to build a gdb for esp32 that works with qemu, but after many attempt, I didn't manage. All my attempts leaded me to the following error message after connecting to the remote target: Remote 'g' packet reply is too long.
Right now I am using the prebuilt version from Ebiroll: https://github.com/Ebiroll/qemu_esp32/blob/master/bin/xtensa-esp32-elf-gdb
but I would like to use a newer gdb version than 7.10, did anyone had success with this?
Here is how I built gdb:
git clone --depth 1 --branch esp-2021r2-gdb https://github.com/espressif/binutils-gdb.git
cd binutils-gdb
mkdir -p build
cd build
../configure --without-guile --host=x86_64-pc-linux-gnu --target=xtensa-esp32-elf --disable-werror
make
make install
(note from this branch the patch to apply from the Zephyr project, as described here https://github.com/Ebiroll/qemu_esp32#qemu-esp32, seems to already be included)
I also tried by applying the following patch (no success):
curl -L https://raw.githubusercontent.com/Ebiroll/gdb/master/gdb/xtensa-config.c.qemu --output binutils-gdb/gdb/xtensa-config.c
or patching qemu to fix the value of num_regs (tried 104 and 172, also no success).
Espressif's qemu wiki mentions setting an environment variable to only list the core registers:
export QEMU_XTENSA_CORE_REGS_ONLY=1
This needs to be set in the environment from where qemu will be executed.
My recommendation is to use both qemu and gdb (from the Esp32 tool chain) as provided by Espressif. I have recently used this combination with success. The latest release uses gdb 9.2.
Debugging my own kernel with qemu and gdb seems to be unnecessarily hard because pressing ctrl-c in gdb to break qemu does not break it, but makes it quit with the message
qemu-system-x86_64: terminating on signal 2
[Inferior 1 (Remote target) exited normally]
qemu command line:
qemu-system-x86_64 -s -no-shutdown -no-reboot -enable-kvm -m 1G -smp cores=1 -cpu qemu64 -drive if=pflash,format=raw,file=ovmf/OVMF.fd -drive file=fat:rw:hda,format=raw -net none -debugcon file:debug.log -global isa-debugcon.iobase=0x402 &
The behavior is the same without KVM. Could someone please help, how to solve this?
qemu-system-x86_64 v3.1.0
gdb v8.2.1
I would like not to build the latest versions of these from source as it seems to be a daunting task to do.
EDIT: Created a minimal environment where the issue can be reproduced. I may have tracked it down to running the whole thing from a shell script, but can't seem to progress further. Commenting out the gdb call in the script and starting it from a separate terminal, solves the issue (however i like things that work with as few keystrokes as possible).
You can download it here.
Just start the script called qd
(Is there a nicer way to provide files? I will delete this after a while.)
I tested with QEMU 5.0.0 and GDB 9.2, same issue, and same solution, that is commenting out the GDB call in the script and starting it from a separate terminal. You could probably just modify your script so that QEMU would be started in another
terminal. Starting QEMU using nohup is not working either.
I included the script I am usually using for building fresh versions of QEMU and GDB: latest versions are likely to have fixed bugs. The script is working on Ubuntu 20.04, and is probably still working on 16.04 and 18.04 - you may have to make small adjustments at the beginning of the script. Feel free to report issues, I would be willing to fix them.
build-qemu-gdb.sh:
#!/bin/bash
set -e
# Xenial/16.04
PERL_MODULES_VERSION=5.22
SPHINX=python-sphinx
# Bionic/18.04
PERL_MODULES_VERSION=5.26
SPHINX=python-sphinx
# Focal/20.04
PERL_MODULES_VERSION=5.30
SPHINX="sphinx-doc sphinx-common"
# Qemu
QEMU_VERSION=5.0.0
PREFIX=/opt/qemu-${QEMU_VERSION}
# GDB
GDB_VERSION=9.2
do_get_gdb()
{
if [ -f gdb-${GDB_VERSION}.tar.xz ]
then
echo "gdb-${GDB_VERSION}.tar.xz is present."
else
wget http://ftp.gnu.org/gnu/gdb/gdb-${GDB_VERSION}.tar.xz
fi
}
do_get_qemu()
{
if [ -f qemu-${QEMU_VERSION}.tar.xz ]
then
echo "qemu-${QEMU_VERSION}.tar.xz is present."
else
wget https://download.qemu.org/qemu-${QEMU_VERSION}.tar.xz
fi
}
do_install_prerequisites()
{
sudo apt-get install libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev libaio-dev libbluetooth-dev libbrlapi-dev libbz2-dev libcap-dev libcap-ng-dev libcurl4-gnutls-dev libgtk-3-dev libibverbs-dev \
libjpeg8-dev libncurses5-dev libnuma-dev librbd-dev librdmacm-dev libsasl2-dev libsdl2-dev libseccomp-dev libsnappy-dev libssh2-1-dev libvde-dev libvdeplug-dev libvte-2.91-dev libxen-dev liblzo2-dev \
valgrind xfslibs-dev liblzma-dev flex bison texinfo gettext perl perl-modules-${PERL_MODULES_VERSION} ${SPHINX}
}
do_configure()
{
local TARGET_LIST="x86_64-softmmu"
pushd qemu-${QEMU_VERSION}
./configure --target-list="${TARGET_LIST}" --prefix=${PREFIX} --extra-cflags="-I$(pwd)/packages/include" --extra-ldflags="-L$(pwd)/packages/lib"
popd
}
do_extract_qemu()
{
echo "extracting QEMU..."
rm -rf qemu-${QEMU_VERSION}
tar Jxf qemu-${QEMU_VERSION}.tar.xz
}
do_build_qemu()
{
echo "building..."
pushd qemu-${QEMU_VERSION}
make all
popd
}
do_install_qemu()
{
echo "installing..."
pushd qemu-${QEMU_VERSION}
sudo make install
popd
}
do_build_qemu()
{
do_extract_qemu
do_configure
do_build_qemu
do_install_qemu
}
do_extract_gdb()
{
echo "extracting GDB..."
rm -rf gdb-${GDB_VERSION}
tar Jxf gdb-${GDB_VERSION}.tar.xz
}
do_build_gdb()
{
do_extract_gdb
rm -rf gdb
mkdir gdb
pushd gdb
../gdb-${GDB_VERSION}/configure --enable-tui --prefix=/opt/gdb-${GDB_VERSION}-x86_64-none-elf --target=x86_64-none-elf --program-prefix=x86_64-none-elf-
make all install
popd
}
# main
do_install_prerequisites
do_get_qemu
do_build_qemu
do_get_gdb
do_build_gdb
The resulting new paths for QEMU and GDB after installation would be:
/opt/qemu-5.0.0/bin/qemu-system-x86_64
/opt/gdb-9.2-x86_64-none-elf/bin/x86_64-none-elf-gdb
I am trying to export Neptune RDF data using the following tools.
amazon-neptune-tools/neptune-export at master ยท awslabs/amazon-neptune-tools
https://github.com/awslabs/amazon-neptune-tools/tree/master/neptune-export
But, Error occurs.
Error
[ec2-user#bastin neptune-export]$ sh ./bin/neptune-export.sh export-rdf -e neptestdb-cluster.cluster-xxxxxx.ap-northeast-1.neptune.amazonaws.com -d /home/ec2-user/output
Creating statement files
Completed export-rdf in 1 seconds
An error occurred while exporting from Neptune:
java.lang.RuntimeException: java.lang.NullPointerException
at com.amazonaws.services.neptune.rdf.NeptuneSparqlClient.executeQuery(NeptuneSparqlClient.java:166)
at com.amazonaws.services.neptune.rdf.io.ExportRdfGraphJob.execute(ExportRdfGraphJob.java:31)
at com.amazonaws.services.neptune.ExportRdfGraph.run(ExportRdfGraph.java:55)
at com.amazonaws.services.neptune.NeptuneExportCli.main(NeptuneExportCli.java:54)
Caused by: java.lang.NullPointerException
at com.amazonaws.services.neptune.rdf.io.EnhancedTurtleWriter.handleStatement(EnhancedTurtleWriter.java:42)
at com.amazonaws.services.neptune.rdf.NeptuneSparqlClient$2.handleSolution(NeptuneSparqlClient.java:161)
at org.eclipse.rdf4j.query.resultio.binary.BinaryQueryResultParser.parse(BinaryQueryResultParser.java:192)
at org.eclipse.rdf4j.query.resultio.AbstractTupleQueryResultParser.parseQueryResult(AbstractTupleQueryResultParser.java:48)
at org.eclipse.rdf4j.http.client.SPARQLProtocolSession.getTupleQueryResult(SPARQLProtocolSession.java:693)
at org.eclipse.rdf4j.http.client.SPARQLProtocolSession.sendTupleQuery(SPARQLProtocolSession.java:372)
at org.eclipse.rdf4j.repository.sparql.query.SPARQLTupleQuery.evaluate(SPARQLTupleQuery.java:55)
at com.amazonaws.services.neptune.rdf.NeptuneSparqlClient.executeQuery(NeptuneSparqlClient.java:126)
... 3 more
[ec2-user#bastin neptune-export]$
The procedure is as follows.
Command
1. download tool
git clone https://github.com/awslabs/amazon-neptune-tools.git
2. install mvn for build
sudo wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.repo
sudo sed -i s/\$releasever/6/g /etc/yum.repos.d/epel-apache-maven.repo
sudo yum install -y apache-maven
mvn --version
3. execute build
cd /home/ec2-user/amazon-neptune-tools/neptune-export
mvn clean install
4. exexute neptune-export.sh
cd /home/ec2-user/amazon-neptune-tools/neptune-export
sh ./bin/neptune-export.sh export-rdf -e https://neptestdb-cluster.cluster-xxxxxxx.ap-northeast-1.neptune.amazonaws.com -d /home/ec2-user/output
If you have any idea, please contact us.
thank you for your cooperation.
Thanks for reporting this. I've identified the problem and will push an update to the repository later today or tomorrow. In the meantime, you can replace line 42 in EnhancedTutleWriter.java with the following:
Resource context = statement.getContext();
if (context != null){
prefixes.parse(context.stringValue(), this);
}
I am trying to run a Docker image based on an ARMv7 container on a x86 computer. According to this site, it is possible by running this container first.
docker run --rm --privileged hypriot/qemu-register
This command works on Mac OS X and on an Ubuntu 19 virtual machine (with a Windows 10 host). However, when I try to run on CentOS 7 and one of the AWS A1 instances, I get the message standard_init_linux.go:211: exec user process caused "exec format error". The CPU for the CentOS 7 is an Intel Core i7-8700K and AWS A1 is based on the Graviton processor.
Anyone know what I'm missing here?
The complaint on the AWS A1 instance is with installing miniconda. I'm not sure if there is a way to say yes (to continue to install) since the -b flag already is supposed to get miniconda to install silently.
Step 6/11 : RUN /bin/bash /tmp/miniconda.sh -b -p /opt/miniconda
---> Running in ab9b5fef6837
WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> Aborting installation
AWS A1 instances do support running Armv7 binaries. Using the available Ubuntu 18.04 AMI for A1, run this on the command line:
cat /boot/config-4.15.0-1043-aws | grep "CONFIG_COMPAT=y"
If this succeeds, then the AMI and kernel have been built with support for running 32-bit executables on the 64-bit platform. To test this capability, install using apt-get install gcc:armhf libc6:armhf to get a minimal 32-bit build environment, create an executable and execute readelf -h on it. You should see the Machine listed as ARM, not AArch64. Execution should also succeed.
Testing docker with armv7 images also works out of the box on the Ubuntu 18.04 AMI on A1. I tested via docker pull armhf/ubuntu:latest and then entered interactive mode using bash and tried installing Miniconda3. The problem does appear to be with the Miniconda install script linked above. It tries this unconditionally on line 58:
if [[ `uname -m` != 'armv7l' ]]; then
echo -n "WARNING:
Your processor does not appear to be an armv7l. This software
was sepicically build for the Raspberry Pi 2 running raspbian wheezy
(or above).
Are sure you want to continue the installation? [yes|no]
[no] >>> "
read ans
if [[ ($ans != "yes") && ($ans != "Yes") && ($ans != "YES") &&
($ans != "y") && ($ans != "Y") ]]
then
echo "Aborting installation"
exit 2
fi
fi
Docker does not do any rewriting of what uname -m returns, it will see AArch64 on the A1 instance and it will trip up there. Commenting this block out should get you going on the A1 instances.
For getting this to work on your x86 laptop, you will need to copy qemu-arm-static to the docker image to enable emulation. I am not sure, but I would suspect that uname would still not return the proper machine-type Miniconda expects.
I did the following both on Ubuntu 14 and SUSE Linux Enterprise Server 11 (x86_64) where libcgroup is installed, with root:
cgcreate -t ngam:home -a ngam:home -g cpuset:/nadav2ndCpuSet
cgset -r cpuset.cpus=1 nadav2ndCpuSet
After that, if you cat /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.cpus,
you will get:
1
which is good! as it is supposed to work.
Then, from user ngam, I ran the following cmd:
cgexec -g cpuset:nadav2ndCpuSet ~/whileLoop
where whileLoop is just a simple program that runs in a loop doing sqrt.
After that, I got the following error msg:
cgroup change of group failed
Why is it happening?
Thanks!
I ran into something similar while playing with cgroups on Ubuntu 16.04 just now.
When using the controller cpuset, cpus and mems are not initiated. Therefor you manually have to do it. Since you already specified cpuset.cpus you only need to set cpuset.mems
simply running
echo 0 > /sys/fs/cgroup/cpuset/nadav2ndCpuSet/cpuset.mems
or
cgset -r cpuset.mems=0 nadav2ndCpuSet
would solve your problem.
for more info on cpuset see http://man7.org/linux/man-pages/man7/cpuset.7.html
What I found is I forgot to make cgconfig start with system reboot, so a simple systemctl start cgconfig resolve the problem, and then do not forget systemctl enable cgconfig to make it start with system reboot.
I know my this answer might not be relevant to the question. I hope when people search the error cgroup change of group failed, this answer could help them.
BTW: systemctl start cgconfig is for centos 7, for centos 6 you may use service cgconfig start / chkconfig cgconfig on