I am trying to run a helloworld.py using dronekit on my solo drone.
My environment is
dronekit==2.7.0
pymavlink>=2.0.0
When I try to run the simple helloworld example the vehicle.connect() timesout.
ERROR LOADING MAVNATIVE - falling back to python implementation
Connecting to udpin:0.0.0.0:14550...
>>> Link timeout, no heartbeat in last 5 seconds
>>> No heartbeat in 30 seconds, aborting.
Traceback (most recent call last):
File "/log/solo-script/helloworld.py", line 9, in <module>
vehicle = connect("0.0.0.0:14550", wait_ready=True, baud=57600, heartbeat_timeout=30)
File "/log/solo-script/env/lib/python2.7/site-packages/dronekit/__init__.py", line 2787, in connect
vehicle.initialize(rate=rate, heartbeat_timeout=heartbeat_timeout)
File "/log/solo-script/env/lib/python2.7/site-packages/dronekit/__init__.py", line 2060, in initialize
raise APIException('Timeout in initializing connection.')
dronekit.APIException: Timeout in initializing connection.
I have tried downgrading pymavlink to 1.1.73 as well, but did not work. Any help is much appreciated.
I had the same problem.After downgrading pymavlink also build older version of dronekit. I used 2.0.0 and its worked.Here is a link for dronekit versions: https://github.com/dronekit/dronekit-python/releases
Make sure you are using python2. Dronekit uses pymavlink and dronekit code have been changed to python3 but pymavlink has given me a lot of issues in python3 and it works fine in python2.
It looks like an issue in vehicle.initialize method however try to set wait_ready=False, If it works then your solo it's not sending the parameters that dronekit is expecting:
# Default parameters when calling wait_ready() or wait_ready(True).
self._default_ready_attrs = ['parameters', 'gps_0', 'armed', 'mode', 'attitude']
Try updating your solo firmware and getting the latest dronekit and pymavlink versions from their git repo.
Related
I have just started learning Quantum Computing using Qiskit and was trying to draw my quantum circuit using the command circuit.draw(output='mpl'). However, it throws an exception:
---------------------------------------------------------------------------
MissingOptionalLibraryError Traceback (most recent call last)
<ipython-input-43-bd220039ee1c> in <module>
----> 1 circuit.draw(output='mpl')
6 frames
/usr/local/lib/python3.7/dist-packages/qiskit/utils/lazy_tester.py in require_now(self, feature)
222 return
223 raise MissingOptionalLibraryError(
--> 224 libname=self._name, name=feature, pip_install=self._install, msg=self._msg
225 )
226
MissingOptionalLibraryError: "The 'pylatexenc' library is required to use 'MatplotlibDrawer'. You can install it with 'pip install pylatexenc'."
---------------------------------------------------------------------------
NOTE: If your import is failing due to a missing package, you can
manually install dependencies using either !pip or !apt.
To view examples of installing some common dependencies, click the
"Open Examples" button below.
---------------------------------------------------------------------------
Then I tried installing the pylatexenc library, as mentioned in the exception using the command !pip install pylatexenc, imported it using from pylatexenc import * and then tried to use the command circuit.draw(output='mpl') again, but it still throws the same exception.
To make sure that the library was installed properly, I re-ran the command !pip install pylatexenc, but then it shows:
Looking in indexes: https://pypi.org/simple, https://us-python.pkg.dev/colab-wheels/public/simple/
Requirement already satisfied: pylatexenc in /usr/local/lib/python3.7/dist-packages (2.10)
Here is my complete code, I am running it in Google Collab's Jupyter Notebook:
from qiskit import *
from pylatexenc import *
qr = QuantumRegister(2)
cr = ClassicalRegister(2)
circuit = QuantumCircuit(qr, cr)
%matplotlib inline
circuit.draw(output='mpl')
One more point to add:
circuit.draw() and circuit.draw(initial_state = True) seem to work properly. Thanks for your help.
If you use google collab, then:
Use "pip install pylatexenc",
Restart the runtime,
Execute your code again.
This should help.
I think understood the mistake that I was making. So, first I ran the code on the Jupyter Notebook that I had set up on my local computer and it worked perfectly fine. However, when I tried to run the same code on the online Google Collab's Jupyter Notebook, it started throwing the exception. Now I am not sure if my solution is correct, but this is the difference and by running this command in the online environment, it works:
in addition to the existing process of installing the pylatexenc library, I also had to run this command:
IBMQ.save_account('your IBMQ API key')
so today i was trying to web scrape via apache-airflow but it is giving this error
File "/home/siva/.local/lib/python3.10/site-packages/selenium/webdriver/chromium/webdriver.py", line 89, in __init__
self.service.start()
File "/home/siva/.local/lib/python3.10/site-packages/selenium/webdriver/common/service.py", line 105, in start
raise WebDriverException("Can not connect to the Service %s" % self.path)
selenium.common.exceptions.WebDriverException: Message: Can not connect to the Service /d/apache-airflow/dags/chromedriver.exe
what should I do to connect the service so the web scrapping can be done I run my airflow test bench in ubuntu wsl so if there is any solution please provide it to get its work done in airflow
or if there are other ways to scrape in airflow do suggest.
Can not connect to the Service /d/apache-airflow/dags/chromedriver.exe
I don't have this set up to test with Airflow to be sure, but I have successfully run Chrome with Selenium under WSL2.
It sounds like you might be following some old instructions that were applicable for WSL1. Under WSL1, my understanding is that it is possible to use the Windows Chrome executable/webdriver.
You might want to try switching to WSL1, but I don't know for sure that Airflow will run there. It's very likely that it will.
However, if you do need to use WSL2, you'll have to use the Linux binaries.
This means that you'll need to install Google Chrome inside the WSL distribution and use the corresponding chromedriver_linux64.zip.
You'll also need to either ...
... be running WSL with the ability to run graphical applications - If you have Windows 11, this is automatic. If not, I recommend Xrdp as the next easiest path.
... or run Chrome in headless mode. I'm not sure off the top of my head how to do this with Airflow, unfortunately.
Can I get a tip for installing on rasp buster? Im hung up on the install directions to check the status of the rabbitMQ server. Traceback of bash console:
(volttron) pi#raspberry:~/Desktop/volttron $ echo 'export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7'|sudo tee --append ~/.bashrc
export RABBITMQ_HOME=$HOME/rabbitmq_server/rabbitmq_server-3.7.7
(volttron) pi#raspberry:~/Desktop/volttron $ source ~/.bashrc
pi#raspberry:~/Desktop/volttron $ RABBITMQ_HOME/sbin/rabbitmqctl status
bash: RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory
There are a few tracebacks earlier on the installation...
If it makes a difference or not here is the entire bash console process. The git gist link I just created the name install.py even though its just bash commands copied pasted per install directions...
`pi#raspberry:~/Desktop $ git clone https://github.com/VOLTTRON/volttron --branch releases/7.x`
It looks like there are a couple of different issues going on here:
The issue you quote above (RABBITMQ_HOME/sbin/rabbitmqctl: No such file or directory) is that your shell isn't finding the rabbitmqctl command. It looks like you added the RABBITMQ_HOME environment variable to your .bashrc, but used the string RABBITMQ_HOME instead of the variable expansion $RABBITMQ_HOME when you tried to run the command. Try running it as $RABBITMQ_HOME/sbin/rabbitmqctl status instead.
The rabbitmqctl status command will check the status of the rabbitmq application, but I don't think you've done anything to start it yet (that happens when you bootstrap the platform and/or start the platform configured to use the RMQ broker)
I think that the traces earlier in the installation process are problematic (appears to be the same error hit two different ways), but you just haven't run into them yet. I haven't seen any issues building gevent on the RPi 4 with buster (though it is pretty slow), but the ctypes error makes me wonder if there's an issue with the underlying c library it is trying to build on top of. I did notice that you're getting amd64 erlang packages, are you running Raspbian on an x86 processor? (if so this isn't a permutation we've tried and you may be hitting some package compatibility edge case we haven't seen)
One thing to try is to manually install cython into your virtualenvironment and then try running the bootstrap script again with the virtualenvironment activated. You could also try and pip install gevent==20.6.1 directly in that virtualenvironment (this is what the bootstrap script was doing at the failure point). VOLTTRON depends on gevent, so if that isn't installing the platform won't be able to run.
I've set up an App Engine project locally using Docker (on OSX), and have been running a server using the usual "gcloud preview app run app.yaml" command. From what I can tell, this keeps creating new images over and over again. After an hour or so of work I end up with something like 30 docker images, each taking 130MB.
Eventually I'm told I can no longer bind to localhost:8080. I tried killing all containers and images, but still cannot use localhost:8080 until I reboot.
Seems like I'm not using Docker/gcloud correctly. Anyone have an idea what I might be doing wrong? Is there another way I should be restarting App Engine instances other than hitting command C and running the "run" command again?
UPDATE: After looking closer, I noticed I'm getting this message when I run an app locally and a container is created: "http: Hijack is incompatible with use of CloseNotifier". I'm not familiar enough with Docker to understand what's going on here. All searches seem to point to Go, which I am not using.
UPDATE 2: Here is the trace:
Creating container...
INFO 2015-05-05 02:23:28,293 containers.py:560] Container 1564ce4344957114312d6d1dc696ffbb4176b40ace6dcff5e4239e13ee04a8f6 created.
Exception in thread Thread-2:
Traceback (most recent call last):
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 810, in __bootstrap_inner
self.run()
File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/Users/judeosborn/google-cloud-sdk/platform/google_appengine/google/appengine/tools/docker/containers.py", line 643, in _ListenToLogs
for line in log_lines:
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 225, in _multiplexed_response_stream_helper
socket = self._get_raw_response_socket(response)
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 167, in _get_raw_response_socket
self._raise_for_status(response)
File "/Users/judeosborn/google-cloud-sdk/./lib/docker/docker/client.py", line 119, in _raise_for_status
raise errors.APIError(e, response, explanation=explanation)
APIError: 500 Server Error: Internal Server Error ("http: Hijack is incompatible with use of CloseNotifier")
INFO 2015-05-05 02:23:28,606 module.py:1745] New instance for module "default" serving on:
http://localhost:8080
There's an ongoing issue with Docker 1.6.x [reference] that prevents gcloud to work well with Managed VMs (as you seem to be using). Easiest workaround until it gets fixed is to downgrade Docker in your development machine to version 1.5.0, which is the latest version known to work.
For Ubuntu, you can do something like:
$ curl -sSL https://get.docker.com/ubuntu | sed 's/lxc-docker/lxc-docker-1.5.0/' | sudo sh
For other Linux distros, you might have to modify that sed pattern, though.
On the other hand, if you're using Boot2Docker under Mac OS X, follow these steps:
Fully uninstall your previous Boot2Docker/Docker setup; there is a nice guide here
Reinstall Boot2Docker/Docker following instructions here. IMPORTANT: You MUST stop right after completing "Install Boot2Docker" step and before "Start the Boot2Docker Application". Once you get there, open up a terminal and execute the following commands:
$ mkdir ~/.boot2docker
$ echo 'ISOURL="https://github.com/boot2docker/boot2docker/releases/download/v1.5.0/boot2docker.iso"' > ~/.boot2docker/profile
At this point, you can continue with "Start the Boot2Docker Application" section and finish the installation. You should now have a valid Docker launchpad with which to start Managed VMs. It'd be nice to double check that you have the right versions installed by issuing:
$ boot2docker ssh docker version | egrep "(Client|Server) version"
The output should look like:
Client version: 1.5.0
Server version: 1.5.0
Now you can try again your original command:
$ gcloud preview app run app.yaml
Try running:
$ ps uax | egrep "gcloud|appserver"
If you see anything running, kill it... you may even need to kill -9 it.
I am trying to run pyramid application on google's app engine using buildout. I followed this link gae_buildout and got struck while running the buildout. Its shows "setuptools not found error" despite of seetuptools being installed in the virtual environment. I tried few work arounds and nothing turned fruitful, any thoughts on this ?
Find the error trace below. I am using pyramid 1.4 version.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1942, in main
getattr(buildout, command)(args)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 622, in install
installed_files = self[part]._call(recipe.install)
File "c:\myenv\newproject\eggs\zc.buildout-2.2.1-py2.7.egg\zc\buildout\buildou
t.py", line 1366, in _call
return f()
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 377, in install
self.copy_packages(ws, temp_dir)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 284, in copy_packages
self.write_pkg_resources(ws, lib)
File "c:\myenv\newproject\eggs\rod.recipe.appengine-2.0.2-py2.7.egg\rod\recipe
\appengine\__init__.py", line 267, in write_pkg_resources
assert len(setuptools_eggs) == 1, "setuptools not found"
AssertionError: setuptools not found
Got the same (Ubuntu 12.04) and finally solved the problem by changing ae-sdk-version to 1.8.0 from buildout.cfg
Open buildout.cfg and change the line:
ae-sdk-version=1.7.5
to:
ae-sdk-version=1.8.0
...or the latest one from here. Now seems to be 1.8.5, but 1.8.0 worked for me.
The problem in fact comes because PyPI is not serving last version of pyramid_appengine. It's serving 0.8.1 and should be (latest) 0.8.2-a2. You can download and install in your virtualenv the latest version in a tarball from here: https://pypi.python.org/pypi/pyramid_appengine/
So here's another solution.
It seems that rod.recipe.appengine doesn't work with the setuptools versions of the system, and it doesn't download the last version in that buildout. So the solution is to force to download a newer version of setuptools that rod.recipe.appengine likes.
Edit the versions.cfg file (should appear just the [versions] tag) and add the following line:
[versions]
setuptools = 1.1.7
(other older versions work as well, I tested successfully with 0.9.8)
And now seems to work easier without needing the mentioned patches (thanks Tom) that are harder to update.
This happened to me as well.
I started looking at the code and noticed it was explicitly looking for an egg install of setuptools, and none of the places I had installations of it were eggs for some reason.
I decided I'd go delete them from my site-packages and re-run the tools to download them, and after only killing the copy in my virtual env, and re-running the bootstrap and buildout, it got the egg and everything started working fine.