OpenSolo Dependencies

Joined
Aug 23, 2017
Messages
53
Reaction score
11
Age
57
Location
Vancouver, WA
Good Afternoon,

I've attempted to bring up the Vagrant VM multiple times and it just hangs forever. If anyone has successfully built the code, would you the be kind enough to post which
versions of the build tools you used?

I have had vagrant/Git/VirtualBox and VMs on this box for over a year and haven't had these issues before and the wiki makes no mention of version dependencies.

I'm currently running a Windows7 64-bit host, Vagrant 2.0.0, VirtualBox 5.1.26 with Ubuntu 16.04.

I suspect I need to downgrade vagrant to 1.97 and Ubuntu to 14.04, but I have other software that depends on 16.04, so that presents a dilemma. But I guess that's a personal
problem.


Thanks
 
Hello Carpy.

As I suspected... Guess I shouldn't have upgraded...

Thanks for the info... Should be able to get it built.
 
  • Like
Reactions: carpy
Old thread, but seems the best place to post this info.

I was able to build the latest OpenSolo on my new install of Windows10, VirtualBox5.2.2, Vagrant 2.0.1, but I had to make a few tweaks to the install-vagrant-deps.sh file to get it to compile completely.

In the install-vagrant-deps.sh script, after:

Code:
# fix broken  urllib3 or some ssl stuff doesn't work
sudo apt-get install -y --force-yes python-pip
sudo pip install urllib3[secure]

I inserted:

Code:
# fix missing python tools and ssl crypto stuff  t.c. 12 12 2017
sudo pip install --upgrade setuptools
sudo apt-get install -y --force-yes libffi-dev
sudo apt-get install -y --force-yes libssl-dev
sudo apt-get install -y --force-yes phablet-tools
repo init
sudo apt-get install -y --force-yes texinfo
sudo apt-get install -y --force-yes chrpath
sudo apt-get --assume-yes update

I then ran:
vagrant up
vagrant ssh -- -X
/vagrant/builder.sh (twice - it needed an update)

and it complied in about 3 hours with two SSL errors and failed.

Reading the error message told me it was an SSL error because two of the bitbake files were using http instead of https

I then edited the two bitbake files that were set to http instead of https:

Code:
#Edit /home/vagrant/sources/meta-3dr/recipes-devtools/python$/python-posix-ipc_0.9.9.bb
SRC_URI = "https://pypi.python.org/packages/source/p/${SRCNAME}/${SRCNAME}-${PV}.tar.gz"

Code:
#EDIT /home/vagrant/sources/meta-3dr/recipes-devtools/python/python-enum34_1.1.3.bb
SRC_URI = "https://pypi.python.org/packages/source/e/${SRCNAME}/${SRCNAME}-${PV}.tar.gz"

And it compiled without any errors.

Of course I have no plans to load this on one of my Solos just yet....not until I come up with a few spare Pixhawk2's and Artoo's that I won't mind bricking.
 
Last edited:
Yes, I'll fork/clone/branch it this weekend then repair the scripts and test so they work on the 1st pass.

Once I verify that fixing it on Ubuntu doesn't break it on other platforms I'll submit the changes to the OpenSolo master.

The changes to the install-vagrant-deps.sh are "band-aids" to prove it will build and should not be needed if the dependancies/libraries are fixed elsewhere.
 
Last edited:
Hey guys. The builder is definitely in need of some TLC. I struggled a lot getting things to work to build the open solo beta releases. Buzz is back in the game and we're going to try to get it to a state of reliable working order. Things like this that you find will help a LOT.
 
  • Like
Reactions: Wetstone
A quick look tells me all that should be needed is edits to the playbook.yml and updating the two mentioned bitbake's so they reference https.


The playbook.yml is using the now defunct sudo: true
and needs to be changed to become: true in a few places.

That will fix it so install-vagrant-deps.sh won't need any changes.

-Tim
 
Last edited:
OK, so it looks like the github.com/OpenSolo/ code was cleaned up over the weekend and it now compiles again without any changes and without any errors.

The MD5's I'm seeing are:
Code:
7379f63ec11ced8171d84b421baac447  3dr-solo.tar.gz
d9a7acfdb10ea07a8e7634fb4069a41b  3dr-controller.tar.gz

but I don't see anything to compare these to in order to verify it is indeed compiling correctly.
 
Yep. I spent most of Sunday and Monday taking all my changes and organizing them into nice clean commits, then merging them into master. Then blowing it up with some merge conflicts. Then redoing them again. Now it's all nice and pretty :) Buzz is working on the build system to get that a little more robust and flexible now. The vagrant issues are resolved. Now he's working on getting it so we can build based on git tags/commits or branches. And eliminating some unnecessary clutter. He pulled in my changes to the build script too so it has the error handling and option arguments I made.

As to the build you just completed... When did you execute it? As long as it was after 1900EST yesterday, you're good. That's when I force-pushed the last of the housekeeping to the sololink and shotmanager repos. I ran the build yesterday evening too, and it is the -RC4 beta I plan to test this evening after work if I have time. The question of "did it compile correctly", the only thing I can tell you is if it didn't, it would have bombed out with errors. So if you completed the build, it compiled.

Are you familiar with how to load those files onto the Solo and Controller?
 
...

Are you familiar with how to load those files onto the Solo and Controller?
Thanks for the updates to the github, all is good now and RC4 compiles fine.

And yes, I do know how to update the copter and artoo manually (a bit of a pita...)
It would be a nice option if Solex would allow us to pick/install our own update zips off of our phone/tablet SD card.

I was just thinking about that... I wonder if I could let Solex download the RC3 firmware, then manually replace the zips it downloaded in the "\Android\data\com.fognl.solex\files\download\package" folder with my own custom same named zips before reconnecting to the solo network and let it install...might work.

Update: seems to be more simple than I thought.
If I create my own custom update zip and place it in the Solex package folder, it shows up in Solex as a downloaded installable option.
 
Last edited:
  • Like
Reactions: fpvsteve
On the new and improved 3.0 release version, it says:

STOCK SOLO SPECIFIC UPDATES: The following applies only to stock solo Pixhawk cubes and does not apply to Green Cube solos.
Distance based battery failsafe:...
Improved landing detection:...
Low battery thrust priority:...
Smart shot altitude priority:...
No more 3DR:....

But don't all of these apply to Green Cubes too?

Or am I just reading this wrong..
 
On the new and improved 3.0 release version, it says:

STOCK SOLO SPECIFIC UPDATES: The following applies only to stock solo Pixhawk cubes and does not apply to Green Cube solos.
Distance based battery failsafe:...
Improved landing detection:...
Low battery thrust priority:...
Smart shot altitude priority:...
No more 3DR:....

But don't all of these apply to Green Cubes too?

Or am I just reading this wrong..
Those are features that 3DR put into their version of ArduCopter for the Site Scan commercial solos (the old 3DR 1.5.3 ArduCopter-Solo). That's what you're seeing there in Open Solo now. Those features do not exist in ArduCopter master, and as such are not available on the Green Cube.
 
  • Like
Reactions: DJMc
once you fly a green cube, those features will sound like the adults on Charlie brown.
mwah mu mwah
Good stuff for the stock cube, but unleashing the power of solo with a proper esc fix, man the beast in solo comes out
 

Members online

Forum statistics

Threads
13,093
Messages
147,741
Members
16,048
Latest member
ihatethatihavetomakeanacc