Skip to main content

Thought 59: House of Cloud Pi: Part 3

Continuing on the House of Cload Pi.

This though is about the software and how to get it setup and going at least for getting things staged

YOCTO

Being familair with Yocto from other projects, this seems like a good place to start. It means dropping the ease of Raspbian Lite, but adds the customization and flexibility we are going to need to make this work. So, first Task is to get a basic image for a pi3 or pi zero w and then we can work from there. We will be following this toturial to get started at getting a basic setup for a PI. We should be able to add recipes and modify from there. Yocto can also be configured to create cross platform SDK's which will be useful in early development.

SWUpdate

After getting a basic image down we should attempt to get some level of updating system in place for the pi in the field. We are not going to be able to simple remove/replace and SDCard easily if there is a pi stuck some where in a wall or too high, so having a method of updating would be good. We can follow this example and hopefully not run into any snags with the setup. Once here we should be able to start building out new recipes. Ideally setup with a A, B image and leave more space available for dataspace, as we will be storing metrics and camera data or joining all of the data section as a clustered drive.

B.A.T.M.A.N.

This should be down in two stages, the first is as raspbian to get an idea on how well it will work for the needs. First follow a toturialrecipe. Then see if there is a recipe for yocto out of the box or not, if not we will need to create one. Set this up and hopefully get to the point where we can take a blank pi drop in a sd card with the image and have it join the mesh network, this will be a big giant step to make things work correctly. Likely we will need to create a few images here, one for the gateway and multiples for the end points like a pi zero w and pi 3 and pi 4, etc so we can drop and go with a network.

Base Software

If we get through have a drop in mesh network and upgradable image, we can now start down the path of adding software to networks.

    Base Software
  • GCC - Everything needs GCC
  • OpenCV, GPIOD, IIO, etc. - Libraries for interfacing with all of the hardware.
  • Node Red - A flow controll system.
  • Influx - For storing time series values.
  • Grafana - For viewing data on the devices.
  • Nanite - Personal flow library
  • Other, not entirely sure what all we will need to make this work, but we can figure it out and add it all to the receipes.

Distributed Software

With a base setup going, it will be time to start harnessing the power of having all of these networked devices. So let's look at some packages that might be useful here.

    Distrubuted Software
  • IceCC - aka ice cream, a distributed GCC
  • Haddop - For both hfs experiment and of course map/reduce.
  • OpenMPI - Not sure how well this will work, but worth given it a shot.
  • Tensor Flow - For machine learning in parrallel
  • Gluster - Clustered disk space. Does not have to be Gluster, just an example.
  • HTCondour - Or some other type of bath based interface.
  • HiveQT - For distributed data collection, although more likely this will be a bunch of mosquitto's
  • Other - Can try things like kafka, cassandra, etc, and build those onto the cluster.

Overall not sure how many of these will handle a system that will be continously growing and could have some nodes that disappear altogher so likely need something to manage it all. Of course docker/k8y comes to mind, we will have to see how well that'll work on the pi zero w's which look like they are going to be a majority of the House of Cloud PI, as they fit just about anywhere.

Other Software

Going to need a gateway with some level of monitoring software on it along with a something like Home Assistant to cover the HA part, will need to run BATMAN-ctrl to view the mesh. Some of the tools will need be bumped up to a web front end. I also feel like the gateway should have a monitor on it, but not a requiement at this point.

Starting to look like this useless thought is starting to form into a not-so-useless thought.

Comments

Popular posts from this blog

Thought 44: Phone Home

This is actually two thoughts in one, but they are both phone related. Thought 44.1: The backside keyboard. We created the typewriters since 1829 and they've use all of our fingers in an effort to create efficiency. We have even created varieties of key layouts such as qwerty and Dvorak to improve the typing speed. Then we took a huge step backwards and created the cell phone with only the 12 buttons for typing, reducing not only the number of keys by the number of fingers usable on those keys. Then we made the thought that if we just replicate the full qwerty things would be better. And to some extend they are, but we still are reduced to just 2 fingers, or rather thumbs to type with. Then it struck me, the full key set could go on the back of the phone. Well at first it seems rather stupid how do you see the keys to type on them, but does/should a touch typist ever look at the typewriter or keyboard? No. The buttons on the back could be a full qwerty keyboard split and r...

Thought 16 - Kid Power

In response "Thought 14 - Perpetual Cat" sugarbumkin said, "The same theory could be applied to balloons tied to kindergarteners at recess. I like it." Well this got me thinking... Clothes with that are laced with MEMS generators. A MEMS generator is a solid state electronic circuit that generates low level of current though passive motion of the environment. Things like temperature change, acceleration, and even Brownian motion are converted to power using a MEMS generator. So, now we have attached them to small free moving bipeds of pure energy. How do we get the energy back. I figure that we isolate the playground into a large battery configuration where the children are running around on a conductive plate that makes contact with the heels of their shoes. They will run around with a super capacitor in addition to the MEMS, when their feet touch the ground the super-cap is discharged into the conductive plate underneath them. I do not think that the childr...

Thought 1 - Future Bike Helmet

Now that I have a motorcycle, I realize the potential future possibilities of the helmet. Wherein the helmet can become more than just mere protection, but a useful interface and aid to the rider. The concept stems from three currently available, but edgy technologies: transparent displays, blue tooth, and EEG recording. Technology 1: Transparent Displays Transparent displays are just now being put into high end cars and modern aircraft to create a dashboard on the windshield allows the driver or pilot to view the instruments, like speedometer, radar, engine problems, etc. This is typically done with a projected display onto a special film on the window. It can also be performed by simply building the LCD into the screen. The built in is not done because it is more costly in terms of construction of the display and a crack or chip in the display becomes an LCD ink blot. The projector could potentially be built into the visor of a motor cycle helmet, especial now that mini projec...