Having read a bit more about WebControl, I realize how foolish I was being in thinking I would need to connect a monitor to the rPi. I could have any computer show a display in a browser! Thanks for putting this together. I am looking forward to implementing it at some point.
Correct. In fact, I recommend keeping it entirely headless (no gui). webcontrol sometimes needs as much processing power as it can get.
There is something called Docker toolbox that you can setup inside an Oracle VirtualBox. But thats getting into the weeds, IMHO.
Let’s see if we can compile it into an exe
Please bear with me for being a noob with rPi… If I don’t set up ssh but use a monitor, keyboard, and ethernet cable connected to the rPi, will everything work the same as in the instructions?
I am thinking that since I have a router in my workshop, I’ll just run an ethernet cable to the rPi for normal use. Since I won’t need wifi, I was going to skip the ssh step and set everything up with connected peripherals.
I assume that once it is all set up (flashing the SD card with @johnboiles image, setting up WebMCP to run on boot) all I will need to do is plug the Maslow into one of the USB ports and turn everything on… then connect using a browser to port 5001 of the rPi.
I also assume that I can turn off the rPi when the Maslow is not in use, and the Maslow will reconnect when it is turned back on?
Yes, just don’t load a gui on it and you’ll be fine.
I don’t know what configuration (if any) you need to do to get an IP address on the ethernet port. @johnboiles? As long as you have an internet connection, @johnboiles sd image will download the necessary docker files and start everything up.
Yes… it should.
This works out of the box. It’s the easiest way to get started because you don’t need to do the wpa_supplicant.conf step to add your WiFi credentials. This is how I connect my Pi
Note that the first boot takes probably 10-15 mins because it’s actually downloading the latest WebMCP. The. You can access the pi on port 5001. If your system has Bonjour/mDNS installed you can go to http://maslowpi.local:5001 in your browser (this definitely works on iPhone, macOS, Linux with the avahi package — can one of you Windows people tell me if this works for you out of the box?)
First I want to apologize for not being able to help with the alpha after signing up for it. Life got in the way and is still going but now I’m beginning to see daylight.
I have obtained an Atomic Pi and would like to use it for the control of the Maslow. It’s got a bit more horsepower than the Raspberry Pi but is running an Intel Atom chipset. Anyone foresee any problems before I give it a go. It will be running Ubuntu 18.04.1 LTS.
I think you’ll have to download the source from github rather than use the docker (though @johnboiles can correct me about this) and build the requirements since the docker image is built for arm processor. Besides that, I think it’ll work.
Yeah the docker image won’t work in its current state since Intel Atom is x86 and it’s built for arm. But +1 to @madgrizzle’s comment: the source should run fine. The SD card image definitely won’t work because the whole OS on that image is compiled for arm.
If you want to investigate multi-architecture docker images, it’d be awesome to have both arm and x86 images available
Thanks. Guess I’ll try to start learning about Docker and what it will take to build Webcontrol for x86. From a cursory glance it looks like the source is all Python so no actual compiling of the source should be needed. Then I guess it’s just building all of the prerequisites into the image. I’ve done similar in VMWare but not Docker (yet)
I think you should be able to use the same dockerfile and just change the
FROM line at the top to an x86 image.
But to do this properly we need to look at how to distribute a manifest with multiple images, one for each architecture. Then we would build for every architecture we are interested in and docker will magically pick the right one depending on the architecture of the host machine you’re trying to run it on
Doesn’t look too hard maybe
I have been thinking about this. It make sense that, if we switch to WebControl, it is easiest if we don’t drag it out. I am wondering if we can make a coordinated decision about whether or not we wish to make WebControl the new default. If we decide that we want to go in that direction, we could try to coordinate the move, such that we minimize the need to maintain two versions of the software. I understand that this dual-version scenario is unavoidable. However, we can minimize the pain by being intentional and coordinated about it.
So, to facilitate that decision and coordination, here are a few questions. Of the new people who are just creating their Maslow, how many intend to use WebControl? If not, if you could respond that you intend to use GroundControl, that would be helpful. What is the basis for your decision? Below is a poll.
- Intend to use GroundControl
- Intend to use WebControl
From this, we could compile a communicated intent. It could be something like: “We intend to migrate development activities to WebControl. We will do a soft phase-out of GroundControl starting August 2019.” This is just an example.
Maybe you can edit your post and take a Poll? Im not sure how to do it, but the option is under the gear icon.
I think that WebControl should be considered a modification to the Maslow unless producers of the kit are intending to include hardware to run WebControl. As it stands now, someone ordering the kit can get up and running without having to purchase another electronic device.
Personally, I really like the idea of using WebControl (and I plan to implement it), but it does presuppose a lot of infrastructure that is not required of the Maslow as it currently stands. Not everyone has workshop access to wifi and/or ethernet, or a spare raspberry Pi lying around. WebControl also requires a bit more computer savvy to set up on the rPi than is required to set up the arduino (not a lot more, but more none-the-less). Unless the thinking is that WebControl will be made as easy to install on Mac and Windows as GC currently is now, and can run from that computer, which would make additional electronic hardware uneccesary.
I think that the idea of phasing out GC as it is currently implemented raises the bar for using the Maslow and should be considered very carefully. I imagine that there are still plenty of kits out there still waiting to be built, and may be in that state for quite a while yet (I am basing this off the amount of time it took before I was able to find time to get mine put together, and I was in a pretty early batch of originals). That said, I also realize that same argument could be used to promote going one way or another.
The main question I have in this rambling post is… Why is it necessary to choose one or the other?
Don’t take wrong way… I write this in all sincerity
I’m the only one that has done any development on webcontrol, it was a learning process (I don’t do this for a living), and there probably are smarter ways of doing what I did. With that said, I wouldn’t recommend this as the “official” version since I’m the only one that knows how the thing works… I don’t know we even need an official version, just provide this as an option for those that want a web-based interface.
And with that said, I like the poll because it gauges interest and if people are interested, then maybe others will start playing around with the code and making it better.
Oh, and the results of the poll will be biased due to where where it’s located. You’ll probably get very high positives on webcontrol since only people interested in web-based ground control will read this thread.
Maybe move the poll to a new thread by itself.
Another thing to consider is how new WebControl is. I would bet that there are a lot of people who don’t know anything about it and can’t make an informed decision about it.
I think I can speak for many when I say THANK YOU!
And I agree with this at the moment. I think that if there is a contingent of people who want to further develop what @madgrizzle has put together, then perhaps it can be rolled into an “official” version with continuing support, but for now I think that it is a nice option to have.
I think Ideally it would be great if WebControl could draw code from GC and be updated concurrently as one package, but that is probably too much to hope for.
That was one of @johnboiles suggestions to me when I was developing it and I really tried to do that. Unfortunately, Kivy is so integrated into ground control that it made it difficult. One of the biggest issue was the use of observer pattern that Kivy has baked in (where when you change a variable value, other variables can be automatically recalculated by it). My life would probably had been so much simpler if I had managed to figure out how to include an observer pattern. The other was that Kivy has its own settings structure and I was forced to roll my own. You’d be amazed how much time was spent just on syncing settings with the controller.
I still use some of the basic routines for the serial communications and logging process, but pretty much everything else has changed to some degree (you’ll see lots of the same code, but with little changes sprinkled here and there to make it work). However, I’ll say that if there’s an improvement made in ground control that is not UI-specific, then likely it won’t be hard to incorporate it into webcontrol.