I am running Drake on Ubuntu 20.04 using WSL2.
I use python3.8.10 and Drake1.2.0.
I tried running the "Mathematical Program Tutorial" obtained from deepnote on my PC, but the behavior of the ipopt solver is unnatural and does not give the expected results.
The 1st error is occurred in the section using ipopt solver.
All components of the solution is printed as "nan"
The 2nd error is below about "get_solver_details().status"
RuntimeError: The solver_details has not been set yet.
I can see both errors in "Demo on manually choosing a solver" in the tutorial.
The result is following
SolutionResult.kUnknownError
x* = [nan nan]
Solver is IPOPT
---------------------------------------------------------------------------
RuntimeError Traceback (most recent call last)
<ipython-input-12-2d1b3835c54a> in <module>
25 print("x* = ", result.GetSolution(x))
26 print("Solver is ", result.get_solver_id().name())
---> 27 print("Ipopt solver status: ", result.get_solver_details().status,
28 ", meaning ", result.get_solver_details().ConvertStatusToString())
RuntimeError: The solver_details has not been set yet.
Thank you in advance.
P.S.
I installed pydrake for venv by pip commands
python3 -m venv env
env/bin/pip install --upgrade pip
env/bin/pip install drake
sudo apt-get install --no-install-recommends \
libpython3.8 libx11-6 libsm6 libxt6 libglib2.0-0
source env/bin/activate
I just download the folder "Tutorial" from deepnote and put it under env.
Then, I run it by Jupyter Notebook as
jupyter notebook
and open env/Tutorials/mathematical_program.ipynb
It turns out that the pip drake == 1.2.0 version has a bug in the IpoptSolver compilation.
As a work-around, you can use SnoptSolver instead, or else use the https://drake.mit.edu/from_binary.html release (unpacking a zipped binary, instead of using pip).
It's possible that the pydrake.solvers.ipopt.IpoptSolver class (which is a wrapper around the https://coin-or.github.io/Ipopt/ library) does not run correctly under WSL2, due to using some odd libc API which doesn't work on Windows. We will need more information to reproduce the problem and try to debug.
Can you state exactly how you installed pydrake (i.e., show us the command lines you used). Was it via pip (https://drake.mit.edu/pip.html) or just via binary (https://drake.mit.edu/from_binary.html)?
Can you state exactly how you ran Jupyter (the command line) to launch the notebook? Was it python3 -m pydrake.tutorials or something else?
Looks like this may not be tied to WSL, but instead pip build (or just binary build). Ran into this on Ubuntu 20.04 (no WSL). Per Drake Slack, filed issue:
https://github.com/RobotLocomotion/drake/issues/17162
Related
Environment: Docker Image based on nvidia/cuda:11.1-cudnn8-devel-ubuntu20.04, python3.8, numpy==1.19.4, opencv=3.4.3.
Error: terminate called after throwing an instance of 'std::runtime_error' what() numpy failed to initialize, RuntimeError: module compiled against API version 0xe but this version of numpy is 0xd
This solution helped:
pip3 install --upgrade numpy
(Successfully installed numpy-1.23.0)
Description:
The python3 application runs successfully with the specified initial version of numpy on a host ubuntu20.04.4.
However, when run in docker based on the same Ubuntu release, it stops at the indicated error.
The solution is found, in the indicated form. However, the essence of the question why this difference in the numpy versions on the host and inside the docker container has a place, is so remains unclear.
Question:
Why this difference in numpy versions on the host (1.19.4) and inside the docker container (1.23.0) has a place, if all the rest of the environment looks identical.
Pycuda is a package that compiles; when it compiles, it uses numpy's libraries.
Next solution, allowed me to use required version of numpy:
pip3 uninstall pycuda -y
pip3 install --upgrade numpy==1.19.4
pip3 install pycuda==2019.1
The background is, I'm responsible for maintaining a fancy Docker image that is used by our team for analytics. It uses a Jupyter notebook image as the base, and then adds various customisations, extra packages, etc.
One of the team members recently wanted to run Tensorflow. No problem, I'll just run mamba install and add it to the image. However, this created an issue: Tensorflow 2.4.3 (the latest version) is somehow incompatible with R 4.1.1 (also the latest version) or something else in the ecosystem, causing R to to be downgraded to 3.6.3. So I created a new environment and installed TF into that:
FROM hongooi/jupytermodelrisk:1.0.0
RUN mamba create -n tensorflow --clone base
# Make RUN commands use the new environment
RUN echo "conda activate tensorflow" >> ~/.bashrc
SHELL ["/bin/bash", "--login", "-c"]
RUN mamba install -y 'tensorflow=2.4.3'
But when I rebuilt the image, I found that while the tensorflow env had been created, the Tensorflow package had been installed into the base env, not the tensorflow env. Has anyone else encountered this? I can verify, if I login to the container, that the tensorflow env has been created: it just doesn't contain the Tensorflow package.
I don't get this problem if run the create, activate and install commands from inside the container. It's only when I try to do it in the Dockerfile.
I use mamba instead of conda because the latter takes forever to run, given the number of packages installed. In fact, trying to run conda install tensorflow crashes after ~5 hours.
Not an expert on dockerfiles, but in general you could just use the -n flag to the install command to specify the target environment for the installation like so:
mamba install -n tensorflow -y tensorflow=2.4.3
Background: I am new to the Python world and am using Plotly for creating basic graphs in Python. I am using AWS Sagemaker's JupyterLab for creating the python scripts.
Issue: I have been trying to run the basic codes mentioned on Plotly's website however even those are returning blank graphs.
Issue Resolution Tried by myself:
pip installed plotly version 4.6.0
Steps mentioned on https://plotly.com/python/getting-started/ for JupyterLab support have already been executed
Code Example:
import plotly.graph_objects as go
fig = go.Figure(data=go.Bar(y=[2, 3, 1]))
fig.show()
I recently had the same issue. Simple change suggested here helped me. I know this is a temporary workaround until a proper fix is found.
// fig = go.Figure()
fig = go.FigureWidget() // replace with this
// fig.show()
fig // remove .show()
Sagemaker notebook instances are using (As of Jan 2022), for some reason, jupyterlab==1.2.21. You can verify that by running pip freeze | grep lab from the terminal or !pip freeze | grep lab from a notebook.
According to the documentation, you'll need to install the following jupyterlab extensions (which are not needed if sagemaker was running jupyterlab 3):
jupyterlab-plotly
jupyter-widgets/jupyterlab-manager
You can install those on a up-and-running instance by running
jupyter labextension install jupyterlab-plotly#5.5.0 #jupyter-widgets/jupyterlab-manager in the terminal or notebook (using ! if you are running on the notebook ofcourse). Notice that the jupyterlab-plotly extension version (here 5.5.0) should match the plotly version you are installing. Mismatches my cause issues. In this case by plotly version is 5.5.0 and thus that's also the jupyterlab-plotly version I've installed.
If you need, like I did, to have it ready upon spinning up a notebook instance, you'll need to:
Create a lifecycle script
To it, add:
PATH=$PATH:/home/ec2-user/anaconda3/envs/JupyterSystemEnv/bin - To ensure nodejs path which is needed for the extension installation
pip install plotly==5.5.0 - To ensure a specific version
jupyter labextension install jupyterlab-plotly#5.5.0 #jupyter-widgets/jupyterlab-manager - To ensure same version
of coures, you can change the version according to the most up to date.
I think that documentation is not on par. You now need to install jupyterlab-plotly extension.
jupyter labextension install jupyterlab-plotly
UPDATE
I followed a mix of instructions here and here.
First Enable Extention manager from jupyter-lab
then from terminal
conda install -c conda-forge "nbformat" "ipywidgets>=7.5" -y
jupyter labextension install jupyterlab-plotly
jupyter labextension install #jupyter-widgets/jupyterlab-manager plotlywidget
And within your environment
conda install nbformat
Installation on Pi zero.
The installation was successful, but when I tried sample code
googlesamples-assistant-hotword --project_id my-dev-project --device_model_id my-model
It returns Illegal Instruction.
The pushtotalk sample didn't work neither.
Appreciate the help.
I finally got the assistant to work on Pi 0 with pushtotalk sample by installing python -m pip install --upgrade --no-binary :all: grpcio before the SDK installation.
However, the assistant will either take forever to give me NO response or not able to finish the response, in either situation, I'll have to close the terminal to end the session. I've opened an issue in github, and it seems like an incompatibility error in the gRPC package. https://github.com/googlesamples/assistant-sdk-python/issues/267
The hotword sample uses the Google Assistant Library, which is not available on the Raspberry Pi Zero.
try run again
python -m pip install --upgrade google-assistant-library
python -m pip install --upgrade google-assistant-sdk[samples]
Been having the same problem with raspberry pi 1. Only solution I could find so far is to use the pushtotalk and have echo automatically input newline using this.
googlesamples-assistant-pushtotalk --project-id gassist-d4d83 --device-model-id gassist-d4d83-rpi-meicej|echo -n
That does the job for me. Don't know if it helps anyone.
Edit: Only part that's bad is, it's always listening. Maybe I can modify the code.
the skeleton code of what I do is
from IPython import parallel
.....
rcAll = parallel.Client()
all_engines = rcAll[:]
lbvAll = rcAll.load_balanced_view()
....
for anInpt in allInpt:
lbvAll.apply(mputil.doAll, anInpt)
lbvAll.wait()
lbvAll.get_result()
....
for ijk in range(len(list(lbvAll.results.values()))):
out = list(lbvAll.results.values())[ijk]
ionS = out[0]
However, all that out ever contains is import error messages.
This worked before but but something must have changed between IPython 2.1 and 2.2. At least, that is my guess.
Check the output of:
cat /usr/local/lib/python2.7/dist-packages/*.pth
Delete the following path if it exits inside the "catted" folder:
/usr/lib/python2.7/dist-packages
usr/lib/python2.7/dist-packages being on the front of sys.path means that there is an easy-install.pth file with this path, which should be removed. It is caused by a bug in setuptools.
If that doesn't work, simply upgrading some of your tools might fix the problem.
pip install --upgrade ipython
pip install --upgrade setuptools pip
I found the problem. I started the ipcluster in a shell with a different PYTHONPATH than the one I was running the notebook in. That simple but I took a while. I apologize for the noise.