Archive for the ‘Engineering’ Category

Tuesday, August 4th, 2020

One of the projects I ponder from time to time is making a 3D printer big enough to print a house. I’m really curious whether it would be possible to take this technology further than it’s already been taken – in particular I’m interested about the possibility of having the printer I electrodeposit or just plain insert rebar at appropriate places, and I’m also curious, how cheap could you make such a beast?

Obviously it’s going to have some expensive parts – a high pressure concrete pump – but mostly it’s just some ropes, some big gear motors, and some sort of scaffolding to hang the whole thing off of.

Another project I have joked about many times – the ConeDrone, a series of remote controlled cars to move around traffic cones so we don’t spend a hour before every construction project shutting down the road and another hour bringing it back online – involves precision locating via RF, which would also figure largely in a 3D printer big enough to print a house.

I should probably start out by making a *small* 3D printer just to get a sense of the problems involved. It looks easy enough, but I suspect like so many things of that nature, the devil is in the details.

I do also sometimes ponder subtractive 3D printing i.e. CNC – watching the amazing work on the Marble Machine 2.0 has made me really appriciate how far this technology has come, and I may get some subtractive 3D gear for the solar tracker project.

Solar adventures

Monday, August 3rd, 2020

So, earlier in the year, when COVID was just starting to ramp up and also when coincidentally I was in the midst of about as manic as I let myself get these days, I – in perhaps a moment of unreasonable paranoia – decided I wanted a backup generator. Except, I wanted a backup generator that would actually be useful if social unrest or other issues resulted in gasoline being difficult to get. (Not that many gas stations have backup generators, so even just a city-wide blackout could the cause this, and we’ve certainly had our share of blackouts since moving to this house, including one !5-day! outage)

So, I did what seemed the most reasonable thing to me at the time, which was buy a bunch of solar panels, some lead acid batteries, and a couple of big inverters.

It has been working pretty well – my basement’s been running off it since March, I think, and I haven’t run out of power yet – however, at the moment the panels are just lying in the front yard. If my math is correct, this is only giving me 30% of the power i’d get if they were on a two axis tracker.

So, I’ve been slowly working through various designs to try to figure out how I want to do tracking with them. I’d like to do something cheap-ish and DIY, and I’m fine with the east/west axis being manual but I want the RA axis to be automatic. I was pondering something like a drawbridge with a winch, but lately I’m again favoring the idea of using a couple of large bearings (I like the idea of using wheel bearings and wheel hubs from a car for some reason) and a gear motor. But it may change designs again. I’ve been suffering from a certain extent of laziness surrounding it. Some of my problem is that I am not really that great at using 3D modelling software – I really need to sit down and learn, but I’m not really sure which software I want to use. I am increasingly thinking I need to buy a desktop application for this as I tried using several different web based solutions and all of them had serious performance issues. I do not think 3D modelling is really something that’s well suited to being a web app, especially in the post-flash world. Of course, maybe part of the problem is just my lack of 3D modelling skill..

Anyway, winter is coming, so I should probably put a little more effort into this. It’s easy to generate enough power to run your basement in the summer in Seattle.. we have very long sunny days. The winter, with it’s very short, cloudy days, is likely to be a good deal more challenging.

One thing that is very sasisfying about having thrown together a solar array – beyond that it worked on the first try and I was able to easily set up a raspberry pi to track energy in and out of various things – is that I can use it to charge my EV. Whatever wars we get up to over oil are therefore that much less my fault. It’s possibly the most effective protest of the US war machine I’ve ever come up with.

IOT problems

Sunday, August 2nd, 2020

So, one problem that we in general have with computers is that they are constantly in a state of growth and therefore it tends to be difficult to read files written 20 or 30 years ago because we don’t have anything remaining that can either handle the physical or logical format. (This makes me wonder if anyone has made something like the 7 layer model for data storage)

Anyway, one upcoming problem is that we lately are doing a lot of IOT devices – and a whole lot of these are going to be in landfills in ten years. The basic problem is that the people coding for them have fallen in love with the latest moronic fad, which is to have a ‘app’ to set up everything.

We need to have a *universal* configuration language that runs over bluetooth – someone should have a working group together. Or, we could just stream HTML over bluetooth – hm, that seems like a really good idea now that I mention it. Anyway, I also am pondering if most devices should just use bluetooth to negotiate the initial internet connection and then be configured via a web page. That seems like it might be best.

What isn’t best, what is in fact awful, is to have custom code, a dedicated app, for each device to be configured. Some of the obvious problems with this:

1) It requires the user to have a device that the app will run on. In 20 years there may be no android or IOS devices left because someone may have written a much better operating system

2) There’s also some version issues. As per usual the developers don’t write things to run on all versions, and it’s very likely that future versions will also be incompatible

3) This requires the developers of the hardware to continue releasing software – in some cases the developers may not even exist, and even if they do exist capitalism says it won’t be profitable to continue to support devices that are even a few years old so I doubt if we’re going to continue to see new versions of configuration tools

So, here’s what I think tehy should be doing

#1: We need a standard communication protocol for bluetooth for configuring all devices that are configured via bluetooth or BLE. Bluetooth working group, I’m looking at you. If you can charge $8000 per device for people to have your logo, you can do less of a halfass job at telling them not to make devices that won’t be configurable in a few years because the apps will no longer be maintained

#2: We need to have a agreement that whenever possible we’re going to use a standard web browser to configure devices. You can still make custom apps that do it as well, but you should document the API and have a plain ol’ javascript version of it so those of us who don’t want to deal with your apps can still use our devices

#3: Whenever possible you should make it so that your device can be maintained locally without your cloud service. Ideal ways to do this include docker and kubernetes containers that run your service that the customer can install on their local hardware, open source descriptions of your protocols, etc.

#4: You should publish schematics, source code, and whatnot for your products – both allowing users to change the basic functionality and publish new and better versions of the firmware, and allowing them to look for security holes and design flaws. In a lot of cases, IOT devices can cause a lot of damage – you all need to be building equipment we can trust.

I’m currently in the process of working on firmware for a IOT device, and it has really made me think about how poor a job humans are doing on IOT in general right now.

Another thing I’d like to mention, and this in particular is aimed at ORbit’s B-Hyve. Whenever possible, *DO NOT* waste the user’s time. If you do not *need* to upgrade the firmware to be able to continue, *don’t*. If you must upgrade the firmware, try to do it over the internet rather than BLE – at the very least, kick into bluetooth classic in order to be able to get halfway decent amounts of bandwidth.

(B-Hyve is in many, many ways a example of how not to, when it comes to IOT devices. It’s a great idea, and the hardware is well done, but the software is *awful* in a very long list of ways)