Connecting to the internet using solo CLI

I just tried this using OpenSolo 2.5-RC2.
Look at the attached file which shows the commands I sent via solo-cli.
The second part of the file (after the +++++) is from an ssh session into Artoo before and after I ran the solo wifi command.

Connected to the Internet just fine.

Thanks. As I guessed it has nothing to do with the Solo fw installed.
Are you using Windows?
Which versions of python, virtualenv, pip do you have installed?
 
My laptop has Linux Mint 18.2. I installed python-pip via Synaptic then updated pip to 9.0.1 then installed setuptools via pip and virtualenv via pip. No idea what their versions are.
Sorry, I don't do Windows.
To get "solo info" to work with OpenSolo & Arducopter 3.5.3 I had to tweak the __init__.py in the solo-cli install. This is because the PIX_VERSION file for 3.5.3 has additional lines that are not properly parsed in the original. See my post in the Development area to get the __init__.py that I used.
 
  • Like
Reactions: Saijin_Naib
Interesting. My connection failed through my Win10 Python2 environment as well as my WSL environment. I wonder if I can connect from my rPi...

The init.py might also be the key here. Thanks for helping us out!

As an aside, have you "broken" through the virualenv? I want to get the Solo/Artoo python environment/runtimes/libraries fully up to date. I've had no luck with the Smart package manager getting the platform binaries updated, but that likely is due to an inability to connect.
 
Don't bother with "Smart" it is not very... and the packages were never kept up to date by 3DR.
Install OpenSolo, follow Matt's instructions. Fly Safe.
My only changes to __init__.py were to allow it to parse the additional lines in PIX_VERSION. If they change again I'll have to fix __init__.py.
 
  • Like
Reactions: Saijin_Naib
Don't bother with "Smart" it is not very... and the packages were never kept up to date by 3DR.
Install OpenSolo, follow Matt's instructions. Fly Safe.
My only changes to __init__.py were to allow it to parse the additional lines in PIX_VERSION. If they change again I'll have to fix __init__.py.
Have OpenSolo, I know the 3DR repository is static, I was toying with the idea of changing the package source list over to the upstream one to see if anything gets updated. I want to fly safe, but I do have a bug that kernel/binary/interpreter/library updates will improve performance of our Solos, especially where gstreamer and video encode performance is concerned. These updates (in my opinion) are not optional. However, I'm about as out of my depth as I can get, so this should be entertaining.
 
Good luck, Please post your adventures with updating any of the packages.
I hope to do some more kernel work over the winter, I've flown with 3.14.28 without issues, but I'd like to get something a little newer running.
 
  • Like
Reactions: Saijin_Naib
Good luck, Please post your adventures with updating any of the packages.
I hope to do some more kernel work over the winter, I've flown with 3.14.28 without issues, but I'd like to get something a little newer running.
Correct me if I'm wrong, but we should net faster boot times as well as lower CPU usage under load with the 4.x branch kernel, correct? And that kernel branch is required for gstreamer 1.x which is in turn required for hardware encode, right? I really feel like this line of updating could be a game-changer for us. The improved encode performance SHOULD give us lower latency on the video downlink, which I don't think would make anyone upset.
 
gstreamer1.0 will run on 3.14.28, but later versions will allow more features. The gstreamer-imx plugins are also very kernel dependant.
Gateworks does a lot of gstreamer work with iMx6 processors, that's where I go to see what is possible.
Yocto/gstreamer – Gateworks
as well as:
GitHub - Freescale/gstreamer-imx: GStreamer 1.0 plugins for i.MX platforms
Last year when I was first looking at 3.14.28 (before 3DR releases their kernel tree) I figured that 3.14.72 was a good candidate.
Later kernels 4+ have very different structures for their dts/dtb (device tree) and I'm not that good at device tree stuff. ;>))
 
  • Like
Reactions: Saijin_Naib
gstreamer1.0 will run on 3.14.28, but later versions will allow more features. The gstreamer-imx plugins are also very kernel dependant.
Gateworks does a lot of gstreamer work with iMx6 processors, that's where I go to see what is possible.
Yocto/gstreamer – Gateworks
as well as:
GitHub - Freescale/gstreamer-imx: GStreamer 1.0 plugins for i.MX platforms
Last year when I was first looking at 3.14.28 (before 3DR releases their kernel tree) I figured that 3.14.72 was a good candidate.
Later kernels 4+ have very different structures for their dts/dtb (device tree) and I'm not that good at device tree stuff. ;>))
I brick my raspberrypi on the regular screwing with the device tree overlays for my LCD panel, so I'm about worthless there. I'll take a poke at those links and see what I can learn.

Edit:
Compositing is possible with gstreamer 1.x.
That sounds like my dream/vision of the Artoo having the telemetry overlaid over the videofeed with a slightly translucent black background is possible, no?
 
Don't bother with "Smart" it is not very... and the packages were never kept up to date by 3DR.
Install OpenSolo, follow Matt's instructions. Fly Safe.
My only changes to __init__.py were to allow it to parse the additional lines in PIX_VERSION. If they change again I'll have to fix __init__.py.
I downloaded and installed your __init__.py in the Solo-cli on my PC. No success, Same problem with WiFi and Solo Info as before.
Do you need to install this file also in the respective artoo and solo directories?
 
No, it only goes on your PC. and the changes only effect parsing the PIX_VERSION file.
I wouldn't expect it to make any difference.
If you ssh into Artoo, what does ifconfig report? both before and after you run solo wifi .....
 
  • Like
Reactions: Saijin_Naib
On your text console try "solo wifi --name xyzzy" and see what pops out. (where xyzzy is NOT your local wifi access point)
I think you should get "connecting to the Controller..." Or something about access point not found. If not it's going to take some low level debugging, maybe having to do with the network on your PC. At this point I've no clue as to what's going on.
 
  • Like
Reactions: Saijin_Naib
I think we need to try and isolate the problem to the PC, Artoo, network, etc. So first let's see if solo-cli can talk to Artoo or Solo.
"solo info" will tell you that.
 
  • Like
Reactions: Saijin_Naib
ipconfig when connected to Solo wifi, before and after ssh-ing into Solo:
C22CF315-A2F2-4AA3-80A1-0712294891DF.jpeg

ssh with WinSCP works fine.
with Solo wifi I get the following trace dump regardless wether I enter the right or wrong home network credentials:
2DB8563F-F57D-457B-B1A1-DB44CD388EE4.jpeg

And for the record, I disabled also my firewall. Just in case.
Is there anyone who managed to use solo cli on Windows??
 
Ok, so from your windows machine, you can:
1) connect to the Artoo's network
2) ping 10.1.1.1 and 10.1.1.10
3) ssh as root to 10.1.1.10 and 10.1.1.1
Right?

If you can do that, try to run "solo info" from your windows box. Post the output.
Also ssh into 10.1.1.1 and post the output of ifconfig (ie run that command on Artoo not your PC). Then run the "solo wifi ....." command (on your PC) and post the output of ifconfig again.
 
  • Like
Reactions: Saijin_Naib
Ok, so from your windows machine, you can:
1) connect to the Artoo's network
2) ping 10.1.1.1 and 10.1.1.10
3) ssh as root to 10.1.1.10 and 10.1.1.1
Right?
yes confirmed.
If you can do that, try to run "solo info" from your windows box. Post the output.
here you go. I had to abort since solo info hangs.
D58FD164-1D6C-44AD-94CE-789B5088D078.jpeg

Also ssh into 10.1.1.1 and post the output of ifconfig (ie run that command on Artoo not your PC).
here you go:
1F290C94-A520-41F6-8850-416507C0C87A.jpeg
Then run the "solo wifi ....." command (on your PC) and post the output of ifconfig again.
There is no difference

C71A6431-91F8-4442-8FC0-67832467938F.jpeg

Thanks cynfab for looking into this! Much appreciated!
 
  • Like
Reactions: Saijin_Naib
The messages that you got after running solo info are the key to what is happening.
The first says: "connecting to Solo and the Controller..." This indicates that main in info.py started execution and got to the print statement.
The next one: "(note: ensure that you are connected to Solo's wifi network.)" means that the _connect method in __init__.py was executed and your PC is trying to connect to (first) the controller and (then) to Solo.
That message is a result of the first connection timing out after the default 5 seconds.
When I look at the messages that come out after you ^C from the hang, I see something very similar to what I see on my laptop when I run solo info without being connected to Artoo's network.
Solo_cli.png
However, my traceback has this:
File "/usr/local/lib/python2.7/dist-packages/soloutils/__init__.py", line 34, in _connect
client.connect(ip, username='root', password='TjSDBkAu', timeout=5)

after the comment about Line 57 whereas yours does not.
It looks like the client.py which is located in the paramiko library may be the issue.
The requirements.txt from solo-cli says paramiko needs to be 1.15.0 (or maybe later) mine is 1.16.0.
You might check what yours is.
 
Wow, that's a whole lot "newer" version than either I am using or that solo-cli was written for.
Just a quick comparison between the 2 client.py modules and they are very different.
As a first step I'd try uninstalling 2.3.1 and installing 1.15.0 or 1.16.0.
This may effect the operation of your PC so proceed with caution.
You might also review the versions of the remaining libs in requirements.txt
such as:
docopt>=0.6.0
paramiko>=1.15.0
scp>=0.10.0
requests>=2.5.0
 

New Posts

Members online

No members online now.

Forum statistics

Threads
13,095
Messages
147,750
Members
16,064
Latest member
dachl