Being a happy Creality owner for years, using it as a workhorse for our project prototyping in a good and bad days.

It sort of worked out to the point when now where we are moving to the Phase II, I decided to keep up with this brand and expand on our manufacturing with some new features + also get rid of one of the main of its issues – that annoying pitch noise where printing. It already went through multiple upgrades such as nozzle and direct drive from Micro Swiss, new printing plate, new thermal sensor, adjusting wheels, levelling upgrade … so I have not expected any major drama.

Anyway, being aware of some potential peculiarities, I contacted Creality’s support to get detailed and professional guidance on our Ender-5 Plus to a “silent” 32-bit board upgrade.

It took a while, but it worked out.

However, post-upgrade, a previously working control path (USB serial + host action commands) disappeared from the firmware. After months of circular responses between “official” support, an AU dealer, and an unresponsive historical retailer, I still cannot get either (1) a fixed 32-bit firmware build, or (2) the corresponding source code + configuration for the build they distribute (Marlin/GPL).

Here is a brief summary of the Creality case:

• Printer: Creality Ender-5 Plus (E5+)
• Why upgrade? Environmental noise made long runs untenable – asked for a quieter path and was guided to a 32-bit “silent” mainboard + cable kit.
• What broke? After the upgrade, the firmware build no longer exposed the USB serial interface with HOST_ACTION_COMMANDS enabled – a control path I had relied on for production runs.
• What I asked for:
  1. A 32-bit E5+ firmware .bin with USB-CDC + HOST_ACTION_COMMANDS enabled (and related flags), or
  2. The matching source + configs for the exact E5+ 32-bit firmware Creality distributes so I can compile those flags myself.
     (Creality’s firmware is Marlin-based; GPLv3 requires supplying corresponding source upon request.)

Timeline (condensed)

(Full timeline with subjects and dates is available on request.)

• Phase 1 – Stable baseline: E5+ operating in production; the USB/host-actions control path was available and used.
• Phase 2 – Vendor-guided upgrade: Creality support directs me to swap in a 32-bit silent board plus an additional cable kit. Upgrade flashes successfully.
• Phase 3 – Regression appears: Post-upgrade, USB serial / host actions are missing from the provided build.
• Phase 4 – Ping-pong:
  • “Not our official software.”
  • “Reinstall the old 8-bit board and re-flash.”
  • “Ask the dealer for a refund.”
  • Dealer: declines (order outside 30-day window; model compatibility listing excludes E5+), points back to the manufacturer for technical resolution.
  • Manufacturer: repeatedly declines to provide a fixed binary or the matching source/configs.
• Phase 5 – Escalation attempts:
  • Asked Creality AU to escalate to HQ; they relayed an internal repo pointer for “32-bit-upgraded E5+” but no confirmed binary or configs enabling USB-CDC + host actions.
  • Reiterated the two reasonable remedies: firmware (or source) / full refund with return. Neither accepted.

The Numbers (because data helps)

• 73 total messages (34 by me, 39 from them)
• 32,715 words exchanged
• “OctoPrint” mentioned 58 times (mostly later being repeated as an excuse for not taking an action by Creality)
• HOST_ACTION_COMMANDS mentioned 18 times
• “USB-CDC” mentioned 15 times
• 38.10 hours average next-response time (both sides)

Material (hard) costs — line items

Time/effort (estimates)

• Hardware swap, wiring, firmware flash, calibration & sanity test: ~5.0 h (range 4–6 h).
• Drafting emails (34 sent; ~15 min each): ~8.5 h.
• Reading/triaging replies (39 received; ~4 min each): ~2.6 h.
• Preparing artifacts (screenshots, timeline, uploads): ~2.0 h.
• Troubleshooting/retests after guidance: ~3.0 h.

Total time (rounded): ~21 hours.

Creality side (for context): 39 replies averaging ~5 minutes each (short, formulaic): ~3.25 h.

What This Is – and Is Not

• This is a regression introduced by an official, vendor-guided upgrade path.
• This is not a demand that Creality “support third-party software.” I am asking that the standard serial + host-action control path not be compiled out of their own firmware build — or that the corresponding source/configs for that build be provided so I can self-compile those flags.

Why GPL Matters Here

Creality’s firmware for these printers is Marlin-based (GPLv3). If you distribute a Marlin binary, you must provide the matching source and (crucially) the configuration used to build that binary upon request.

I asked for exactly that. I have not been provided with it.

Reasonable Remedies (unchanged since Day 1)

1. Provide a working .bin for Ender-5 Plus (32-bit) with USB-CDC + HOST_ACTION_COMMANDS enabled (and related flags).
   or
2. Provide the corresponding source + configs for the exact E5+ 32-bit firmware Creality distributes, so I can compile those flags myself.
   or
3. If neither can be done, accept a full return for refund (entire printer with the 32-bit board + cable kit), with shipping covered.

Any one of these closes the issue.

Lessons Learned (for CURRENT AND FUTURE operators)

• Treat any “official” upgrade as a breaking change until proven otherwise; take a full pre-upgrade snapshot of firmware + config.
• When a vendor’s firmware is GPL-based, the matching source + configs are not a favor – they’re a requirement. Ask for them early.
• Keep a structured archive of all comms; a simple timeline and stats table helps cut through “he-said/she-said.”

But mainly – DO NOT BUY ANY CREALITY PRINTER – EVER – AGAIN!

There are others! (https://www.prusa3d.com/, https://au.store.bambulab.com/)

PS: Creality has been contacted & offered to provide their feedback.

In 2021, I wrote a blog post Helium vs. Hydrogen atom size exploring why I prefer hydrogen over helium for lighter-than-air applications. One of my key arguments was that hydrogen molecules, being larger (kinetic diameter 289 pm vs. helium’s 260 pm), should leak more slowly through the airship envelope. I likened this to a tea strainer-larger particles can’t escape as easily through small holes.

But I was recently contacted by Mr. Peter Garwood, historian and photojournalist of the Balloon Barrage Reunion Club, who generously shared his article on gas permeability during the barrage balloon era. His insights, backed by both history and physics, prompted me to revisit and correct some of my original assumptions.

The Misconception: Bigger Molecule = Less Leak

My original logic hinged on kinetic diameter alone, assuming that a bigger molecule like hydrogen would have more difficulty passing through small imperfections in fabric.

However, this overlooks the mechanism that actually governs gas leakage in airship envelopes: Effusion, not just Diffusion.

The Reality: Effusion Favors Hydrogen

Peter points to the Thomas Graham’s Law of Effusion, dating back to 1832, which says that lighter gases effuse faster, regardless of their physical size. In fact, under identical conditions, hydrogen effuses 1.4 times faster than helium, even though it’s “bigger”Gas Permeability.

“In simple terms this means that the larger Hydrogen gas is the ‘Houdini’ of gases and will leak faster than the smaller Helium gas.” – Peter GarwoodGas Permeability

That’s quite a turnaround! My earlier assumption neglected the role of molecular mass and internal pressure, which drive effusion. The “tea strainer” analogy doesn’t quite hold up when we’re dealing with quantum-scale particles under pressure.

Practical Implications for Airships

Well, despite hydrogen’s faster leak rate, I think it still holds major advantages for airship use:

• Hydrogen is ~6% lighter than helium, giving better lift.
• It’s renewable, whereas helium is finite and expensive.
• Envelope materials and temperature control can mitigate effusion to practical levels.

As I noted in the 2024 addendum to my original post, temperature also plays a crucial role—higher temperatures mean higher molecular activity and increased leakage. So while hydrogen leaks faster than helium at a molecular level, real-world airship performance depends on a broader set of factors: pressure, envelope materials, operational temperatures, and refuelling logistics.

Acknowledgment and Thanks

I want to thank Peter Garwood for getting in touch and providing his correction. It’s great that someone with his life-time experience invests his time into our little project.

If you’re interested in more of Peter’s work, check out the Balloon Barrage Reunion Club at www.bbrclub.org. It’s a treasure trove of historical knowledge from the era when these gases weren’t just theoretical.

It’s been a journey. From experiments with hydrogen balloons, to actual hydrogen lifts and a full-blown demo flight, Phase I of the H2Use airship project is officially wrapped.

Let’s rewind for a sec. Our roadmap has been public from the start – our Trello board laid out Phase I goals and, give or take a few, we delivered.

Our very first website post goes all the way back to June 4, 2020 at 2:11 AM and the Trello plan first hit the blog around December 19, 2021. Since then, the real magic happened inside the Projects section — our testing ground for everything we needed to make flying with hydrogen a reality. Here’s the greatest hits list:

• Ballast Control
• CF Tubes
• Celestial Navigation
• Gas Cells
• Jet-cart
• Gimbals
• Vectoring Thruster
• Hydrogen Balloon
• Propellers
• Testing and Calibration Rig
• High-capacity Battery

Listing through all the 2700 pictures we took and 300 videos, we clearly made some great friends and cool memories

All these were mostly just experiments – they were also building blocks and let us pull off the big one: the Phase I Demo Flight. It was a mini miracle, after all these hours and days spent on this, yes we delivered! Some can have a polemic here about all ending in a rogue airship flying away, but given the overall project – it was awesome wrap up with all the glitter!

So, what’s next? We’ve cracked open a new Trello board, and Phase II has a name: Esquie. This time we’re scaling up – way up with Target specs:

• Volume: ~500 m³
• Size: 19 × 8 × 5 m
• Operational Time: up to 7 days
• Range: 2000 km (return)
• Payload: 200 kg
• Speed: 30 kph

Design work is happening – from developing 400mm diameter tubes (18m long and weighing just 27kg) and upgrading our 3D printer (faster, quieter and with better results), to envelope and gas bag concepts (FluidX3D), gimbal redesigns (2kW motors) and more. And yes, the blog will stay alive with all the gritty updates, breakthroughs, fails, and milestones along the way.

Finally, a massive thanks.

Too many people helped to list everyone – but some stand out every time we fly (literally or metaphorically):
Veronika (for your infinite patience), Sebi (for coding through chaos), Serge (for never letting go), Kristian, Richard, Chris, the Redcliffe Gang (Robin, Greg, Liz, Julia, Simon, Tam, Paul…), HOBR crew (Martin, Adam, Misa, Ondrej, Mirda, Lumir, Brano…), all our external helpers (Vlada, Oli, My Mum, Rob, Damian, Channon), and every organization that helped us lift off in every sense.

Thank you. We’re not done — in fact, we’re just getting started.

Let’s make Phase II epic!

Date: 25 May 2025
Location: Kayo Stadium (Dolphins NRL), Redcliffe, QLD

Executive Summary

On Sunday, May 25th, 2025, the H2Use team conducted a full-scale demonstration of its prototype hydrogen airship at the Dolphins NRL Kayo Stadium in Redcliffe. This event marked the culmination of over four years of independent R&D work, driven by a small team passionate about lighter-than-air transport development through the modern technology.

While the airship was ultimately lost due to an in-flight structural failure, the demonstration successfully validated key technologies and provided critical data and insight to conclude Phase I of the H2Use project. It also confirmed public interest, engineering viability, and partner support, setting the stage for the next phase of development.

Technology Demonstrated

• Hydrogen as dual-purpose resource: Successfully used as a safe lifting gas and for onboard power generation via fuel cell.
• All-electric propulsion system: Demonstrated silent, emission-free thrust using EDFs and vectored gimbals.
• Ballast control system: Validated dynamic water ballast tanks with solenoid valve control, enabling level hovering and controlled lift.
• Advanced hybrid airship design:
  • Biconvex envelope geometry reduced size by half vs traditional cigar-type shapes, while achieving stable flight.
  • Centralised keel and duct system introduced a new propulsion concept: intakes lowered frontal pressure, while rear thrusters vectored motion.
  • Integrated gimbal-based control replacing conventional elevators/rudders with more responsive vectored actuators.
• Hydrogen-electric LED system: Showcased mid-flight power conversion from hydrogen to usable electrical energy.
• Weather & atmospheric validation: Forecasts and wind models were essential to safe operations — a key rediscovery from historic airship practices.
• Recovery via GPS-traced trajectory: Final flight path calculated post-event thanks to GPS data — 21.4 km traveled over ~3–4 hours.

Partners & Acknowledgments

We would like to express heartfelt thanks to our supporters who made this demonstration possible:

• CoreGas Australia – For hydrogen cylinder supply, safety consultation, and logistical support. Special thanks to Wodek Jakubik and Mayur Kora for their technical insight and reliability.
• Dolphins NRL Club & Mr. Youri Wystyrk – For granting access to Kayo Stadium and trusting us with this ambitious event. Your facilities and support made this day possible.
• Hydrogen Grand Prix (H2GP) – For providing the hydrogen cell and hydrate canisters.
• Silver Team (Media) – Martin & Jacob Kosik, Chris Drake, Mick Cullen, Simon Steffen – for exceptional documentation of a historic day.
• Green Team (Engineering Team) – Kristian Nemeth, Lumir Bodlak, Branislav Kusy, Adam Galvin – for making the airship assembly and handling safe and easy.
• Red Team (Security Team) – Vilem Cerny, Serge Testa, Rob Mataic, Damien Foy, Channon – for ensuring safe Hydrogen handling, separation of demo operations from our audience and guests.
• All Guests & Volunteers – Your support, presence, and understanding made this day meaningful.

Outcomes and Lessons Learned

What Worked

• Test plan provided excellent structure; where followed, operations ran smoothly.
• Airship achieved lift, hover, directional thrust, and real-time ballast control.
• Hydrogen systems operated safely and as expected.
• Assembly and electronics performed flawlessly thanks to pre-demo preparations.

Challenges and Key Learnings

• Envelope Material: Super-light membrane exhibited signs of distributed wear → future iterations require stronger, factory-quality manufacturing.
• Structural Stress Points: Rear gondola attachment failed under load → led to unplanned detachment and uncontrolled ascent.
• Deviation from Flight Plan: Last-minute decision to mount landing suspension introduced unnecessary risk.
• Software Rewrites: Late code changes affected original control capabilities (gimbal-assisted forward thrust).
• Live GPS tracking: Absence of a tracker limited real-time recovery response → now deemed essential for future flights.

Despite these setbacks, the team remains confident that these are not failures, but rather critical validations of the hypothesis: that modern airships, powered by hydrogen and built using 21st-century technologies, deserve a place in future transportation infrastructure.

Recovery Story – A Bonus Ending

After a dramatic unintended ascent and several hours adrift, the airship was located by the Reef Cat ferry crew in Moreton Bay and safely recovered. With one envelope partially deflated, the airship had travelled 21.4 km before being spotted and retrieved. The ferry captain described the event as his first-ever UFO sighting report, and the “silver fish” became an overnight anecdote. Their team kindly shared photos, videos, and recovery coordinates — a surreal but fitting epilogue to a visionary project.

What’s Next?

This demonstration concludes Phase I of the H2Use project. We now shift focus to:

• Consolidating technical learnings
• Engaging new partners and collaborators
• Exploring scalable prototypes aligned with practical transport goals
• Laying groundwork for long-term viability of hydrogen-powered aerial logistics

The loss of the prototype is not the end — it’s the opening of a new chapter.

Thank you for believing in the vision. Together, we made history — and we’re just getting started.

— Jan Bilek and the H2Use Team

We have a big weekend behind us! The actual plan for and the structure of the envelope blueprints was:

1. Airship Envelope:
   • Total length: 6500mm
   • Front section: Half-torus, forming an intake funnel, 1500mm long, radius 1000mm
   • Central section: Cylinder, 2000mm long, radius 1000mm
   • Rear section: Half-ellipsoid, 3000mm long, radius 1000mm
2. Material Sheets:
   • Width: 1000mm (folded in the middle for handling and easier alignment when welding)
   • Circumference calculation based on radial distances
3. Objective:
   • Calculate radial distances and corresponding circumferences for points along the airship’s length.
   • Divide the circumference by the closest number of material sheets, then by 2 (because of folding).
   • Transfer these calculations into a cutting plan on material sheets.

To be able to cut the envelope in sheets it actually needed to be separated in multiple logical pieces where front section’s been split into the rotational half-ellipse(2) with an intake cutout (1).

Sheet shape calculation Excel spreadsheet then looks like this, getting some nice graphs:

Y-values from a spreadsheet are then providing widths of the half-folded sheet for every 10cm of its length. So the plan is to do 7 sheets alongside the envelope.

This image then shows single cutting sheet of 7, where all being identical:

There is also a wedge piece which serves to isolate the inner tube from envelope and also to support the envelope lift tensions across its length. On a spreadsheet above you can see it as Y (for) wedge.

Well the D-day came Saturday when whole team arrived to Vilda’s work in Beenleigh and long story short it took us nearly 10 hrs to translate that spreadsheet to reality – let pictures to talk.

Foreseeing this being whole day task, we took some cool time lapse of a whole procedure.

Ten hours later Vilda & Tom present all that treasure nicely folded in a box.

Huge thanks to the whole team – Vilda, Risa, Kristian, Seb, Tom and others! It wouldn’t be possible without your help! Thank you guys!

Next stage is to weld it all together. We are just looking into ~144m of air-tight welds! 😀

In continuation of our envelope development effort – there are plenty new things happening these days.

First thing first, there is a mass production of the envelope valves and beam sleeves. Actually there are 20 of those needed, where each set takes bit over 5 hrs to print. Those are also coming in two colours – green and red, using the aircraft (or boating) code for side identification. 2 of those were left as blue ones as intended for generic filling / venting valves purpose.

Second in line was to test our ability to fix existing envelope when having a rupture and also to test if we can use the tape to seal “the vedge” part. All the tests shown that both tapes (Mylar one and common industrial tape) can withstand much more than what’s needed.

The final test was to get some guiding values on the envelope pressurisation. For that we’ve extended our tiny Arduino project to record max pressure values for us and used their “Plotter” screen to visualise the output from the Serial port.

#include <Q2HX711.h>
#include <AverageValue.h>

const byte MPS_OUT_pin = 21; // OUT data pin
const byte MPS_SCK_pin = 22; // clock data pin
int avg_size = 10; // #pts to average over

long minVal = 100000;
long maxVal = 0; 

Q2HX711 MPS20N0040D(MPS_OUT_pin, MPS_SCK_pin); // start comm with the HX710B
AverageValue<long> ave(avg_size);

void setup() {
Serial.begin(9600); // start the serial port
}

void loop() {
  long measurement = MPS20N0040D.read()/ 256.0;
  ave.push(measurement);
  Serial.print(ave.average());
  if (measurement < minVal)
    minVal = measurement;
  if (measurement > maxVal)
    maxVal = measurement;  

  Serial.print(",");              //seperator
  Serial.print(maxVal);
  Serial.print(",");              //seperator
  Serial.println(minVal);
}

Then we had quite a fun throughout several attempts to burst the envelope, while measuring its internal pressure. All of those are quite interesting.

Second try by Seb.

Third one – the final one, where Seb needed to use cycling pump! Don’t forget to get a sound pretty loud as it comes with cool sound effects! 😀

It is probably not too obvious on that video, but measured values were 32768 as the base-line and 49151 as the maximum. What are these values? No idea. What was clear is that when around 35000 the envelope was seriously hard. Whatever it means is that we are now quite confident that we can do pretty strong weld and also having some idea on pressure values to test our final envelope!

Things were bit quiet around lately, but we are actually making some good progress. The most important things first – the Windreiter guys (Andreas) agreed to provide us with huge amount of their Tritax blimp material, also giving us very friendly discount.

(Apparently they strongly discourage people from buying the foil directly from them as it is horrible work to re-roll precisely and most people then fail welding envelopes and then are pissed – so don’t do this!)

It took DHL couple weeks, but all arrived well and in a good shape.

Having material in our hands we immediately started with preps on few jigs and also to retest our welding technique. First part was to develop a a ring which would allow gimball trusses to pass through the envelope. It took a little to get that going with OpenSCAD.

use <ShortCuts.scad>

r1 = 20.5;
r2 = 35;
ribs = 16;
t1 = 2; //ribs thickness
t2 = 2; //slab thickness
t3 = 1.5; //tube thickness
length = 50;

module tube_inner() {
Ry(90)
cylinder(2, r2, r2, $fn = 100);
for(w=[0:360/ribs:359])
  Rx(w)
  linear_extrude(height = 2, v = [0, 0, 1], center = true, convexity = 10, slices = 20, scale = 1.0, $fn = 16)
  polygon( points=[[0,r1],[t1+3,r1],[t1,r2-0.1],[0,r2-0.1]] );
  
Ry(90)
cylinder(length, r1, r1-1, $fn = 100);
}

module outer_tube() {
D() {
tube_inner();
Tx(-.1)
Ry(90)
cylinder(length+2, r1-t3, r1-1-t3, $fn = 100);
}
}

module inner_tube() {
D() {
Ry(90)
union(){
cylinder(2, r2, r2, $fn = 100);
cylinder(length, r1-t3, r1-1-t3, $fn = 100);
}
Tx(-.1)
Ry(90)
cylinder(length+2, r1-t3*2, r1-1-t3*2, $fn = 100);
}}

outer_tube();
inner_tube();

It worked out nicely:

Printing itself is now tuned to precision so those came out lovely as well.

Important part was to check on how will those jigs go though the envelope into inner sleeve.

As you can see, there was some trial and error process in place. Clearly using super-glue wasn’t good enough, but resenting back to Selley’s contact glue worked out well at the end. At the end I also did a test on stressing the seal and it looks like all envelope forces are distributed well and seal seems to be air-tight.

Next time we’ll need to test the welding and check how much stress these welds can take so we have some baseline value on expected envelope pressurisation.

As per release of the ChatGPT v4.o I thought giving it a go on our Blimp topic and test some of its new features like the image recognition. This is how it worked out:

Me: Hi, would you be able to tell me what you can see on the picture attached?

ChatGPT: In the attached image, there is an airship flying over a desert landscape. The airship, named “Airbender” with the designation “OK-0001,” appears to have a twin-hull design with two large, cylindrical envelopes. The background showcases sand dunes and distant mountains under a sky with clouds. The airship’s engines or propellers are visible on the sides of the hulls. The overall scene conveys a futuristic or conceptual design for an airship in a scenic desert environment.

Me: That’s excellent! Thank you! Would you please try to generate similar picture like this? A futuristic airship, with a twin-hull design with two large, cylindrical envelopes flying over some interesting place (leaving this one with you to pick)?

ChatGPT:

Here is the generated image of a futuristic airship with a twin-hull design flying over a lush, green valley surrounded by towering mountains. The scene conveys advanced technology and a sense of adventure in a beautiful, natural setting.

Also tried to ask it if I can have an animation or video, but that didn’t work out. Perhaps next time! Anyway, that’s lovely isn’t it?

In a follow up on our Frame fixes, we did another round of testing last weekend which worked out in a mild success – we’ve been able to assemble whole structure in under 5 hrs, while nothing (major) broke throughout our test. Still I was hoping to demonstrate some significant forward movement what wasn’t achieved. Ok, we moved probably an inch! 😀

Gallery below covers whole day pretty well.

Here comes engines test (80%), I simply can’t get enough of that jet-sound. Also you can notice that front right gimbal is not running, that + one of the engines running in a wrong directions significantly contributed to the outcome of our test.

Now the main test itself.

Huge thanks to the whole ground team, mainly to Seb dealing with thousands issues, Viktor & Anfried providing muscles, Veronika and Jitka for feeding us and to usual audience of our supporters!

In follow up on a frame damage as per the DAMAGE REPORT article, we had to do few improvements. One of the obvious problem has been that forces were not properly transferring from the upper part of the frame to the suspension – causing major stress on both upper and lower clamps. While that looks like an obvious design flaw, it’s been caused by a late decision to actually add the suspension (& wheels) itself.

Anyway, a new clamp was needed to address this. See the image compare widgets below. The first one shows whole gondola with a new clamp, where second one comes with an detail.

Second image compare also shows material reinforcements to the front clamp, where new reinforcing rings were introduced to improve clamp’s strength.

Printing both took a while as there were still some problems with a printer’s filament feed & flow settings, but finally had everything working out with following setting in Cura.

Prints worked out very well.

Interestingly whole clamp worked out to be weighing 107g.

Then mounted with tubes it looks pretty cool.

Final part was to fix one of the tubes which broke.

Procedure itself was already tested, but I’ve been still glad it worked out again. Simply wrap it in additional two layers of CF, apply resin, another layer of “white tape” followed by a layer of the office tape and finally heat it up with a fan to 160C for 20 minutes.

It worked out nicely and it feels strong again!

Next step is to continue with mounting new clamps so we are ready for another taxiing test! I plan to add few more pics on that (finalized clamps installation) later.

Subtitle: A Playful Exploration of Eco-Friendly Electricity Filtration project idea with assistance from ChatGPT

Constantly exploring powers of ChatGPT and getting bit bored over the Christmas we (Vilda & I) came with a hilarious use case to stretch its brain-power. The idea was pretty simple – If it could design a business plan for us, developing a company would sell a device that differentiates electricity generated by nuclear power plants from renewables and selectively allows only renewable energy into a home. (Original idea came from here.)

So we started with asking ChatGPT’s opinion on this idea:

So, What do you think about this?

Designing a business plan for a device that differentiates electricity generated by nuclear power plants from renewables and selectively allows only renewable energy into a home is a unique and challenging concept. There are several critical aspects to consider:

1. Technical Feasibility: The primary challenge is the technical feasibility. Electricity from different sources is indistinguishable once it enters the grid. Separating them at the end-user level is currently not feasible with existing technology. However, a device could simulate this by tracking the proportion of renewable energy in the grid and adjusting household consumption accordingly.
2. Market Research: Understanding the market in Austria for such a device is crucial. This involves assessing consumer interest in renewable energy, willingness to pay a premium for such devices, and the regulatory environment in Austria regarding energy sources and consumer devices.
3. Product Development: The use of an ESP32 for logic and statistics is a sound choice for a prototype. It’s cost-effective and versatile for IoT applications. The device could provide real-time data on energy usage and its source proportions, giving users a sense of control and contribution to renewable energy usage.
4. Cost Analysis: A $2000 price point is significant. A detailed cost analysis covering manufacturing, distribution, marketing, and after-sales service is necessary. You would also need to consider the return on investment for consumers and how long it would take for them to recoup the cost through energy savings or other incentives.
5. Regulatory Compliance and Partnerships: You’ll need to navigate the energy sector’s regulations in Austria, potentially partnering with energy providers or government bodies. This would also involve ensuring the device meets all electrical safety and compatibility standards.
6. Marketing and Sales Strategy: Developing a compelling marketing strategy that highlights the benefits of the device is crucial. This could include environmental impact, potential cost savings, and the novelty of the technology.
7. Sustainability and Future Expansion: Consider the environmental impact of manufacturing and disposing of the device. Also, plan for future expansion possibilities, like scaling to other countries or integrating with smart home systems.
8. Funding and Financial Projections: Outline how you’ll fund the initial development and production. Create financial projections including initial investment, break-even analysis, and profitability forecasts.

In summary, while the concept is innovative, its technical execution is currently not feasible in the way described. However, creating a device that promotes renewable energy usage through monitoring and statistics, combined with a strong business plan focusing on market research, cost analysis, regulatory compliance, and marketing strategy, can be a viable alternative.

That sounds great, would you be able to generate an image depicting the device for me please?

Here is the image of the modern, sleek home electricity monitoring device, integrated with an ESP32 microcontroller. This design is intended to illustrate the concept of a device that monitors and promotes the use of renewable energy in a household setting.

That looks awesome, would you be able to suggest a company name & domain name we can use?

Certainly! When choosing a company name and domain for a business focused on innovative energy solutions, it’s important to select something that is memorable, easy to spell, and reflects the eco-friendly and technological nature of your product. Here are some suggestions:

Company Name Ideas

1. EcoVoltSync
2. GreenCurrent Innovations
3. RenewaWatt
4. EcoEnergy Matrix
5. PulseGreen Tech
6. VerdeWise Energy
7. CleanVolt Insights
8. EcoStream Technologies
9. RenewableRhythm
10. NaturaVolt Solutions

Corresponding Domain Name Ideas

1. EcoVoltSync.com
2. GreenCurrentInnovations.com
3. RenewaWatt.com
4. EcoEnergyMatrix.com
5. PulseGreenTech.com
6. VerdeWiseEnergy.com
7. CleanVoltInsights.com
8. EcoStreamTech.com
9. RenewableRhythm.com
10. NaturaVoltSolutions.com

Before finalizing, it’s essential to check the availability of these names as both company names and domain names. This helps ensure uniqueness and avoid legal issues related to trademarks or existing entities.

Nice! Would you be able to suggest relevant logo design for me please?

Here is the logo design for ‘EcoVoltSync’. This design encapsulates the concept of combining eco-friendliness with technology, represented through the stylized green leaf and lightning bolt.

Can you please suggest company motto which we can use to advertise our new products?

Certainly! For a company focusing on electricity filtration based on its source, the motto should reflect the uniqueness of this technology and its impact on energy consumption. Here’s a revised suggestion:

Company Motto:

“Select Your Source, Shape Your Future”

This motto captures several key elements:

• Select Your Source: Directly references the core functionality of your products, which is the ability to filter and select electricity based on its source (nuclear, solar, wind, etc.).
• Shape Your Future: Implies that this choice in energy source is not just a functional decision, but a meaningful step towards shaping a more sustainable and personalized energy future.

This motto encapsulates both the innovative nature of your technology and the empowerment it offers to consumers, aligning perfectly with the ethos of your company’s vision and products.

Excellent! Would you be able to suggest names for fictional particles or technologies which would allow us to distinguish sources of electricity? For nuclear we have tachions, but I don’t like it, while we need those for solar, wind, coal and water based sources of electricity as well.

Certainly! Creating fictional names for particles or technologies that could hypothetically distinguish between different sources of electricity is an interesting and creative task. Here are some suggestions:

1. Solar Energy:
   • Name: “Photonixons”
   • Description: These particles are theorized to carry the unique quantum signature of solar radiation absorbed and converted by photovoltaic cells.
2. Wind Energy:
   • Name: “Aerions”
   • Description: Aerions are imagined as microscopic particles that are energized through the kinetic process of wind turbines, carrying a distinct energy pattern unique to wind-generated electricity.
3. Coal Energy:
   • Name: “Carbonix Particles”
   • Description: These are theoretical particles that emerge from the combustion process in coal power plants, characterized by a specific carbon-based molecular vibration.
4. Hydroelectric Power (Water):
   • Name: “Hydrolectrons”
   • Description: Hydrolectrons are fictional particles thought to be generated by the movement of water in hydroelectric plants, encapsulating the unique vibrational energy of flowing water.
5. Nuclear Energy:
   • Name: “Fissionites”
   • Description: Fissionites are imagined as unique subatomic particles theorized to form during the nuclear fission process in reactors. These particles would possess a specific energy pattern or signature that is exclusive to the atomic splitting in nuclear reactions. Fissionites, in this fictional concept, would be the key to identifying and distinguishing nuclear-generated electricity from other sources due to their unique atomic characteristics.

Each of these names and descriptions presents a fantastical and speculative view of how different energy sources might have unique identifiable properties at a microscopic or even quantum level. In reality, of course, electricity from different sources is indistinguishable once it’s on the grid, but in the realm of science fiction or speculative technology, these concepts can be quite intriguing!

I like it a lot! Would you be able to suggest a fictional process how those particles would transform into electricity?

Certainly! Let’s envision a fictional process for how these unique particles, like Fissionites for nuclear energy and others for different sources, could transform into electricity:

The Concept: Energy Signature Conversion Process (ESCP)

Process Overview

The Energy Signature Conversion Process (ESCP) is a fictional, advanced technological method that involves the transformation of unique energy particles, specific to each energy source, into usable electricity. The process is based on the theoretical premise that each energy source emits distinct particles with unique properties.

1. Particle Harvesting

• Mechanism: Specialized collectors, called “Harvesters,” are designed for each energy source. These Harvesters are equipped with nano-scale sensors and quantum field generators to detect and capture the specific particles (like Fissionites, Photonixons, Aerions, etc.).
• Example: In a nuclear power plant, Fissionite Harvesters would be integrated into the reactor’s core, capturing Fissionites released during fission reactions.

2. Energy Signature Amplification

• Mechanism: Once captured, these particles undergo an amplification process where their unique energy signatures are enhanced. This is done using a “Resonance Chamber,” a device that uses electromagnetic fields to resonate with the specific frequency of each particle type.
• Example: Fissionites, with their unique vibration frequencies, are amplified to increase their energy output.

3. Signature-to-Electricity Conversion

• Mechanism: The amplified particles are then fed into a “Conversion Matrix.” Here, their energy is transformed into electrical energy through a process akin to reverse particle acceleration.
• Example: Amplified Fissionites enter the Conversion Matrix, where their nuclear-specific energy is converted into a stream of electrons, generating electricity.

4. Electricity Stabilization and Distribution

• Mechanism: The newly generated electricity is then stabilized to match the standard electrical grid requirements. A “Grid Sync Unit” adjusts the voltage, frequency, and phase to ensure compatibility.
• Example: Electricity derived from Fissionites is synchronized with the grid, making it indistinguishable from electricity generated by other means, yet it retains a trace of its original energy signature.

5. Energy Monitoring and Management

• Mechanism: A “Signature Tracking System” continuously monitors the energy flow, ensuring the integrity of the process and providing data on the proportion of each energy type being used.
• Example: Users can see real-time data on how much of their electricity is coming from nuclear, solar, wind, etc., based on the particle signatures detected.

Conclusion

The ESCP is a highly advanced, fictional concept that embodies the idea of not just generating electricity, but also preserving a trace of its origin through unique subatomic particles. This process allows for a futuristic way of distinguishing and utilizing energy from various sources, adding an extra layer of depth to energy management and consumption in a speculative technology scenario.

I love it! Would you please generate an image depicting how our website would look like using some of traditional Austrian Alps motives as well?

Here’s the conceptual image of the website design for your energy company, now incorporating traditional Austrian Alps motifs, blending the innovative aspect of your technology with a nod to Austrian heritage.

It is great! One more thing – would you be able to add few traditional Alpen animals in the mix?

Here’s the updated conceptual image of the website design, now featuring traditional Austrian Alps motifs along with Alpen animals, enriching the scenic backdrop with elements of Alpine wildlife.

I love it! Would you be able to describe our typical customer?

Certainly! Describing a typical customer for your innovative EcoVoltSync device involves understanding the profile of someone who would be interested in a high-tech, environmentally conscious energy solution. Here’s a detailed customer profile:

Typical Customer Profile for EcoVoltSync

1. Demographics:
   • Age: 30-50 years old, a segment that is typically financially stable and willing to invest in home improvements.
   • Location: Urban or suburban areas, where there is a higher concentration of tech-savvy and environmentally aware individuals.
   • Income Level: Middle to upper-middle class, as the device’s price point suggests a certain level of disposable income.
2. Psychographics:
   • Environmentally Conscious: Highly values sustainability and is concerned about their carbon footprint.
   • Tech-Savvy: Comfortable with new technology, likely to be early adopters of innovative gadgets.
   • Quality-Oriented: Prefers products that offer superior performance and reliability, even if they come at a higher price.
3. Lifestyle:
   • Homeowners: Likely to be homeowners who are interested in smart home technology and energy efficiency.
   • Family-Oriented: May have a family and are concerned about creating a sustainable future for their children.
   • Active Social Life: Enjoys hosting and sharing their lifestyle choices with friends and family, possibly influencing others in their social circle.
4. Behavioral Traits:
   • Research-Driven: Spends time researching products and technologies before making a purchase decision.
   • Brand Loyal: Once they find a brand that aligns with their values, they are likely to be loyal and make repeat purchases.
   • Socially Responsible: Prefers to support companies that have a positive impact on society and the environment.
5. Values and Beliefs:
   • Strongly believes in reducing reliance on non-renewable energy sources.
   • Values transparency and authenticity from brands.
   • Seeks products that align with their ethical and environmental principles.
6. Goals and Motivations:
   • Aims to reduce their household’s environmental impact.
   • Seeks to integrate cutting-edge technology into their daily lives.
   • Motivated by the desire to be a part of the solution to global environmental challenges.

Conclusion

Your typical customer is a tech-savvy, environmentally conscious individual who values quality and innovation. They are willing to invest in products that not only benefit their lifestyle but also contribute positively to the environment. They are influencers in their own right, often setting trends within their social circles.

Awesome! Would you be able to generate an image of our “perfect customer” please?

Here’s an image depicting the “perfect customer” for your innovative energy product, showcasing a tech-savvy and environmentally conscious individual in a modern, sustainable living environment.

Would you please create a fictional chat where our sales representative will be selling our new device to a customer? Just a short one and bit cheeky as well. 🙂

Certainly! Here’s a fictional, slightly cheeky chat conversation between a sales representative of your company and a potential customer:

Sales Rep: “Good day! Have you ever dreamed of telling your electric company, ‘No thanks, I only do solar today’? With our EcoVoltSync device, dreams meet reality!”

Customer: “Sounds intriguing, but I’m not sure I follow. How does it work?”

Sales Rep: “Imagine a bouncer at a club, but for electricity. Our device stands at your power socket’s door, only letting in the cool, renewable energy. Nuclear? Coal? ‘Not on the list’, it says!”

Customer: “Haha, that’s one way to put it! But seriously, can it actually differentiate between energy sources?”

Sales Rep: “Absolutely! Thanks to our patented ‘Fissionites-Photonixons Detector’ or as we like to call it, the ‘Energy VIP Pass’, it identifies and filters your electricity based on its source.”

Customer: “Interesting! And what if I want only wind energy on windy days?”

Sales Rep: “Our device is as flexible as a gymnast. Windy day? It sways with the Aerions. Sunny day? It basks in the Photonixons. You get the drill.”

Customer: “Sounds like a party at my power socket. But what’s the cost?”

Sales Rep: “For the exclusive experience of tailoring your electricity? A small price of $2000. A bargain for being the eco-trendsetter in your neighborhood!”

Customer: “Eco-trendsetter, huh? I like the sound of that. Count me in!”

Sales Rep: “Fantastic! Your power socket is about to become the coolest club in town. Welcome to the future of energy consumption!”

This conversation paints a fun and engaging picture of the product, highlighting its unique features in a playful manner.

That’s great. Now if you can please generate a flyer for our product.

Here’s the promotional flyer design for the EcoVoltSync device. It highlights the key features and the eco-friendly aspect of your product in a visually appealing layout.

I love it! Would you be able to suggest an image on how the mobile phone application to control this product would look like?

Excellent. We are here thinking about some more merchandise to offer, would you be able to generate for us Eco Volt Sync soft drink?

Here’s the image of the fictional ‘Eco Volt Sync’ soft drink, designed to reflect an eco-friendly and refreshing concept.

Thank you, you’ve been great & we had an awesome fun! You are amazingly powerful technology and it is a pleasure to work with you.

You’re very welcome! I’m thrilled to hear that you had an enjoyable and productive time working together. If you ever have more questions or need assistance in the future, don’t hesitate to reach out. Best of luck with your projects, and have a fantastic day!

As we prepare to bid farewell to 2023, it’s a time for reflection, gratitude, and anticipation. This year has been an extraordinary chapter in our journey at [Your Company/Your Project Name], filled with challenges, achievements, and invaluable experiences. As we stand at the threshold of 2024, we are filled with excitement for the adventures that await us.

First and foremost, a heartfelt thank you to our incredible team. Each one of you has been instrumental in steering our project towards success. Your dedication, creativity, and tireless efforts have not just propelled us forward but have also laid a strong foundation for our future endeavors. The milestones we achieved this year are a testament to your hard work and commitment.

2023 was a year of growth, learning, and collaboration. We navigated through complexities, celebrated our victories, and learned from our setbacks. I’ve put together a collection of the best pictures from few highlights in a tiny gallery below.

Looking ahead to 2024, we are gearing up for some serious flight experience. Our sights are set high, and our spirits are soaring. We are committed to pushing boundaries, exploring new horizons, and continuing our pursuit of excellence. With the support and collaboration of our remarkable team, we are confident that the coming year will be filled with groundbreaking achievements and exhilarating experiences.

Thank you once again to each member of our team for your phenomenal contributions. Here’s to a 2024 filled with innovation, success, and high-flying adventures!

Warm wishes, Jan & Seb

It took a while to write this report, obviously no one is too happy to share failures, so let’s make it short.

We’ve spent whole weekend putting things together and ended up having all gimbals and EDFs wired, working and tested. As you can see from following images it’s been a very rainy day on Sunday.

Robin was very kind and helped us with documenting everything including some cool videos.

I also took few pictures, mainly about all the wiring.

Then we ended up running short of time as it kept raining and I really wanted to do the “taxiing” test, so we removed most of the electronics, wrapped up gimbals, vectors and EDFs and took it to the street to see how it “just goes” to the end of the street and back.

A moment later structure collapsed.

All CF-parts survived nicely, but some more support will be needed, including parts re-printing. See you soon! 🙂

Through some channels where I am involved I noticed that Australian government is seeking feedback on their Aviation Green Paper including:

• airlines, airports and passengers – competition, consumer protections and disability
• access settings
• regional and remote aviation services
• maximising aviation’s contribution to net zero
• airport development planning process and consultation mechanisms
• general aviation
• fit-for-purpose agencies and regulations
• emerging aviation technologies
• future industry workforce
• international aviation

Well, as you may see, they don’t mention any kind of airships or alternative to current aviation standard to be even considered. So I decided to send out following submission:

Submission to the Aviation Green Paper 

From: Jan Bilek, CTO, EFTLAB and Founder of BBBlimp 

Date: November 14th, 2023 

Subject: Submission in Response to the Aviation Green Paper 

Introduction 

This submission is presented by Jan Bilek, CTO of EFTLAB and founder of the BBBlimp project, in response to the Australian Government’s call for feedback on the Aviation Green Paper. The BBBlimp project, detailed on our website (https://www.bbblimp.com/), represents a groundbreaking initiative in sustainable aviation, focusing on the development of hydrogen-powered autonomous airships. 

This submission aims to underscore the synergies between the BBBlimp project and the objectives of the Aviation Green Paper, particularly in advancing aviation to be safer, more connected, and environmentally sustainable. Additionally, it seeks to advocate for hydrogen-powered autonomous airships and suggests amendments to the Aviation Green Paper that would pave the way for similar innovative projects. 

Alignment with Aviation Green Paper Goals 

1. Environmental Sustainability: 

• Hydrogen-powered airships align with the Green Paper’s emphasis on reducing environmental impact in aviation. Airships produce zero emissions, significantly contributing to the reduction of greenhouse gases in the aviation sector. 
• The use of renewable hydrogen as a fuel source is in line with Australia’s focus on developing a hydrogen-based economy, presenting an opportunity for sustainable aviation. 

2. Innovation and Technological Advancements: 

• The modern airship projects incorporate advanced technologies such as 3D printing, robotics, machine learning, and modern materials like Kevlar and carbon fiber. This aligns with the Green Paper’s focus on promoting innovation in aviation. 
• Our use of IoT technologies enhances passenger safety and comfort, demonstrating a commitment to leveraging technology for improved aviation experiences. 

 
3. Accessibility and Inclusivity: 

• Airships offer a unique travel experience, potentially more accessible to individuals with disabilities due to the spacious and customizable nature of airship cabins. 
• The project’s focus on quieter travel (below 69 decibels operational noise) addresses the need for reduced noise pollution, benefiting communities near flight paths. 

4. Economic and Social Benefits: 

• The development of airship technology opens new economic opportunities in tourism, surveillance, and transportation, aligning with the Green Paper’s goal of a more connected aviation sector. 
• Airship projects bring potential to access remote and regional areas can enhance connectivity and accessibility, especially in parts of Australia that are currently underserved by traditional aviation. 

Recommendations 

In light of the above, we recommend the following considerations for the Aviation White Paper: 

1. Support for Sustainable Aviation Technologies: Encourage and facilitate the development of sustainable aviation technologies like hydrogen-powered airships. 

2. Innovation Funding and Partnerships: Establish funding mechanisms and partnerships also to support experimental innovative aviation projects, particularly those focusing on environmental sustainability. 

3. Regulatory Framework for New Aviation Technologies: Develop a regulatory framework that accommodates and promotes new aviation technologies, ensuring safety and accessibility. 

4. Promotion of Hydrogen Infrastructure: Support the development of hydrogen production and refueling infrastructure to facilitate the growth of hydrogen-powered aviation. 

Conclusion 

The Airship projects embodies a significant step towards a more sustainable, innovative, and inclusive aviation sector, while embracing the latest trends in technology. We are confident that our project closely aligns with the objectives of the Aviation Green Paper and can make a meaningful contribution to the future of Australian aviation. 

We anticipate the opportunity to collaborate and contribute to the development of the Aviation White Paper and are hopeful that this contribution will open an opportunity for hydrogen-powered airship projects to be considered as a part of Australia’s aviation future. 

Contact Information
…

Submission submitted!

While posting it, I found list of previous submissions. It is an interesting reading.

In preparations of our next stage I thought it would be good to have a scaled down envelope model we can send over to the Windreiter team to make sure that whole that concept is well understood.

Initial sketch of the envelope model showcasing the modular design and providing us with ~26kg buoyancy:

When visualized in OpenSCAD, that front part (EDF intake) looks like this:

And then the overall view of a one envelope with a part of inner structure is planned like below:

Started with some scratches on a cardboard paper and looking for a material and ended up picking the LLDPE plastic bin-bags as a first go. Tried multiple glues for gluing it through past months, but none of those did well. So when looking for our options I ended up finding a website Welding Plastic Bags which provides very simple way to solve this. Long story short it goes like this:

1/ You need a baking paper and a soldering iron with a flat tip and temperature control.

2: Stack Materials – The welding process is commenced by preparing the Mylar sheets, ensuring they were free of dust and oils. Then make a material sandwich as baking paper, plastic sheet A, plastic sheet B, baking paper.

3: Welding the Seam – Use pressure on the soldering iron and move it along the seam to melt the sheets. Tip of the iron needs to be so that the whole surface of the tip makes contact with the paper. Heat gun will fuse plastic sheets together, forming a strong bond. This step was critical in ensuring the envelope’s durability and airtightness.

Testing it on couple tiny objects we managed to manufacture following experimental balloon:

Seeing that doing reasonably ok, still that material seemed to be too thin and we’ve got many accidents burning through it. Seb then came with an idea to get back to a leftover of the Mylar (wide silver reflective film roll with tough black backing), which we tested instantly and that really started look pretty good! So we decided to go with that one.

Then it took pretty much couple weekends of cutting and welding.

But the result is worth it!

The last part was to do some weighing.

As you can see, scales say that it comes up with 235g. I think we used roughly about 1m2 of material so with our planned envelope of 70m2 it would take 16+ kgs. That’s unfortunately too much for our leftover weigh budget of ~12kg.

As always, we welcome insights or experiences from others working on similar projects. Feel free to share your thoughts in the comments below.

Today, I am thrilled to share a momentous milestone in our airship project—an achievement that brings us closer to reaching to the skies. It took more then a year, but our first airship’s inner structure finally takes shape!

The Majestic Structure: Our airship, which measures approximately 6.5 meters in length, nearly 5 meters in width (inclusive of mounted gimbals), and 1.5 meters in height (with more height to come once the envelope is inflated), now got through the first actual assembly and looks great. Interesting fact – whole this structure presented weighs just 8kgs (17lbs)!

See the gallery below (special thanks Seb & Julia for serving as models!).

I also prepared a bit of before and after so it doesn’t look like bunch of sticks. Unfortunately aligning a 3D model with a real-world perspective shown to be quite a peculiar task, so please ignore few imperfections.

[bafg id=”6498″]

Finally, we took a video which probably demonstrates the best overall size of that structure.

What’s Next: Well the electrification phase is ahead of us to bring this airship come to life. From gimbals to vectoring thrusters and EDFs, those still need to be carefully wired in.

Following electrification, we’re preparing for a crucial taxiing test. The plan is to evaluate our airship’s performance and check how we’ll be able to transport this creation from site to site.

And then, the pièce de résistance—crafting the envelope. The plan here is to ask the Windreiter guys to have it done for us – that will be another great milestone, seeing it inflated.

Stay tuned for more updates!

Thank you for being a part of our adventure.

In continuation to Seb’s initial attempt to connect our BBB with the QGroundControl, he actually achieved some super-cool progress – making it think it calls to a real drone!

But let’s start from the beginning – QGroundControl (QGC) is the Graphical User Interface (GUI) application which provides full flight control and mission planning for any MAVLink enabled drone. Its primary goal is ease of use for professional users and developers. All the code is open-source source, so you can contribute and evolve it as you want. and project website is here.

The idea is to use QGC in combination with the Mavlink and use it for our airship navigation.

As the first Seb used the Robot Control library for BBB to send UDP packets to a Mavlink. That’s been achieved through using the rc_mav_send_hearbeat function. We confirmed those with tcpdump accordingly:

$ sudo tcpdump -i any port 14550 udp

20:02:02.222327 wlp5s0 In  IP beaglebone.modem.14550 > mavic.modem.14550: UDP, length 40
	0x0000:  4500 0044 e42b 4000 4011 d387 c0a8 00e6  E..D.+@.@.......
	0x0010:  c0a8 00bf 38d6 38d6 0030 2edf fd1c 0000  ....8.8..0......
	0x0020:  0001 0121 0000 6d26 8cb0 62f6 c8ef 073d  ...!..m&..b....=
	0x0030:  405b 0000 0000 0000 0000 0000 0000 0000  @[..............
	0x0040:  ffff 7078                                ..px
20:02:02.552843 wlp5s0 In  IP beaglebone.modem.14550 > mavic.modem.14550: UDP, length 40
	0x0000:  4500 0044 e435 4000 4011 d37d c0a8 00e6  E..D.5@.@..}....
	0x0010:  c0a8 00bf 38d6 38d6 0030 fba2 fd1c 0000  ....8.8..0......
	0x0020:  0001 0121 0000 6827 8cb0 62f6 c8ef 073d  ...!..h'..b....=
	0x0030:  405b 0000 0000 0000 0000 0000 0000 0000  @[..............
	0x0040:  ffff a8b3                                ....
20:02:02.763607 wlp5s0 In  IP beaglebone.modem.14550 > mavic.modem.14550: UDP, length 40
	0x0000:  4500 0044 e45f 4000 4011 d353 c0a8 00e6  E..D._@.@..S....
	0x0010:  c0a8 00bf 38d6 38d6 0030 dfd2 fd1c 0000  ....8.8..0......
	0x0020:  0001 0121 0000 6228 8cb0 62f6 c8ef 073d  ...!..b(..b....=
	0x0030:  405b 0000 0000 0000 0000 0000 0000 0000  @[..............
	0x0040:  ffff ca82                                ....
20:02:03.027456 wlp5s0 In  IP beaglebone.modem.14550 > mavic.modem.14550: UDP, length 40
	0x0000:  4500 0044 e493 4000 4011 d31f c0a8 00e6  E..D..@.@.......
	0x0010:  c0a8 00bf 38d6 38d6 0030 20c5 fd1c 0000  ....8.8..0......
	0x0020:  0001 0121 0000 5c29 8cb0 62f6 c8ef 073d  ...!..\)..b....=
	0x0030:  405b 0000 0000 0000 0000 0000 0000 0000  @[..............
	0x0040:  ffff 8f8f                                ....
20:02:03.104488 wlp5s0 Out IP mavic.modem.14550 > beaglebone.modem.14550: UDP, length 17
	0x0000:  4500 002d 43d1 4000 4011 73f9 c0a8 00bf  E..-C.@.@.s.....
	0x0010:  c0a8 00e6 38d6 38d6 0019 b0ea fe09 e9ff  ....8.8.........
	0x0020:  be00 0000 0000 0608 c004 0317 eb         .............

In that above Seb actually used existing bindings into the Mavlink library to create a Rust code which he compiled as per previous post and made it to send fake GPS coordinates.

One major problem was that Rust didn’t come with the UDP stream which would inherit from the generic stream and so he needed to reimplement that to see this working. Even more interesting was that this solution was proposed by the ChatGPT.

use std::io::{self, Write};
use std::net::{UdpSocket, SocketAddr};

pub struct UdpStreamWriteWrapper {
    socket: UdpSocket,
    remote_addr: SocketAddr,
}

impl UdpStreamWriteWrapper {
    pub fn new(local_addr: SocketAddr, remote_addr: SocketAddr) -> io::Result<Self> {
        let socket = UdpSocket::bind(local_addr)?;
        Ok(Self { socket, remote_addr })
    }
}

impl Write for UdpStreamWriteWrapper {
    fn write(&mut self, buf: &[u8]) -> io::Result<usize> {
        self.socket.send_to(buf, &self.remote_addr).map_err(From::from)
    }

    fn flush(&mut self) -> io::Result<()> {
        // UDP is a datagram protocol, so there's no need to flush.
        Ok(())
    }
}

Result is here – as you can see below in upper left corner, QGC running on Seb’s laptop now thinks that BBB provides some initial data and states “Not Ready”, where it was originally saying “Disconnected”.

There is one more where BBB uses Mavlink protocol to provide some hard-coded GPS coordinates and show them on a map (see the red arrow).

Finally all the code landed in our new blimp_control GitHub repository as per below: https://github.com/bbblimp/blimp_control.

Well done Sebi!

In continuation of our previous development as documented here, more and more fiddling was needed. Then, last week, I archived my phone to our long-term storage NAS and ended up with no easy-to-grab pictures left so decided just to do a short post to quickly cover the latest – mostly in points without much context below.

Chris expressed his concerns about ABS as we good material for what we are using it for (clamps) so we used steel garden-hose clamps to make some serious clamp reinforcements.

Having those improved clamps, we finished those traversing beams + there’s been a defect on one of those tubes which needed fixing. They are now ready for a final assembly.

Asked our neighbor (Jane) for few spare tennis-balls, and mounted those on as a padding for suspension legs. Having those completed I took few pictures how that fits straight on our tennis-table (no it wasn’t intentional, that legs span just worked like this by accident).

Final touch came with an initial mounting of the gondola platforms – we picked “Sunlite 8 1.2 x 0.61m Clear Twinwall Polycarbonate Sheet” as it looks nice, is easily available and feels pretty strong.

You can see the front platform already mounted below with BBBlue & Wifi pig-tail & GPS chip placed there for demonstration.

Three more platforms are still needed – rear one for 6V battery pack + two middle ones for those 25V big-battery packs. However that material (Twinwall Polycarbonate Sheet) is easy to work with, so it shouldn’t be a big deal to get it done in next few days.

Thinking about reviving our blimp controls, Sebi unpacked our BBBlue again and had a bit of fun with it convincing it to interact with the Librobotcontrol over Rust.

The Rust code to work with seemed to be simple – just classical ‘Hello world’ enriched with an unsafe call to the librobotcontrol to blink LED #3 with 2Hz for 5s.

use librobotcontrol_sys as lrc;

fn main() {
    println!("Hello, world!");
    unsafe {
        lrc::rc_led_blink(lrc::RC_LED_USR3, 2.0, 5.0);
    }
}

Toml file looked like this:

Cargo.toml:
[package]
name = "blimp_control"
version = "0.1.0"
edition = "2021"

[dependencies]
librobotcontrol-sys = "0.4.0"

While magic came in the Makefile, which looked like this:

makefile:
all:
	cross build --target armv7-unknown-linux-musleabihf

push:
	scp "/home/sebula/code/bbblimp/blimp_control/target/armv7-unknown-linux-musleabihf/debug/blimp_control" debian@192.168.8.1:/home/debian/blimp_control

As you can see above, Sebi is using “cross build –target armv7-unknown-linux-musleabihf” which allows him to cross-compile ARM code on his i686-64bit and then pushes it with SCP to the BBBlue sitting on a Wifi. This is pretty clever as compilation and code editing on a local laptop is much faster than externally the BBB.

This can really save time, Thank you Sebi!

In continuation of our previous development as documented here, clamps were needed. Those are in light-blue (front & back-ones) on following picture.

Design ended up being quite funny kind of a tube-clamp, with some reinforcement on the beam, let’s call it Clamp-A.

A top clamp also needed to be a bit different as there is that front-to-end traversing beam, let’s call it Clamp-B.

Then it took a week to tweak it and print 6x Clamp-A, 2x Clamp-B and start mounting them on.

At some stage of this development the OceanGateTours sub collapsed, what made me thinking about all those thin-walled tubes and how those clamps will hold on … and came with a simple in-fill tube idea to counter those external forces.

That clearly did the job and our vertical tube is holding in there nicely now. Having all clamps printed, we could finish the final assembly and weigh our gondola skelet!

Reading on the above picture is not too good, but it says 1163g.

We should receive more CF tape some time next week and that would allow us to finish those large traversing tubes, then we need clamps to hold our ducts + clamps for gimbals and we’ll be ready to start wiring!

In a follow up on our original article Airships with Craiyon, Seb’s been having fun with another generative artificial intelligence program – Midjourney.

Midjourney is an example of generative AI that can convert natural language prompts into images. It’s only one of many machine learning-based image generators that have emerged of late. Despite that, it has risen to become one of the biggest names in AI alongside DALL-E and Stable Diffusion.

https://www.androidauthority.com/what-is-midjourney-3324590/

… and some of his makings worked out pretty cool. See the gallery below.

#Airship in the Grand Canyon

#Airship over Dystopian city

#Airship in Paris

Let us know if you’ll come with some experiments on your own, it will be cool to expand this article as it goes.

So today we are trying to prepare the main frame to our gondola. The rough idea is sort of like this.

You are seeing rectangular shape formed by CF tubes and corners from 3D printed ABS, while there are clamps to hold three plates. Front for controllers, middle for batteries, which will also serve as balancing the centre of gravity and the rear one for small batteries pack to feed servos.

While constantly working on a good source of tubes, the corner ended up today’s goal. It looks simple but its model evolved through several weeks. Final OpenScad code is below, describing tube-in-tube design from Serge.

use <ShortCuts.scad>
use <tubes.scad>

module corner_tube(simple) {
D(){
union(){
rotate_extrude(convexity = 10, angle=90)
translate([50, 0, 0]) {
D() {
  circle(d = 29.5);
  circle(d = 25.5);
}
if(!simple) {
square([0.8,26.5], center=true);
square([26.5,0.8], center=true);
Rz(45){
square([0.8,26.5], center=true);
square([26.5,0.8], center=true);
}}}
if (!simple)
for( i = [0 : 2] ){
R(90,0,70/3*i+22)
Tx(50)
cylinder(0.8,13.5,13.5);
}

if (!simple)
rotate_extrude(convexity = 10, angle=90)
translate([50, 0, 0]) {
circle(d = 12);
}}

if (!simple)
rotate_extrude(convexity = 10, angle=90)
translate([50, 0, 0]) {
circle(d = 11.2);
}
}}

module leg_tube(simple) {
D() {
T(35.3,35.3,0)
R(20,20,90){
  union() {
    tube(0,0,0,29,14.7,14.7,2);
    tube_enforce(70, simple);
  }
}
rotate_extrude(convexity = 10, angle=92)
  Tx(50)
  circle(d = 29);
}}

module panel() {
D() {
minkowski() {
D() {
T(2,2,-1)
cube([40,40,1]);
Rz(45)
cube([30,30,80], center = true);
}
sphere(0.5);
}
  rotate_extrude(convexity = 10, angle=90)
  Tx(50)
  circle(d = 29);

  //screw hole 1
  T(20,8,-5)Rz(45)
  minkowski() {
  cube([10,0.1,0.1]);
  cylinder(10,1,1);
  }

  //screw hole 2
  T(9,20,-5)Rz(45)
  minkowski() {
  cube([10,0.1,0.1]);
  cylinder(10,1,1);
  }}

  D() {
  minkowski() {
  R(90,0,-135)
  translate([-36,5,-0.5]) linear_extrude(1) {
    polygon(points=[[-5,-5],[20,-5],[-11,20]], paths=[[0,1,2]]);
  }
  sphere(0.5);
  }
  rotate_extrude(convexity = 10, angle=90)
  translate([50, 0, 0]) {
  circle(d = 29.5);
}}}

module corner(simple = false) {
corner_tube(simple);

Tx(50)
Ry(45)Rx(90)
tube_enforce(50, simple);

Ty(50)Rx(-45)Ry(-90)
tube_enforce(50, simple);

leg_tube(simple);
panel();
}
corner(true);

The idea started quite simple.

Printing seemed to be easy, while taking 15hrs+.

As printing came with few problems (walls collapsing), internal frame needed to be added.

Then went completely crazy, trying to make it lighter with internal super-structure + platform clamp.

Here is the final model which implements the tube-in-tube idea from Serge.

Well, then all printing’s been quite adventurous and took few weeks to tune up.

Then we did a final assembly and it is looking pretty cool!

Added a mock-up platform to show how that will look up when complete.

I am happy with the progress, good to see things moving after a while again!

Progressing on our heater story – did a longer test which clearly demonstrated that we don’t have enough power. Simply running a heater for 220V on 60V is not giving enough umpf.

So Serge stepped in and proposed coming back to the plan A – 220V. However first things first little bit of additional grinding was needed. I took a cool video of Serge handling that.

Next stage was to refurbish our heater by rewiring it to 220V.

Quick test revealed that all is working happily. Actually we’ve hit 160C in under 5 minutes.

Wrapped whole tube in Kapton to protect it a bit before inserting it in the external tube.

We carried on with doing a test by using a simple wrapping with 50% overlap, followed by heating it up to 140C and letting it cool down.

Tube extraction was easy and we ended up with pretty nice prototype.

While weighing ~80g it is looking perfect, however I am not convinced about its stiffness as as per my estimates two of these tubes needs to be able to carry a whole gondola.

Anyway, weekend’s goal achieved and it’s a promising start to finally start getting some good progress again!

Finally huge thanks to Serge for his never-ending support!

Having a major success with our BIG tubes, we decided that we’ll prepare tubes for a whole frame. While Serge inclined to use our current technology for the rest, I already had a plan to repeat our production process and get some light and awesome ~25mm ones.

When planning ahead, in February 2023 I reached to Vilem and he checked for us on Aluminum tubes available through his sources. Following options came up:

.. then situation somehow changed and apparently we ended up with these:

The idea here is that we’ll use an inner tube with a heater rod to expand another (external tube), which will be used as a mould for our CF tape, so we have an option to contract it and extract the tube after curing. Vili sourced tubes in a perfect condition.

They are awesome! Thank you Vildo!!!

Then I asked Serge to help us with cutting the external one.

Excellent job Serge, as always. A tiny test shown how cool it is.

Well, that inner tube sit in there too well! Testing this with Serge, he mentioned that once we’ll wrap it with CF, friction will be so high that we won’t be able to pull it out. That would be a not good at all. Checking what’s going on I reached to the Engineering ToolBox – (Resources, Tools and Basic Information for Engineering and Design of Technical Applications) and Serge was right!

The value 1 here is pretty bad (e.g. teflon on teflon is 0.04) – it actually is one of the worst values in that table! Apparently this is because Aluminum surface oxidises very rapidly under the atmospheric conditions, and Al2O3 has quite different properties from elemental Aluminum.

Anyway, there are thoughts how to solve this, but that’s for another day. Let’s move to our new … heater! Serge came with an awesome idea to use a Stove Cooktop Burner Element – straighten it and use it as substitute for our heating coil.

Serge did an excellent job and we ended up with this (first picture next to our Alu tubes):

Running ideas on how to actually use it through Richard, while he raised more then few exclamation marks on connecting this straight into 240V mains.

Crunching this for a while I picked a safe way to use our welder again to power this contraption. Testing it clearly shown that Risa’s worries were well in place.

One last question remained – how to keep our heating rod straight in a middle of our inner tube. Brainstorming it with Serge he suggested some high-temperature silicon. Google then came with JB Weld Muffler Seal, 340g from Super Cheap Auto, which apparently withstand temperatures up to 850F (450C) which we assumed to be enough to do the job.

So we ended up applying this muffler cement in rings on the rod, hoping this will do the job.

Finally we couldn’t resist and connected our welder to see what happens and ended up reaching nice 94C while running it on a lowest settings for about 5 minutes.

We’ve run out of time to wait for cement to cure properly, so a proper test will have to wait for another day. Anyway whole this exercise actually worked out well so I am positive this will do the job and we’ll see some tube prototypes in next few days. Stay tuned!

So we are now trying to build envelope coming with shape around something like this:

As you may see it is quite simple concept of joining two ellipsoids with interlaced cylinder reaching maximum diameter of 2m. So the front part is traditional ellipsoid with w=2.5 (A), followed by a central cylinder w=1 (B), closed by another ellipsoid of w=3 (C). The plan is to buckle in the ellipsoid A so it will all end up being ~6m long.

The idea is to do a 5:1 scaled model and send it to Windreiter guys for review and a quote. To be able to do so, we actually need to draw parts which we can glue together next. Here we’ll be using classical pie/rugby-ball seems method, hoping that it will all work out when inflated.

Having a radius of 1m, maximum circumference comes to 6.28.

C=2πr=2·π·1≈6.28319

Divided by 6 to get height of each part we are getting h=1m. Scaling down 5:1 this is 20cm + 2cm for seem we have the first parameter 22cm.

With the W – part A this is going to be half-ellipse of -> 52cm (scaled 2.5m/5 + 2cm for seems), part B is a simple cylinder of 20cm and part C is -> 62cm (scaled 3m/5 + 2cm for seems).

To get this transformed this onto a paper, I prepared myself a tiny Excell helper (with another help from here). Where X is calculated with =B$2*COS(RADIANS($A5)) and Y =B$1*SIN(RADIANS($A5)).

Ellipse A:

Ellipse B:

Of course we’ll use just a part of those ellipses getting:

And:

Now let’s get practical!

As per our last post we ended up with some kind of mysterious power gain. Having few ideas we’ve been able to rule out all at the point when Richard clearly stated that it is the Venturi effect!

So what’s the Venturi effect again?

The Venturi effect is the reduction in fluid pressure that results when a fluid flows through a constricted section (or choke) of a pipe. The Venturi effect is named after its discoverer, the 18th-century Italian physicist Giovanni Battista Venturi.

Wikipedia

I think that following picture tells even more.

As you can see, it pretty much correlates with what we are experiencing. Input velocity is same, but output one is higher. Well, now how to test this. Richard stated that there is no way to gain whatever energy out of nowhere so with higher velocities we should be also seen higher power demand. And the easiest way to do so is to monitor the input Wattage.

Local Jaycar luckily offers their Mains Power Meter with extendable LCD Display which does exactly that for shabby $34.95.

So we grabbed one!

Then we rebuilt our testing setup, plugging our new power meter in front of our 2kW PSU. Running on idle power meter clearly indicated constant consumption ~8W.

Oli and Sam helped with testing where they were checking on highest measured value. I prepared everything to repeat our tests on EDF only, 1m PU tube and our new 6m CF tube. Also received new set of propellers from Chris and I was hoping to duplicate same test on those, but hit some problems there so I don’t have video of guys measuring and following form is just half-filled, waiting for another opportunity.

Measurements above clearly shows that with higher speeds power consumption was clearly growing. Where we were getting very much 20% gain on the wind speed (17.26m/s -> 20.65m/2), our power requirements were also growing – making it 14% higher power input.

I suppose that this concludes it for now, mystery solved a now to back to building our airship again! 🙂

Of of the main concerns with our new tubes is how they will perform as a duct. Having just our original duct the only way to get any clue was to compare those against each other. How ridiculous it may sound, while different lengths (1m and ~6m) – both tubes still share one essential parameter the inner diameter 60mm.

There is also EDF from our jet-cart project, which can be transferred around and we can use it for comparison together with our old friends – 2kW PSU and high-speed Anemometer.

Test #1

Asking Seb to assist we did a test with original tube first.

As you can see, we removed the vector thruster for now and measured peak at 16.84 m/s.

Test #2

Setting up our new [6m] tube took little bit longer, some cutting and some taping was needed.

Being little bit worried about all that contraption not flying away we did a tiny test run.

All good, now ready to roll.

Well and that is where became quite surprised. As you can see, peak came up to 20.32 m/s! That’s quite a different value to our original measurement of 16.84 m/s. Having same tube diameter, EDF, and power levels – I am more then happy to see 20% power increase, but it also horrifies me that goes completely against our assumptions (expected was 20 – 40% decrease).

I assume that using the Watt-meter might tell us if the higher output observed correlates with higher power consumption, or if we’ve been really somehow able to increase a tube performance. No idea what sort of physics might be behind it, unless tube getting seriously heated by Queensland’s sun.

Any idea, anyone?

Thinking about mechanics of our airship’s keel it is actually one of the most trivial tasks to solve. We’ll be looking to calculate reactions, shear force and bending moment here and then to test it.

Our use-case takes in account our 6-meter-long beam, having two supports in its thirds, where traversing beams will be joined to hold our gondola. Gondola weight is assumed to be ~10kg (100N) and we’ll multiply it by safety factor of 3 getting 300N. Let’s divide this value by four – number of joints – getting 75N per support. To be able to solve this in some easy way, we need to double this value getting nice 150N force in a middle.

So let’s go with bit of theoretical calculations on this first. The easiest way to do this these days is to use e.g. Free Online Beam Calculator, which I like a lot as it is making this task trivial.

Reactions

Force Extremes

Nothing too much to see yet, so let’s have a look at bending moment and sheer forces

The last one is the deflection, which (if we would provide actual tube properties) would finally provide us with a some actual values to test for. Graph below uses Young’s Modulus (E) 200000 MPa, which is clearly too high for our use-case, but as we don’t have any good value here we’ll be using it for demonstration.

Now to our actual testing – two chairs serve as a support there, supporting our tube in its thirds. Pillows and cloth in the middle serves to distribute forces bit around so those are not “too pointy”. Below you can see a set of weights totaling 15kg provided by Andrew.

Tube #1 (950g)

Long story short all holding! A minor tube bending’s been noticed, but overall whole tube seemed to be very firm and stable.

Tube #2 (850g)

Again – all holding! 15kg load and tube seems to be stable. Even on the final picture you can’t see any bending whatsoever there.

As you can see Jan being happy – whole this exercise ended up with a huge success, making whole team confident that our tubes will perform well with a 3-fold safety margin.

As always, ping us back with whatever comments and congratulations to the whole team for excellent work!

Just a quick post to announce that our new baby (CF tube to serve as a main duct for our drone) comes out being 6.10m long and weighing just 956 grams only!

++ few initial pics as evidence.

Working on our “tubes” project at some stage someone (I think it was Byron) mentioned the “Fail fast, fail often” mantra. Well, the last weekend ended up following this slogan to the last bit! Still, preparing for this post it came to me checking on what it actually means and ended up reading few articles on this.

“Fail fast, fail often,” as a mantra has seen some success. SpaceX comes to mind. But “fail fast, fail often” has been around for years. Thomas Edison, by example, “failed” 9,000 times before he was successful with his light bulb invention.

Dan Pontefract (Forbes)

I picked the quote above as it resonated with me well – we failed too many times over the weekend! 😀

Plan B (Friday)

Based on our a new plan (see the end of our previous article) Serge and I tested 150C curing with single CF strip – two wraps, to check if we’ll be able to take it away when mold cools down.

We ended up preparing 20g of resin mixture (4g harderner + 16g resin).

All resin work started going much faster now when we know what to do. Demolding spray -> CF bath -> wrap -> white tape -> office tape. 15 minutes later all ready to heat up.

Keeping it for 20 minutes at 150C and wrapped seemed enough for our purpose so we let it cool down and unwrapped it.

Anyway, even cooling it down under water and using ice didn’t help and we needed to cut the tube to remove it from the mold again. There were not even signs that it would go off peacefully. Serge then used leftover resin to glue it in a tube again and we left it overnight to cure as is.

That did actually pretty well and we were able to see some mechanical stability being demonstrated for a first time.

Plan B+ (Saturday)

Before moving to a Plan C (splitting the tube) the idea came in that our demoulding spray might not be the best for our use case, so decided to re-run Plan B with our original TR mold release wax.

Eight layers later – tube mold looked like coming straight from Madame Tussauds museum. Serge needed to leave so Seb stepped in as the main assistant.

He seemed to actually have some good fun about it.

.. but it failed again. Even with X layers of mould-release wax – all still the same, it won’t release and we ended up cutting it again.

Plan C (Sunday)

Becoming reasonably desperate, I decided to go with the Plan C – cutting the tube. Not having Serge around to come with some better idea and being pretty upset after all those set-backs, it actually felt pretty relaxing to start manually splitting that two meter-long tube in half (Chris’s idea of split tubes modified by me to be doable in our environment).

It took one hour to chew through that pipe. It was far from being perfect, but also could look worse. Using caliper it was clear that there are probably 2-4 mm missing now on circumference, while those two halves flexed nicely.

I also prepare a jig to keep those halves split away to get additional gap which can be used afterwards to assist another demoulding attempt.

We used Kapton tape to bridge the gap on tube and Seb helped with another wrapping & heating round.

… and after all those failures, we finally had a nice tube. Short one, with imperfections, but it was a tube!

Plan C+ (Sunday night)

Finally seeing a way forward we instantly started preparing to demonstrate how to manufacture longer tube and took this opportunity to show how tube joining will work as well. Seeing how our mold flexes on longer distance, I decided to prepare new spacer which will fit between those halves.

We have that tube preparation already pretty much mastered and stopping in a middle and joining afterwards didn’t seem to be a big deal.

Seb then removed spacer-rods and after bit of wrestling – it worked out!

Final tube came out being roughly 65cm long and weighing 74 grams, which still fits into our plan.

I tried to demonstrate its stiffness on following video.

As you can see, that worked out very well! As always there are few things to improve, but there is a good potential that we’ll be really able to produce some decent tubes here!

Thanks for reading and don’t forget to leave us your comments & ideas as always!

We couldn’t resist with Serge and did another session to release the tube of the mandrel. Following the plan we started with filling the tube with ice to check if it’s going to do the job.

It is not that obvious on those pictures above, but it seems to be cracking, it did nothing.

We’ve resented to the plan B – using a brute force and cut it off.

It didn’t go well and took us probably 10 minutes to do so and while we made it, our Aluminium tube suffered some serious scratches.

On the other hand, holding our first tube attempt was pretty satisfying and it clearly has some parameters we are looking for. We agreed that if we’ll be able to take it off the mold properly, it is likely that it’s going to do the job.

Anyway, it was time to check at least some parameters.

As you can see on pictures above, we ended up very close to producing one meter tube weighing 135g. When we take weight of CF tape used ~ 94g it comes with 70:30 CF to resin ratio – which is apparently very good. Next stage would be vacuum bagging where it is possible to reach 75:25, still very close!

In preparation for our next stage we made another trip to ACME Composites and finally got our Resin and HTG Hardener.

Thinking about how to get ready for another go, we formed a new plan:

1/ Test 150C curing with single CF strip – two wraps and check if we’ll be able to take it away when mold cools down

2/ If it won’t we’ll use ice

3/ If it’s going to work out we’ll continue and will try to do 30 cm strip keeping enough tape to potentially continue

4/ Assuming that 3/ worked out – we’ll try to continue and do another 30 cm and so on

5/ In case we won’t be able to continue, or that joint won’t work we’ll cut it of and do another – separate 30cm tube and try to join them together with overlap

6/ If everything fails we have a plan B – Chris came with a plan to split our tube in half to create a gap or space which could be used to release the tube when curing finished

Going through our latest obstacle – releasing our CF tube off the Aluminium mandrel – it made me to do some thinking and recap some calculations on what should we actually expect in this field.

So let’s start with Wikipedia again – Aluminium’s Thermal expansion coefficient (CTE) (α) comes as 23.1 ×10-6/°C

Now, our Al tube comes with 60mm in diameter, which makes our initial circumference of 3.14 * 60 -> 188.4 mm.

Case #1: ΔT – 40C

Our initial test was reaching max 70 C for 90 minutes. While starting on beautiful Queensland summer’s 30 C, that makes our total temperature change (ΔT) of 40C. Using our tube’s diameter, AL CTE and delta we get the circumference change.

188.4×0.0000231×40 -> additional 0.1740816 mm (174 μm) to our original circumference value

Going back to our diameter

188.5740816÷3.14 -> 60.0554 mm

Just for reference, Hair’s breadth comes ranging anywhere from 17 μm to 181 μm [millionths of a meter] – yep, it would be very thin hair gap there!

Case #2: ΔT – 70C

While case #1 temperature change (ΔT) was 40 C, because of Queensland, we’ll now improve our chances by reducing the base line to 0 C. That ramps up our total temperature change (ΔT) of 70 C. In this case we’ll get following change.

188.4×0.0000231×70 -> additional 0.3046428 mm (304 μm) to our original circumference value

Going back to our diameter

188.7046428÷3.14 -> 60.09702 mm

Coming back to our hair’s breadth comparison, we are still within a limit of a single hair (17 μm to 181 μm) here.

Case #3: ΔT – 150C

Let’s go wild and aim for our final ΔT of 150 C. This is going to be achieved by heating our mold to 150 C, while cooling it to 0 C afterwards with a common ice.

188.4×0.0000231×150 -> additional 0.652806 mm (652 μm) to our original circumference value

Going back to our original diameter again

189.052906÷3.14 -> 60.2079 mm

Doing our final hair’s breadth comparison – we finally made it over the single hair (17 μm to 181 μm) limit here – let’s be humble and say we’ll have “two hairs” space there. Would it be enough? No idea.

As per our Day 1 Seb wasn’t available (Sunday rock-climbing training) so I asked Greg to assist us and we started with planning first.

While probably even more cryptic then the one from previous day, decoded it comes like this:

1. Apply the demolding spray
2. Weigh all CF so we can calculate amount of resin mixture needed
3. Check if anyone has any urgent needs now (restroom visit)!
4. Check all tapes are ready
5. Calculate resin needs
6. Prepare resin mixture (wet-job timer starts here)
7. Apply 1st layer – this is probably one major change to our original plan. Serge came with idea that having a first layer wet will do well as excess resin will be soaked by the second one.
8. Apply 2nd layer – this one comes as a dry one
9. White tape with 50% overlap
10. Office 80%-90% overlap to squeeze the job even more (wet part of our job finishes)

Job started with the demolding spray application. Serge places several markers there so we won’t miss a spot.

The next in the line was the CF weighing which worked out being roughly 47g per layer.

Based on this value we decided to prepare 150g of resin mixture in a 1:3 ratio (1 part of hardener on 3 parts of resin). Then we hit quite an interesting & unexpected obstacle just before getting it mixed – I’ve been recommended to use Nitrile gloves – but how the heck do you put them on in ~30C heat-wave?

Mixing resin was easy with scales – 37g of hardener + top up to 150g with resin. Our wet-job timer started here!!

The next stage was to make sure that all CF is getting wet properly.

On to laying the first (wet) layer + Serge using squeegee to spread resin evenly on top.

Straight to the second (dry) one.

White tape! (~10 minutes in). Here you can see that we ended up with few “white” patches where tape seems not to be having enough resin. This will be visible even more later, but raising it here as it became apparent for the first time (pretty early in process). It is likely that we still had a good chance to add some resin to fix this at this stage.

… and yes, final layer with the office tape!

Done! All in roughly 15 minutes!

At this stage we found ourselves in an interesting situation – what should we do next? As we couldn’t get the actual resin I’ve been looking for we ended up with a more traditional one which sort of even doesn’t require any heat-assisted curing. It can cure on its own though several days. Another question here was when should we expect that curing process to start as being almost an hour in the “wet” job, while mixture’s viscosity was still – honey-ish.

We left an excess resin in a jar so we can oversee that actual curing process and it actually all happened in a matter of minutes … right just when team (Serge & Greg) left. Resin temperature suddenly spiked to 90C+ and I couldn’t pinch its surface anymore.

Seb then had a quite a fun testing it – and we were quite amazed that he needed to use a hammer to actually smash it.

Discussing it further with Serge we decided to test the high-temperature (70C) curing on it as well. And so we did!

Heater needed to be injected in the wider tube again and we wrapped whole contraption in a thermal insulation to reduce the heat dissipation. Strangely contact of our temperature probe with that aluminium foil seemed to confuse readings again so I decided to cutout a bit to avoid any. That also opened way how to cross-measure temperature with our IR thermometer.

Richard’s heater & Seb’s monitoring system did the job and together with a bit of manual overload we’ve been able to keep pretty stable 70C for 90 minutes.

Giving it another hour to cool down – we started removing the white-tape wrap. It was strangely satisfying experience seeing how it is coming out.

At the end I took few pictures of that texture – it looked perfect!

Well and here we are! We apparently have an awesome CF tube ready, but I don’t seem to know any way to get it from the mold! Not like it would be glued to the Al tube, but it is so tight that it is clear that stripping it away will be difficult to the point where I am already quite negative that it will work out.

Anyway, there is still a chance that our Al tube expansion wasn’t big enough as we were using different resin than intended for our final go (150C). We should also consider using even more of that de-moulding spray, probably in multiple layers (4+) – one by one when they get dry.

Finally, there is that problem with CF not being properly wet on few places. That needs to be something we need to watch after next time.

Otherwise, I think this was an amazing job for our first go! When around and having some ideas, please leave us those in comments, as always more brains comes handy.

What a weekend! Huge thanks to whole team first (Serge, Greg, Seb, Richard & Chris … and more) – because we made it! There were so many things happening both days that I decided to split it in two (still pretty chunky) posts.

We started with Serge about 2pm Saturday with forming a plan!

While not readable well, it sort of goes like this:

1. Clear the tube
2. Build a resin applicator
3. Apply release film
4. 1st carbon fiber (CF) wrap & seal ends
5. 2nd carbon fiber (CF) wrap & seal ends
6. 3rd layer resin protection tape
7. Weigh CF tape + measure time for the wet-works (just a note)

While Serge started working on the resin dispenser, work progressed in parallel on clearing the tube. That’s important so resin has limited grip on it and releases the mold with ease. For this I ended up using Septone Ali Brite Aluminium Cleaner 1 Litre from Good Guys, what ended up being a wrong decision.

While this product seems being recommended all over the shop, it didn’t deliver – our aluminium tube still being scratched and dirty even after 5 minutes of polishing. Serge came straight with a better solution – bringing in a green sponge for washing dishes & dishwashing paste – and it came with an instant results. Still doing this properly took us probably 30 minutes.

Meanwhile Serge built the resin dispenser by reusing old squeegee and Loaf Pan from K-Mart.

Final picture TBA.

The next step was to apply the release film – ULTRALEASE EPX PARFILM MOULD RELEASE from Barnes, however we decided not to do it and leave this step for the wet run.

Apply the 1st CF layer next – Serge realized that ends of our CF tape needs to be taped so they keep together, also found that picking up a right angle how to apply the tape might be bit tricky.

Apply 2nd CF layer – that already went much easier together. That also came with some of our first measurements, it looks like we need ~2 meters of tape per layer.

3rd layer resin protection tape on top

We repeated whole procedure twice to be sure we are well orchestrated and all is at hand when needed. That came with few notes:

• Use a squeegee to tighten up the first layer – it gets wrinkly when not tighten up properly
• Applying second CF layer + protection tape took roughly 4 minutes, which should leave us enough time (assumed “pot” time at this moment was 10 -15minutes
• Tapes! Tiny, long, narrow, fat … they need to be readied in advance and in a good quantities (it is difficult to get any when working in gloves)
• Resin protection layer to come with 50% overlap, another office-tape layer to be considered
• Hand-operated lever to spin the tube actually works pretty well. With the CF tape width of 10cm, it still goes pretty well and allows niche control when things go not-that-well.

That wraps it that up for Day 1, let’s get ready for Day 2!

Starting to picking up a Resin in one of our previous articles, we ended up engaged in a discussion with a local Resin supplier – Acme Composite Supplies. You can see their reviews on a Google below and I have to agree. In a situation where guys coming in with an idea of building a new Hindenburg – they’ve been very open to help – from very beginning.

Unfortunately their experience with high-temperature curing was limited, so their preference was to use resin with curing cycle temperature up to 70C. Unfortunately that would potentially come with some manufacturing issues on a horizon such, where we were counting on our Aluminium tube/mold expansion at 150C to assist us with decoupling. That tube expansion is also there to counteract external forces (tape) to serve us on behalf of missing autoclave processing.

So the option left in their offer was to use PRIME^TM 37 RESIN & PRIME™ HIGH TG HARDENER from Gurit.

Mechanical properties

Hoping that, when everything going well, we should get mechanical properties somehow close to following values (using two-plies of uni-directional Carbon Fiber instead of 4 plies of XE600 biaxial e-glass):

Comparing it with other resin / hardeners combination, this one provides roughly 5-10% better values across all properties see PRIME^TM 37 RESIN & AMPREG 3X FAST HARDENER below.

Curing time

While the mold handling (Aluminium tube decoupling process due to temperature change) is the important one, pretty much same importance comes with the curing time, which is with our selection shortened from 10+ hours to a single hour. That should potentially allow us to streamline pipe production.

Viscosity

The last bit to solve here was the initial system viscosity. There were some concerns that HTC solution will have very low viscosity so it won’t stick on our CF tape. Comparing a mixture viscosity for PRIMETM 37 RESIN & AMPREG 3X FAST HARDENER – 375 at 30C – with our selection – 210-230 at 30C, indicates that it will be really more “running” than what guys at Acme Composite Supplies are used to.

Just to understand what we’ll be facing here, I did a tiny excursion to Wikipedia to check how that compares. Apparently viscosity of water at 20C equals 1, while our expectation of 210 – 230 throws us probably to the “Sour cream” region. For others see the table below.

Implications? No idea. Let’s get surprised! … unless getting a big pack of Nitrile gloves before it will all get pretty messy. 😀

Apparently there are many awesome ways to use today’s most evolved AI – ChatGPT. Clearly the most obvious one is to ask it to write a poem about rigid airships!

(Adding it also in a text form here so web crawlers can grab it.)

Poem about rigid airships

Rigid airships, floating in the sky,
A marvel of engineering, soaring high.
With gasbags filled with lighter-than-air gas,
They glide through the heavens. faster than a mass.

Their rigid frames, a wonder to behold,
Defying gravity, a story to be told.
A mode of transport, in a time long gone.
Their memory lives on, with each rising dawn.

In the early 20th century, they ruled the skies,
Luxury liners, carrying people with great size.
From Europe to America, a journey so grand,
Their mighty presence, a sight to stand.

But their time was brief, as planes soon took flight,
Making airships obsolete, out of sight.
Yet they still inspire, a symbol of grace,
And their legacy lives on, in each new space.

So here's to the rigid airships of old,
A testament to human ambition, so bold.
Their spirit lives on, in the skies above,
A symbol of our dreams, of peace, and love.

Credited to ChatGPT.

In continuation of our work on TEMPERATURE MONITORING FOR TUBE CURING CYCLE we needed to get back to Richard to help us out. That however ended up in quite a major overhaul where I’ll cite Richard “I needed to throw it away and built it from scratch”.

Discussing it with Richard, apparently we plugged the original model in a wrong direction, which caused overheating, which lead to a damage to some electronic parts. At the picture above you can see Richard’s instructions in a way to make our next attempt bullet-prrof.

Still, to avoid any potential overheating problems, Richard replaced original IRFP90N20DPBF – MOSFET N-CH 200V 94A TO247AC with IRFP4668PBFF – MOSFET N-CH 200V 130A TO247AC.

To get little bit in a detail on that – that original MOSFET came with resistance 8 milliohms, while the new one has 23 milliohms. This translates to 3W radiated at 20A for the first one (we have three MOSFETS connected in parallel), which is greatly reduced to 1W in our new setup.

Huge thanks to Richard for preparing this for us!!

We’ve been rushing home to plug it in. while Richard’s instructions were to test it with our Power supply unit first.

Test 1/ There should be minimum resistance when in “open” state – tick. Showing 3 milliohms actually very much correlates with expected value (7.6 milliohms). As per comment from Adam in our previous post – these multimeters are not that accurate when getting to very low values.

Test 2/ Maximum resistance when in “closed” state – here we’ve been getting range of very high values, starting with multiples of hundred ohms and going all the way up to out-of-limit. Richard said that we should be seeing just “out-of-limits”, but well, I assume this should be ok.

Test 3/ Heat generated on those MOSFETS. Running a load of 1A and 12V through these – we couldn’t observe any temperature increase at all. Seriously cool stuff Richard!

Next stage was to hook this up to our heater and Arduino wit temperature probe.

This was the moment where we hit the wall! Apparently our coil-heater creates an electromagnetic field which interferes with our temperature probe and kills its signal.

Seeing this – it pretty much ruined my day. First idea was to replace our thermal probe with an infrared sensor, but that would clearly delay our plan to move on with this thing. I texted Richard and Chris about this and surprisingly Chris came with an awesome (and obvious) solution to this – just measure temperature only when not running current through the coil! So easy and so cool! Thank you Chris.

It took Seb minute to update Arduino code to do the job. Pasting it below without much details as it is pretty much self-explanatory.

#include "max6675.h"

const int dPin = 2;

int thermoDO = 4;
int thermoCS = 5;
int thermoCLK = 6;

MAX6675 thermocouple(thermoCLK, thermoCS, thermoDO);

float realTemp;
float inputTemp;

void setup() {
  Serial.begin(9600);
  pinMode(dPin, OUTPUT);
  pinMode(12, OUTPUT);
  digitalWrite(dPin, LOW);
  digitalWrite(12, LOW);
  // wait for MAX chip to stabilize
  delay(500);
  realTemp = thermocouple.readCelsius();

}

const int low = 0;
const int high = 5;

const int range = 5;

void loop() {
  static int onTime = 0;

  inputTemp = mapfloat(analogRead(A0), 0, 900, 20, 150);

  onTime = map(inputTemp - realTemp, -1, range, low, high);
  Serial.print("Top: 70, Bottom: 20, ");
  Serial.print("RealTemp: ");
  Serial.print(realTemp);
  Serial.print(", ");
  Serial.print("InputTemp: ");
  Serial.println(inputTemp);

  if (onTime <= 0) {
    delay(200*high);
    realTemp = thermocouple.readCelsius();
    return;
  }

  if (onTime >= 5)
    onTime = 5;

  digitalWrite(dPin, HIGH);
  delay(100*onTime);
  digitalWrite(dPin, LOW);
  delay(100*(high-onTime));
  digitalWrite(dPin, LOW);
  delay(50*high);  
  realTemp = thermocouple.readCelsius();
  delay(50*high);
}

float mapfloat(long x, long in_min, long in_max, long out_min, long out_max) {
  return (float)(x - in_min) * (out_max - out_min) / (float)(in_max - in_min) + out_min;
}

We still had to go through few obstacles, but initial testing worked out satisfactory and while initially overshooting temperature with 3C it seems to be behaving very well. Following graph comes from Arduino plotter and shows how our contraption has been able to heat up to predefined temperature and then sustain it.

This will probably still need some thinking (no idea why that temperature is above the target line), but is is already something we should be able to work with.

Another tiny experiment also demonstrated that that temperature level is quite easy to sustain, so probably wrapping our tube in an thermal insulation will assist us to distribute all that heat evenly and very little energy will be needed to sustain it.

We are almost there guys! Thank you all for your support and adding a tiny TODO list with what to expect next weekend:

• Getting the high-temperature Epoxy Resin (should arrive Friday)
• Polish our aluminium tube to support the demolding process
• Dry test and as we should finally have all components ready -Wet test!!!

As secretly hoping to use our carbon fiber parts as a common ground for overall power distribution, I thought it would be good to actually measure how it is doing in a context of our other options. The plan is to measure the material resistance and voltage drop for copper wire, aluminium bar and our CF tape on 1 m of material.

Copper

Our first testing subject is 25A 2 Core Tinned DC Power Cable from Jaycar.

Running it through a nice cable calculator, we should be seeing following readings – expected resistance to be 5.8 micro-ohms.

Now to our actual measurement.

Well, we measured 0.3 ohm. That doesn’t seem to be correct as this would be 100 times higher value than what calculator shows. Voltage drop was 5.87 mV.

Aluminium

Our second testing subject is Metal Mate 20 x 1.6mm 1m Aluminium Flat Bar from Bunnings warehouse.

Running it through our nice cable calculator again, we should be seeing following readings – expected resistance to be 0.8281 micro-ohms.

Now to our actual measurement.

Well, we measured 0.4 ohm. That doesn’t seem to be correct as this would be again 50 times higher value than what calculator shows. Voltage drop was 0.6 mV. This value is lower than with copper as we have more much more cross-section area here (10 times more).

Carbon Fibre tape

Our last testing subject is 12k 200gsm 4″/10cm width Carbon Fiber Uni-directional Cloth UD Fabric Tap High strength Repair material Tensile strength 3400Mpa from AliExpress.

Unfortunately our calculator doesn’t know Carbon Fibre material, but as it didn’t help much for that copper and aluminium before we’ll just go ahead. Seb prepared aluminium clamps so we have something to connect to.

First reading came with 8 ohms resistance, what seems to be roughly 20 times higher value than for the others. As were trying to measure the voltage drop, we needed to put weights on those clamps to improve connectivity. Still, we measured quite high 1.2V drop just on that 1 meter!

So putting it all in a table:

Honestly I am not sure what to make out of this. Does this still qualify to be used as our common ground? I suppose someone with more insight into electricity needs to have a look. It is not a big deal if this is not ok, but we’ll have to count with additional weight for doubling our power cables.

Update from Richard 2023/1/23

You can connect it to GND, but you can’t use it for electrical GND for return currents. So you really want to be using:

P=I^2R
So if 2A flows P=32W

Update from Chris 2023/1/23

Resistance is different in different directions on carbon fiber as well – and almost none between layers. CF threads are “wet” with a chemical which helps the resin absorb – if you’re wealth enough to grow carbon nanotubes on the CF to use as the wetting agent, you then get excellent conductivity in all directions.

Or the opposite of that technology – when you don’t use nanotubes, conductivity is poor. Multi-Functional Carbon Fibre Composites using Carbon Nanotubes as an Alternative to Polymer Sizing – what’s the ground for? If it’s the high-current for the motors, perhaps some copper tape laid along with the fibers when you make the tubes like below?

There’s been also big comment from Adam, see in comments below.

Thank you guys!

Carbon fiber tube curing process, we are working at, needs to go through several stages. First one is to hold temperature on 70C for ~3hrs, followed by another 1.5h on 140C. To be able to achieve that, we needed to put together some sort of thermostat which would drive our heater.

Discussing this problem all around, Richard suggested to build our own and provided list of parts needed.

So we got ourselves one MAX6675 K-type Thermocouple Temperature Sensor 0-600 Degrees Module Arduino – mainly to grab its signal amplifier.

Followed by AU Heat-resistant K Type Stainless Steel Thermocouple Sensor Probe Meter (1m) as it comes with pretty impressive operating temperature range: -100 – 700°C.

Both packages arrived quickly (days).

It took Seb to hook it up to one his Arduino.

Sebi provided me with a code, claiming that that’s just a copy & paste from some thermocouple example. I am putting it here for reference, while all credits go to Adafruit guys.

// this example is public domain. enjoy!
// https://learn.adafruit.com/thermocouple/

#include "max6675.h"

int thermoDO = 4;
int thermoCS = 5;
int thermoCLK = 6;

MAX6675 thermocouple(thermoCLK, thermoCS, thermoDO);

void setup() {
  Serial.begin(9600);

  Serial.println("MAX6675 test");
  // wait for MAX chip to stabilize
  delay(500);
}

void loop() {
  // basic readout test, just print the current temp

  Serial.println(thermocouple.readCelsius());

  // For the MAX6675 to update, you must delay AT LEAST 250ms between reads!
  delay(1000);
}

Finally we took a tiny video to see it all working together – showing data from Seb’s Arduino being received by a plotter on his laptop responding nicely to temperature changes.

Afterwards we did some attempts to hook it up with Richard’s MosFETs to drive our heating coil, but that didn’t work out well, so keeping it for another post as there is quite a live discussion running around it right now.

Also there is a question of an actual driving of our heater as it will certainly react with some delay following the hysteresis curve, but that’s for another day as well.

In continuation of our Tubes story, we’ve hit several delays and proper celebration of New Year 2023 was one of them. However there were others…

Adapter jig

Initial plan was to have both tubes (50mm and 60mm) as one component and do all tube cladding like that. Seeing how potentially fragile is that heater made me rethink further steps. I assumed that would be much better to do all preparatory works on that 60mm tube only and use the internal heater when needed only. This obviously called for a new set of jigs to allow our thick tube handling.

Practically that meant to develop an adapter which would allow to extend our 60mm tube and plug it into our 50mm wall mount. Bit of OpenSCAD design and couple days of printing worked out nicely.

Wall mount upgrade

Another obstacle appeared when testing the heater. Our current wall-mount made out of ABS didn’t give me enough confidence that it will withstand whole working cycle reaching 150C for 90 minutes. It actually seemed like it started loosing its internal integrity anyway.

Using the graph from arpnjournals below, it is obvious that we can rely on ABS on up to 110C only.

Thinking about which material to pick instead and how to actually make it happen, Serge appeared and offered his help.

A day later we ended up having new wall mounts. 🙂

Material – TR-102 REGULAR PASTE WAX

Checking on all material, we’ve been able to get our hands on, there were few interesting bits. The first one was a mold decoupling wax. Looking around it worked out that the best fix will be for TR-102 REGULAR PASTE WAX from Barnes Australia.

It arrived in an excellent condition – thanks to our sponsor Tam!

Material – Carbon Fiber tape

Next part was to get our hands on a Carbon Fiber tape. I’ve ended up picking 12k 200gsm 4″/10cm width Carbon Fiber Uni-directional Cloth UD Fabric Tap High strength Repair material Tensile strength 3400Mpa. Thinking about it a bit later, I should probably pick bidirectional woven instead, but well we need to start at somewhere.

As before, it arrived in an excellent condition, couple weeks later.

I’ll leave you here so this post doesn’t go forever, but here is a tiny TODO list what to expect next:

• Getting a high-temperature Epoxy Resin
• Develop thermal control system for our heater
• Apply first layers of decoupling wax at our molding tube

See you soon!

Bit late, but well, airships don’t need to rush – why to be fast, when you can enjoy being slow. 🙂

This is a continuation of the Back to Tubes – Mounts and Adaptors article. Here we’ll finally focus on real action when wiring the heater tube and finally doing some initial testing.

In preparation of the heater tube winding, I first did a review of all the material we’ll need.

The most important part of this ended up to be a set of heat resistant 11 AWG cables, so we can lead them from inside of the tube. (This is actually why our previous attempt couple weeks back failed right at beginning.)

Drilling holes in our 50′ aluminium pipe was the first step, followed by initial wiring and cable insulation.

The next stage was where all the fun started and we needed Serge and Seb! Unfortunately I haven’t been able to take a video of that initial tube winding, but we ended up multiple runs when re-aligning these threads, which I’ve been able to document.

Making that thread consistent ended up being quite tricky and after several attempts Seb came with a classical hair brush which did the best.

Still I took more than few pictures from all that process.

Final step was to test it all.

We took temperature and width measurements and it all worked out. Serge thinks that that tube expanded roughly 3 paper widths.

Finally we ended up having a visitor – Paul, who participated by supervising whole session and came with a way to measure tube temperature through the paper as it was reflecting the thermometer laser. 🙂

Well, all done for now. Seb is still preparing a jig which would allow us to control heater’s duty cycle, but that will be for another article again.

This is a continuation of the Back to Tubes – Theory & Shopping article. Here we’ll focus on some CAD design and 3D printing.

To be able to do all wire & tape winding on a tube we ended up with a need of several gadgets / jigs, namely wall mount, vise mount, levers and mount adaptors. Wall mount and the vise mount was in place already and seemingly holding ok.

While using an electric drill later in videos, we also prepared a lever with a handle.

OpenSCAD handle code here:

//Lever
module lever() {
  D() {      
    union() {
      //main body
      D() {
        union() {
          Tx(75)
          cube([146, 56, 16], center=true);
          cylinder(16, 28, 28, center = true);
        }    
        T(148.4, 506,0)
        cylinder(21, 500, 500, center = true, $fn = 1000);
        T(148.4,-506,0)
        cylinder(21, 500, 500, center = true, $fn = 1000);
      }
      //small ring
      Tx(150)
      cylinder(16, 10, 10, center = true);
      }
    //Main hole
    cylinder(21, 24.5, 25.5, center = true);
    //Small hole
    Tx(150)
    cylinder(21, 8, 8, center = true);
  }
}

//Handle
module handle() {
  D() {
    union() {
      T(150,0,50)
      cylinder(100, 8, 8, center = true);
      T(150,0,10)
      cylinder(2, 10, 8, center = true);
      T(150,0,100)
      cylinder(2, 15, 15, center = true);
    }
    //central hole
    Tx(150)
    cylinder(210, 6.8, 6.8, center = true);
  }
  
  //reinforcement
  T(150,0,50)
  cube([1.3, 14, 100], center = true);
  T(150,0,50)
  cube([14, 1.3, 100], center = true);
}
  
lever();
handle();

Final product worked out nicely.

Final missing part was a set of tube adaptors (60 -> 70mm) so we can reuse mounts we have for a wider tube. (I made it probably little more fancier than it needed to be, but it is sometimes difficult to hold back. 😉 )

OpenSCAD adaptor code here:

module big_tube_adapter() {
  D() {
    union() {
      cylinder(180, 25, 25);
      Tz(140)
        cylinder(40, 27.1, 27.1);
      Tz(40)
        cylinder(100, 27, 29);
    }
    Tz(-1)
    cylinder(182, 23, 25);

    Clamps = 4;
    for (i = [0:1:Clamps]) {
      R(0,0,i*(360/Clamps)+45)
      T(0,70,90)
      scale([0.3,1.3,1.2])
      sphere(50);
    }
  
  }
  
  //reinforcement
  T(0,0,90)
  cube([1.6, 50, 180], center = true);
  T(0,0,90)
  cube([50, 1.6, 180], center = true);
}

big_tube_adapter();

Slicing in Cura:

Final product:

Well, that wraps it up for this post, next one will be finally some action about wiring and testing.

This article is a follow up on our previous tube development covered here, here and here.

I had to remind myself on what we are trying to achieve here a bit and rethink it again. So for our actual project we need to develop a tube which will serve as a central duct and airship keel. It has to be ~6m long, roughly 6-7cm diameter, super-strong and also super-light. Yes, whole tube needs to be under 1kg to make it working, even better under 800 grams.

The idea is to end up with a scale-able jig which will allow us to produce continuous tube without a need to do some vacuum bagging or autoclave usage.

I made a simple draft on how that’s plan to work out.

So reading it sort of left to right there are two main parts, heater and mold pipe. For a heater we’ll get an 50′ aluminium tube, wrap it in Kapton tape, wind it in 18AWG 80m wire and apply two more Kapton tape layers.

Second part starts with another aluminium tube, now 60′ which will serve for the heat distribution and molding. First layer will be actually a set of decoupling wax layers (6) followed by a first carbon tape (200gms) clockwise winding, hand-applied resin, second carbon tape layer (200gms) counter-clockwise, finishing with very thick layer of office tape (1mm thread) to squeeze out excessive resin and air.

When done, the plan is to achieve a curing plan when on 3 Hours at 25˚C plus 2 Hours At 155˚C and attempt get tube parameters around as described in article Effect of Thermal Exposure on Residual Properties of Wet Layup Carbon Fiber Reinforced Epoxy Composites.

Translated in a table from here it practically says that we need to shoot for 90 minutes curing at 150C.

Percentage Change in Characteristics.

Shopping

In preparations we needed to do some additional shopping first. First thing on my list was a demoulding wax. Picked the best out of the best (and probably also the most expensive) TR-102 REGULAR PASTE WAX from Barnes.

Well, why not to get the best, when we have such a generous sponsors like Tam (huge thanks Tamara)!

Second essential was to order a Carbon Fiber tape – after some serious thinking, we ended up with 12k 200gsm 4″/10cm width Carbon Fiber Uni-directional Cloth UD Fabric Tap High strength Repair material Tensile strength 3400Mpa. It is on its way.

The final missing part is Epoxy, this is still to be decided on which one to use, secretly hoping to get our hands on EPOXY RESIN 4 HIGH TEMPERATURE FIBERGLASSING & CARBON FIBER PREPREG RESIN 80 as it seems to be perfectly what we need.

Next on the list is some CAD design and 3D printing as we need jigs to hold our tubes and operate them in general. I am splitting it into another post so it remains readable.

Thanks to Sebi, we’ve got some new 45A ESCs, which looks awesome.

While replacing the old ones, which burned out, it let us thinking about why we are actually getting so many burned out ESCs? Sometimes those burn without any actual load, just connecting them to a battery is enough to get a “smoke” situation.

Discussing this with Richard he suggested to implement a power soft-start design to reduce initial kick (inrush current) to those electronic components. THE ULTIMATE GUIDE TO SOFT START DESIGN article provides detailed description of this problem, including several options on how to address it.

The basic solution to this is trivially simple – limit the inrush current by adding a power resistor in series with the load primary.

Which very much correlates with Richard’s version (recommending to use 10 Ohm 5 Watt Wire Wound Resistor):

Intention here is to achieve something like on a the measurement below – reducing those current spikes to a level where our 100A battery won’t cause any harm.

After the inception phase, our project started with some decent shopping.

1 x 10 Ohm 5 Watt Wire Wound Resistor

2x DPDT IP56 Heavy Duty Toggle Switch

… well and to be little bit fancier – a Missile Switch Protective Cover!

We also couldn’t avoid bit of 3D design & printing for the switch case.

Finally, it’s just about putting it all together.

Final assembly done!

I had a chat with Ken Macken (modern day MacGyver) on some other topics, when he surprised me with a note on the ChatGPT – that he dared asking it “How do I make a business out of a global blimp transport service?” and it came with pretty cool answer. Well and as ChatGPT resonates these day through all the media I thought to make it in this post.

So let’s start from beginning – what exactly is the ChatGPT? ChatGPT is a chatbot developed by OpenAI. ChatGPT is built on top of OpenAI’s GPT-3.5 family of large language models, and is fine-tuned with both supervised and reinforcement learning techniques. (taken from Wikipedia)

You can already find some good videos explaining ChatGPT on Youtube, I liked this one:

Anyway, back to our original topic, Ken asking “How do I make a business out of a global blimp transport service?” got following answer:

GPT3: To make a business out of a global blimp transport service, you will need to conduct thorough market research to determine the feasibility and potential demand for such a service. This should include identifying potential customers and their needs, as well as any potential competitors and the market conditions they will be operating in.

Once you have a clear understanding of the market and the demand for a blimp transport service, you can begin to develop a business plan. This should include a detailed description of your proposed service, as well as a financial plan that outlines your projected costs, revenue, and profitability.

You will also need to secure funding to purchase or lease blimps and other necessary equipment, and to hire and train staff to operate the service. This may involve seeking investors or securing a loan from a bank or other financial institution.

Additionally, you will need to obtain the necessary licenses and permits to operate a blimp transport service, and ensure that your blimps and operations meet all relevant safety and regulatory requirements. This may require working with local, national, and international authorities to obtain the necessary approvals.

Overall, starting a business in the global blimp transport industry will require significant planning, market research, and financial investment. However, if there is a strong demand for such a service and you are able to offer a high-quality, reliable service, it could be a lucrative and rewarding business venture.

I obviously liked a lot that last paragraph. 🙂

Our business case just arrived! 🙂

France has been given the green light to ban short haul domestic flights – opening this opportunity to other alternative transport options. Thank you France

More in the original article here.

As per our fist steps into optocoupler world seemed worked out nicely, we’ve ventured to roll out full scale implementation which would cover all our 12 servos.

Progressing with wiring that altogether we’ve reached a dilemma how to actually give them some more practical form. The most plausible idea came to organise them in a triangle.

Finishing that assembly we ended up with some indescribable blob of cables. It needed few iterations to give it some reasonable form and reduce number of all cables.

Mainly, looking at it it instantly reminded me of a famous Flux Capacitor from the Back to the Future movie. 🙂

Anyway, it took us another week to plug it in and see it all in action.

We’ve agreed with Sebi that it looks like those ghost signal were substantially reduced and overall responsiveness seem to improved as well! That cabling is still quite silly, but that’s just an opportunity for improvement.

Passing our Hydrogen generation test and also having our new Hydrogen detector in place, it’s been time to move forward. First stage was to review leftovers from a previous day together with checking whether there’s been any impact to our Teflon coating.

It worked out that there’s been some more material in there, while coating came out without any scratch or signs of decay.

To test everything works and also to get rid of any excessive air in the container we filled another blimpy first and took some cool pictures of our dramatic sky

Seb’s been having fun with his new friend.

And we started filling the Windreiter envelope.

As you can see from the gallery below, it actually took few hours to get us there. Luckily chemical reaction stabilised nicely so we’ve got pretty stable Hydrogen production.

Finally we’ve ended up with some super-cool blimp!

Last bit was when we measured the lifting power to confirm achieved Hydrogen purity.

As you can see our kitchen scale measures 171g, where advertised value should be 195.60g of lift at Sea Level H2.

That’s roughly missing 25g, which we accounted to the thread attachment metallic clamp, sealing clamp and potential Hydrogen impurities as our experiment has long way to a clean laboratory environment. Whatever it was I think we did pretty well and whole team was very happy about the outcome! 🙂

Next morning after our initial Hydrogen generation test, I’ve realized that couple months back we’ve bought several MQ8 Hydrogen Gas sensors for our Arduino and this would be also an excellent opportunity to check if & how that’s working.

So I asked Seb and Christopher to put it together and about an hour later – voila – they had it working!

Arduino code looks pretty straightforward.

long sensorValue;
void setup() {
  Serial.begin(115200);
}
void loop() {
  sensorValue = 0;
  for (int i = 0; i < 100; i++) {
    sensorValue += analogRead(A0);
  }
  sensorValue = map(sensorValue/100, 0, 1023, 100, 10000);
  Serial.println("ppm: " + String(sensorValue));
  if (sensorValue > 300)
    tone(3, sensorValue/5);
  else
    noTone(3);
  delay(100);
}

As you may see on video below, they also added a “buzzer” to signal number of particles detected and connected it to a plotter to show values on a graph. They are using hydrogen from a previous day to test that it is really working.

Having that buzzer there came later pretty handy as it served us well to detect all the leaks whilst generating hydrogen, but that’ll have to wait for another post. 🙂

In follow up on our latest adventure in Envelope from Windreiter we’ve ended up some amazing progress this weekend. Our plan was to get heaps of it from Aluminium and Sodium Hydroxide Reaction | Al + NaOH.

Christopher dug out for us how it should work – one sodium atom, one oxygen atom, and one hydrogen atom make up this compound. When all of the molar masses of the constituents of sodium hydroxide are added together, the result is sodium hydroxide’s (NaOH) molar mass. Thus, 22.989g/mol+15.999g/mol+1.008g/mol=39.996g/mol.

So approx 40g of caustic soda = 1g hydrogen.

Molar volume, or volume of one mole of gas , depends on pressure and temperature, and is 22.4 litres – at 0 °C (273.15 K) and 1 atm (101325 Pa), or STP (Standard Temperature and Pressure), for every gas which behaves similarly to an ideal gas. The ideal gas molar volume increases to 24.0 litres as the temperature increases to 20 °C (at 1 atm).

For an ideal gas, the attractive or repulsive interactions between the molecules of gas can be neglected, therefore we can treat this gas as “ideal”. (Side Note: interaction forces between specific gases create conditions for non-ideal gas situations)

The actual molar volume of hydrogen can be exactly calculated from the experimental density of that gas, that is 0,0899 g/L at 0 °C (1 atm ) and 0.0837 g/L at 20 °C (1 atm), knowing that one mole of dihydrogen (H2) amounts to 2,0159 g/mol. Thus, if 0,08988 grams amount to 1 litre, a mole will be as big as 2,0159/0,0899 = 22,42 litres at STP (0 °C – 1 atm) and 2,0159/0,0837 = 24,1 litres.

These values of true molar volume of hydrogen are very close to the ideal gas values of 22,41 L/mol and 24,0 L/mol at 0 °C and 20 °C, respectively, thus confirming that hydrogen gas behaves almost ideally.

As always it needed some shopping to be done first to get our Hydrogen production back on rails. We started with getting 0.5 kg of Aluminium powder from Barnes.

It looks so tiny when having it in hand.

Getting Caustic Soda from Santo was much more entertaining as they keep selling it in 25kg bags only.

Of course, handling such material might be mildly problematic, we’ve got proper protection ready.

Next phase started by putting together the “reaction chamber” by scavenging on our previous hydrogen generator. Mainly our original investment into the Teflon coating paid off thousand times as the main basin needed to be corrosion resistant to withstand that caustic soda solution, while also having high thermal conductivity to disperse heat from planned (exothermic) reaction.

As a lid we’ve used an old perspex sheet and drilled couple holes to get solution feed in and hydrogen outlet. Whole contraption got placed in an esky filled with water to cool things down and also to capture any potential leaks.

Moments later we’ve started generating our first Hydrogen!

And few moments later, with assistance from Ondra, we had our blimpy back again.

At that stage we had to stop our test as it was getting late and we had some other activities.

While working in parallel on multiple projects here, an important one seemed to became quite laid back lately – our airship’s envelope. However that’s not that true. I’ve been checking all the corners to get an material which should do the job – 100 micron PU sheets – but with no luck so far.

At some stage I’ve got in touch with Mr. Martin Hill, who suggested to contact a German company called Windreiter and check what they are doing. Then it was easy and I’ve got in touch with Dr. Andreas Burkart – Windreiter co-founder and we briefly discussed our project.

To my minor setback Dr. Burkart suggested not to start building anything too complex before taking baby steps and pointer to their e-shop with few of-the-shelve envelopes there. Being busy with work I couldn’t make myself to decide where next with this topic till the “Father’s Day” event came with Sebi asking what do I want. While my first idea went to the SignMyRocket, then I reverted to a more plausible solution and asked him to pick one of the Windreiter envelopes for us instead.

Sebi picked the Silver Blimp 181-200 for 40,00 EUR.

It came from Europe in about two weeks in a well padded envelope.

Data sheet confirmed that we are getting what we’ve ordered! Based on that we should be getting ~195g of lifting power (1.91 newtons earth) with it when using Hydrogen at sea level.

Seb got instructions to use our air pump to inflate it and test if it holds pressure well.

As you can see above, it worked out very well! I can’t wait till we attempt to fill it in with Hydrogen with our aluminium foil and caustic soda experiment! 🙂

We’ve finished our previous article TRAINING SET WITH STELLARIUM II having the training set ready to go. It was up to Sebi to the next step and do the actual star identification AI training. Sebi ended up to be sort of reluctant making it in a post so it came to explore a form we haven’t used up to this point – an Interview.

Jan: Where do we start Sebi?

Seb: I’ve been interested which will be the better for our job – whether the PyTorch or the TensorFlow, and after some initial research I’ve picked PyTorch as being more popular.

So I’ve started watching following video tutorial about PyTorch.

After watching it I wrote my first code based on that video. Here it goes:

from random import random
import torch
import torch.optim as optim
from torch.optim import lr_scheduler
from torchvision import models, transforms
from torch.utils.data import DataLoader, random_split
from torchvision.datasets import ImageFolder
import os
import torch.nn as nn
import time
import copy
import signal
projectDir = os.path.dirname(os.path.realpath(__file__))+"/"
dataDir = projectDir+'../data/train_224_224_monochrome_big'
deviceName = "cuda:0" if torch.cuda.is_available() else "cpu"
device = torch.device(deviceName)
trainData = ImageFolder(dataDir, transform=transforms.Compose([transforms.Grayscale(num_output_channels=1), transforms.ToTensor()]))
testData = ImageFolder(projectDir+'../data/train_224_224_monochrome', transform=transforms.Compose([transforms.Grayscale(num_output_channels=1), transforms.ToTensor()]))
modelName = "resnet18"
batchSize = 1000
logName = "resnet18.log"
model = models.resnet18(pretrained=False)
model.conv1 = nn.Conv2d(1, 64, kernel_size=(7, 7), stride=(2, 2), padding=(3, 3), bias=False)
model.fc = nn.Linear(model.fc.in_features, len(trainData.classes))
if os.path.exists(projectDir+modelName+".pth"):
  model.load_state_dict(torch.load(projectDir+modelName+".pth"))
def main():
  print(trainData.classes)
  save_model(model)
  trainDataLoader = DataLoader(trainData, batch_size=batchSize, shuffle=True, num_workers=3)
  testDataLoader = DataLoader(testData, batch_size=batchSize, shuffle=True, num_workers=3)
  model.to(device)
  criterion = nn.CrossEntropyLoss()
  optimizer = optim.SGD(model.parameters(), lr=0.1, momentum=0.9)
  scheduler = lr_scheduler.StepLR(optimizer, step_size=1, gamma=0.8) # every step_size epochs multiply learning rate by gamma
  train_model(model, optimizer, criterion, scheduler, trainDataLoader, testDataLoader, 1, test=True)
def train_model(model, optimizer, criterion, scheduler, trainDataLoader, testDataLoader, numEpochs, test=False):
  start = time.time()
  best_model_wts = copy.deepcopy(model.state_dict())
  best_acc = 0.0
  best_train_acc = 0.0
  running_incorrects = {star:{star:0 for star in trainData.classes} for star in trainData.classes}
  if test:
    log("the next epochs are for testing:")
  for epoch in range(numEpochs):
    log('Epoch {}/{}'.format(epoch+1, numEpochs))
    log('-' * 10)
    for phase in ["train", "test"] if test == False else ["test"]:
      running_loss = 0.0
      running_corrects = 0
      if phase == "train":
        model.train()
      else:
        model.eval()
      for index, (inputs, labels) in enumerate(trainDataLoader if phase == "train" else testDataLoader):
        print('Batch {}/{}'.format((index+1)*len(labels), len(trainDataLoader if phase == "train" else testDataLoader)*len(labels))+' Accuracy: {}/{} Percent: %{:.4f}'.format(running_corrects, len(trainData if phase == "train" else testData), (running_corrects / ((len(labels)*(index)) + 0.00001)) * 100), end="\r")
        inputs = inputs.to(device)
        labels = labels.to(device)
        with torch.set_grad_enabled(phase == "train"):
          outputs = model(inputs)
          _, preds = torch.max(outputs, 1)
          loss = criterion(outputs, labels)
          if phase == "train":
            optimizer.zero_grad()
            loss.backward()
            optimizer.step()
        running_loss += loss.item() * inputs.size(0)
        running_corrects += torch.sum(preds == labels.data)
        for index, (prediction, label) in enumerate(zip(preds, labels.data)):
          if prediction != label:
            running_incorrects[trainData.classes[label.item()]][trainData.classes[prediction.item()]] += 1
      epoch_loss = running_loss / len(trainData if phase == "train" else testData)
      epoch_acc = running_corrects.double() / len(trainData if phase == "train" else testData)
      if phase == 'train':
        scheduler.step()
        if epoch_acc > best_train_acc:
          best_train_acc = epoch_acc
      # log("failed classes: "+str({star:sorted(running_incorrects[star].items(), key=lambda item: item[1], reverse=True) for star in running_incorrects}))
      log("failed classes: "+str(running_incorrects))
      log('{} Loss: {:.4f} Acc: {:.4f}'.format(
        phase, epoch_loss, epoch_acc))
      log('Accuracy: {}/{}'.format(running_corrects, len(trainData if phase == "train" else testData)))
      # deep copy the model
      if phase == "test" and epoch_acc > best_acc and test == False:
        best_acc = epoch_acc
        best_model_wts = copy.deepcopy(model.state_dict())
        save_model(model)
        log("updated model")
      time_elapsed = time.time() - start
      log('Epoch time stamp: {:.0f}m {:.0f}s'.format(time_elapsed // 60, time_elapsed % 60))
    log("")
  log('Training complete in {:.0f}m {:.0f}s'.format(time_elapsed // 60, time_elapsed % 60))
  log('Best val Acc: {:4f}'.format(best_acc))
  # load best model weights
  model.load_state_dict(best_model_wts)
  return model
def save_model(model, name=modelName):
  torch.save(model.state_dict(), projectDir+name+".pth")
  log("saved model: "+modelName)
def handler(signum, frame):
  quit()
def log(message, name=logName):
  print(message)
  with open(projectDir+name, 'a') as file:
    file.write(message+"\n")
signal.signal(signal.SIGINT, handler)
main()

Jan: What’s that doing? Looks messy.

Sebi: No. It is beautiful! Ok. It takes from pre-build network Resnet18 from PyTorch. (Resnet networks are in general famous for its image processing abilities.) I’ve changed it to have a correct number of inputs and outputs.

Jan: Like what?

Sebi: Inputs – greyscale and 64 x 64 points resulutions and Outputs – number of training classes (20 stars).

Jan: What next?

Sebi: Then it starts training that model through the back-propagation neural network and started showing how it progresses. It stops after several epochs and saves itself (trained weights).

Jan: What was a first result?

Sebi: So on a first epoch on a first go, I’ve ended up with accuracy of 0.01 accuracy. It kept improving over 33 epochs and it came up with 60% accuracy against the testing dataset.

Jan: That’s pretty cool for a first run. Would you share that log with us please?

Sebi:

# learning rate: 0.01, momentum: 0.0, step_size: 7, gamma: 0.1
saved model: resnet18
Epoch 1/50
----------
train Loss: 2.8978 Acc: 0.0972
Epoch time stamp: 22m 34s
test Loss: 2.7925 Acc: 0.1225
saved model: resnet18
updated model
Epoch time stamp: 23m 24s
Epoch 2/50
----------
train Loss: 2.6922 Acc: 0.1929
Epoch time stamp: 45m 48s
test Loss: 2.6295 Acc: 0.2250
saved model: resnet18
updated model
Epoch time stamp: 46m 32s

… many mode lines.

Epoch 32/50
----------
train Loss: 2.0006 Acc: 0.6081
Epoch time stamp: 762m 41s
test Loss: 2.0135 Acc: 0.5955
Epoch time stamp: 763m 35s
Epoch 33/50
----------
train Loss: 2.0006 Acc: 0.6106
Epoch time stamp: 786m 42s
test Loss: 2.0042 Acc: 0.6065
saved model: resnet18
updated model
Epoch time stamp: 787m 36s

Jan: Ok, what happened next?

Sebi: I’ve been playing with few training constants like it follows on a smaller dataset.

saved model: resnet18
ended session
# learning rate: 0.1, momentum: 0.9, step_size: 5, gamma: 0.5
saved model: resnet18
Epoch 1/10
----------
train Loss: 0.4430 Acc: 0.8650
Epoch time stamp: 41m 11s
test Loss: 0.0202 Acc: 0.9960
saved model: resnet18
updated model
Epoch time stamp: 42m 34s

.. making it clear that those new training constants have quite significant impact on how it all operates (much better now). As you can see below – it finished in achieving 100% accuracy.

saved model: resnet18
Epoch 1/3
----------
train Loss: 0.0003 Acc: 1.0000
Accuracy: 18000/18000
Epoch time stamp: 22m 11s
test Loss: 0.0001 Acc: 1.0000
Accuracy: 2000/2000
Epoch time stamp: 22m 52s

Jan: Amazing – almost unbelievable. It means that we can identify 20 brightest stars with 100% accuracy now?

Sebi: Not exactly. When we started training on a much bigger dataset and it achieved on the training set just 99% accuracy, while on the testing 95%.

Jan: Why do you think it didn’t reach 100%?

Sebi: Because that dateset is corrupted … definitely.

Jan: I don’t believe you.

Sebi: Checkout this.

Epoch 1/1
----------
failed classes: [('Arcturus', 877), ('Canopus', 157), ('Achernar', 0), ('Acrux', 0), ('Aldebaran', 0), ('Altair', 0), ('Antares', 0), ('Betelgeuse', 0), ('Capella', 0), ('Deneb', 0), ('Fomalhaut', 0), ('Hadar', 0), ('Mimosa', 0), ('Pollux', 0), ('Procyon', 0), ('Rigel', 0), ('Rigel Kentaurus', 0), ('Sirius', 0), ('Spica', 0), ('Vega', 0)]
test Loss: 0.1494 Acc: 0.9483
Accuracy: 18966/20000
Epoch time stamp: 9m 28s

Why do you think it would fail on just two stars?

Jan: That original data set was generated programatically and I am pretty sure there is no problem.

Sebi: Fine, look at this:

Training complete in 0m 25s
Best val Acc: 0.000000
saved model: resnet18
the next epochs are for testing:
Epoch 1/1
----------
failed classes: {'Achernar': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Acrux': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Aldebaran': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Altair': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Antares': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Arcturus': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 79, 'Capella': 798, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Betelgeuse': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Canopus': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 157, 'Spica': 0, 'Vega': 0}, 'Capella': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Deneb': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Fomalhaut': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Hadar': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Mimosa': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Pollux': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Procyon': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Rigel': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Rigel Kentaurus': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Sirius': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Spica': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}, 'Vega': {'Achernar': 0, 'Acrux': 0, 'Aldebaran': 0, 'Altair': 0, 'Antares': 0, 'Arcturus': 0, 'Betelgeuse': 0, 'Canopus': 0, 'Capella': 0, 'Deneb': 0, 'Fomalhaut': 0, 'Hadar': 0, 'Mimosa': 0, 'Pollux': 0, 'Procyon': 0, 'Rigel': 0, 'Rigel Kentaurus': 0, 'Sirius': 0, 'Spica': 0, 'Vega': 0}}
test Loss: 0.1494 Acc: 0.9483
Accuracy: 18966/20000
Epoch time stamp: 9m 55s

… just four stars identification results are strangely incorrect. See the table below.

Jan: Well – it is a neural network, it is ok to have few wrong. I actually think this is an awesome result! Thank you Sebi!

Sebi: FYI I also tried running it with Resnet30 and …

saved model: resnet30
Epoch 1/1
----------
....
train Loss: 0.0008 Acc: 1.0000
Accuracy: 199995/200000
Epoch time stamp: 549m 7s
failed classes: {"Achernar": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Acrux": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Aldebaran": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 1, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Altair": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Antares": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Arcturus": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 271, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Betelgeuse": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Canopus": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 2, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 840, "Hadar": 0, "Mimosa": 0, "Pollux": 1, "Procyon": 0, "Rigel": 8, "Rigel Kentaurus": 0, "Sirius": 92, "Spica": 0, "Vega": 57}, "Capella": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Deneb": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Fomalhaut": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Hadar": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 1, "Sirius": 0, "Spica": 0, "Vega": 0}, "Mimosa": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Pollux": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 1, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Procyon": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 2, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Rigel": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Rigel Kentaurus": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Sirius": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Spica": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}, "Vega": {"Achernar": 0, "Acrux": 0, "Aldebaran": 0, "Altair": 0, "Antares": 0, "Arcturus": 0, "Betelgeuse": 0, "Canopus": 0, "Capella": 0, "Deneb": 0, "Fomalhaut": 0, "Hadar": 0, "Mimosa": 0, "Pollux": 0, "Procyon": 0, "Rigel": 0, "Rigel Kentaurus": 0, "Sirius": 0, "Spica": 0, "Vega": 0}}
test Loss: 0.7076 Acc: 0.9365
Accuracy: 18729/20000
saved model: resnet30
updated model
Epoch time stamp: 566m 14s
Training complete in 566m 14s
Best val Acc: 0.936450
saved model: resnet30
Epoch 1/1
----------

… here the accuracy got even worse – getting just 94%. I find interesting that those invalid results with Resnet18 are not correlating with Resnet30. It just doesn’t make sense …

Jan: Well for me both results look impressive. Thank you for answering all my questions!

Having this stage of our project covered, what lies in front of us next? We need to finish whole loop here which I currently imagine like this:

1. Stellarium randomly picks a place on Earth in a certain date-time
2. Sellarium takes pictures of 4 brightest stars saves those locally and records their inclination
3. Pre-trained AI attempts to identify all 4 stars and potentially runs some basic checks if those are forming a plausible scenario (can be seen from Earth at some stage / above horizon).
4. In the next stage application uses inclinations of identified stars and looks up star charts for specified date to identify celestial position.
5. Finally it translates celestial position to GPS coordinates.

However this needs to wait for another day. 🙂

On 8th Sept we had an opportunity to present our project on a Hydrogen Connect Summit Brisbane 2022 organised by H2Q.

It was a long day and we met number of awesome people interested in our project. I took few pictures and will keep adding into following gallery as getting more from other sources.

Whole event culminated by presenting our project in front of ~400 summit attendees, including our technological demonstrator.

PowerPoint presentation itself here:

Whole team took a picture altogether with organisers.

Huge thanks to H2Q for inviting us to this event. We’ve learned a lot and got some awesome contacts to follow up on with!

UPDATE 2022-09-12: Received this video from Phil – Seb demonstrating our Blimp’s control with ramping up motors to a full power to show off. 😉

UPDATE 2022-10-07: Received few more pictures from Hydrogen Connect Summit team.

Working on our new super-cool gimbal arm for a while we’ve hit a bummer. The most stressed part of our design – the joint between the main arm and attachment jig – apparently is not strong enough to withstand required forces, even more, making it pretty susceptible to a so-called hangar-rash.

It took us couple hours to do a minor design change – running upper connection bolts all the way through the attachment jig to reinforce that whole thing.

Slicing on cura – that’s that easy part.

However running out of filament was a major problem 😀

Luckily one of our generous sponsors (Vilem) came back with an instant supply of 4 big rolls of it! Thank you Vilem!!! 🙂

Printing it was then easy, it just took whole weekend to get 4 of those as each print took 7hrs.

Bit of sanding + drilling and mounting and voila – it feels much stronger now.

Let’s see where it breaks next time. 🙂 Still, it keeps me wonder how all that 3D printing (Additive Manufacturing) made things possible for us. You mess up / break something and isn’t24 hrs later you have a better or replacement part in your hands without much stress and hustle.

Checking some articles on this I have found this one – Intro to Additive Manufacturing: Prototyping vs. Production, which is very nicely describing challenges of redesigning legacy products and prototyping with 3D printing provides tangible benefits.

They are mentioning 5 key points where 3D printing helps:

• Accelerate Development Time – Exceeding the typical design cycle schedule by 3D printing your ideas overnight and having your parts available the next morning.
• Fail Fast, Fail Often – 3D printing enables the engineering team to identify mistakes early in the process. Products are hardly ever right the first time, this process is mitigating the time lost with rapid prototyping.
• Cost Effective – The traditional methods of developing a prototype can be time consuming and expensive. Multiple fabrication methods, reserving time on production equipment or not having access to the right technology can be costly.
• Enhanced Creativity – Rapid prototyping is an efficient tool for engineers to quickly evaluate and improve on their ideas.
• Product Testing – Form, fit and function. Feel the ergonomics of a new prototype, squeeze pieces to pressure fit an assembly or drop test the part to evaluate functional strength. Easy with 3D printing.

Sounds pretty handy, doesn’t it? 🙂

Checking where next with our “super-awesome” 42GB training set, I’ve realized that for a next step we’ll need much lower resolution. We are now on 1920 x 1080, while many of those traditional neuron networks like ResNet are happily coping with much more modest 224 x 224.

So well onto some tiny Python scripting to get our set converted to 224 x 224 – grayscale! Following script does that magic in a matter of 90 minutes.

#!/usr/bin/env python3

from argparse import ArgumentParser

from PIL import Image, ImageOps
import os
from glob import glob

def transform(im, args):
  left = im.width/2-args.width/2*args.scale
  top = im.height/2-args.height/2*args.scale
  right = im.width/2+args.width/2*args.scale
  bottom = im.height/2+args.height/2*args.scale
  return left, top, right, bottom

def crop(args):
  result = [y for x in os.walk(args.input) for y in glob(os.path.join(x[0], '*.png'))]
  counter = 0

  for filename in result:
    with Image.open(filename) as im:
      im2 = im.crop(transform(im, args))
      im2 = im2.resize((args.width, args.height))
      if args.grayscale:
        im2 = ImageOps.grayscale(im2)
      filename_out = filename.replace(args.input, args.output)
      os.makedirs(os.path.dirname(filename_out), exist_ok=True)
      im2.save(filename_out)
    counter += 1
    pct = round(counter/len(result)*100,4);
    print("Finished processing for", filename_out, "\t[", pct, "%]")


def main():
  parser = ArgumentParser(description='Recursive crop & transformation for image files')

  parser.add_argument('--input', default='./train', help='input folder')
  parser.add_argument('--output', default='./train_224_224_monochrome', help='output folder')
  parser.add_argument('--height', default=224, help='image height')
  parser.add_argument('--width', default=224, help='image width')
  parser.add_argument('--grayscale', default=True, help='convert output to grayscale')
  parser.add_argument('--scale', default=2, help='scale down coefficient')

  args = parser.parse_args()

  print('input  folder: ', args.input)
  print('output folder: ', args.output)

  if args:
    crop(args)

  else:
    parser.print_help()

  print("Done")

main()

This whole operation worked out reducing our initial 48.5GB monster train set to much more convenient 1.4GB.

Result seems to be bit radical, but well it is like it is.

Meanwhile Sebi kept reading and experimenting with machine learning and got some fantastic results there, but that’s for another post. 🙂

Thinking about training our AI to locate stars Sebi ran a test demonstrating a simplified training set we’ll be needing images of 20 brightest stars – 10.000 per each having:

• reasonable focus / zoom in & out
• any possible rotation
• good quality
• no atmospheric effects
• no horizon
• no planets / sun / moon / satellites

The obvious question came instantly – where to get such a training set for our project? The idea came to use Stellarium.

Stellarium is already a pretty old application (started 2001) which can emulate a planetarium for your computer. It shows a realistic sky in 3D, just like what you see with the naked eye, binoculars or a telescope.

Getting and running Stellarium on a Linux is piece of cake:

$ git clone https://github.com/Stellarium/stellarium.git
$ cd stellarium
$ mkdir -p build/unix
$ cd build/unix
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/stellarium ../.. 
$ make -j4
<wait here>
$ ./src/stellarium

Application throws you straight to a nice screen – showing very late morning in North Brisbane. 🙂

Well, this is a moment when things got little bit more complicated. I had to get familiar with the Stellarium scripting engine, its API, Julian calendar and also PyTorch training set layout and ended up with submitting an actual patch to the Stellarim guys with all that wrapped up.

Let’s start with a patch which seems to be trivial – just allows creating a subfolder when needed:

From 6d2fcc079705385f4803c78902099a38ddc4e89f Mon Sep 17 00:00:00 2001
From: Jan Bilek <jan.bilek@eftlab.com.au>
Date: Sat, 13 Aug 2022 22:22:59 +1000
Subject: [PATCH] Screenshot to attempt to create folder when missing

---
 src/StelMainView.cpp | 19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/src/StelMainView.cpp b/src/StelMainView.cpp
index 288832dc75..d72b1c14f6 100644
--- a/src/StelMainView.cpp
+++ b/src/StelMainView.cpp
@@ -1718,16 +1718,17 @@ void StelMainView::doScreenshot(void)
 		}
 		else
 			screenshotDir = StelFileMgr::getUserDir().append(screenshotDirSuffix);
+		StelApp::getInstance().getSettings()->setValue("main/screenshot_dir", screenshotDir);
+	}
 
-		try
-		{
-			StelFileMgr::setScreenshotDir(screenshotDir);
-			StelApp::getInstance().getSettings()->setValue("main/screenshot_dir", screenshotDir);
-		}
-		catch (std::runtime_error &e)
-		{
-			qDebug("Error: cannot create screenshot directory: %s", e.what());
-		}
+	//Always check if destination folder exists and attempt to recreate it if not
+	try
+	{
+		StelFileMgr::setScreenshotDir(screenShotDir.isEmpty() ? StelFileMgr::getScreenshotDir() : screenShotDir);
+	}
+	catch (std::runtime_error &e)
+	{
+		qDebug("Error: cannot create screenshot directory: %s", e.what());
 	}
 
 	if (screenShotDir == "")
-- 
2.25.1

Don’t get distracted by that – it looks much worse then what it is – it is just couple lines, all the rest is computer generated fluff to make it look cool (and needed to be working with the original code).

Interesting part comes now – following script generates a PyTorch star training set for our celestial navigation project – 20 x 10000 pictures of the brightest stars. 🙂

var stars = ["Sirius", "Canopus", "Arcturus", "Rigel", "Vega", "Capella", "Rigel Kentaurus", "Procyon", "Betelgeuse", "Achernar", "Hadar", "Altair", "Acrux", "Aldebaran", "Spica", "Antares", "Pollux", "Fomalhaut", "Deneb", "Mimosa"]; //20 brightest stars

DIR="~/Pictures/Stellarium/";

var pictsInSet = 10000;     //Size of a training set per star
var minMjDay = 50000.000000 //Min Julian calendar date to consider for randomization
var maxMjDay = 60000.000000 //Max Julian calendar date to consider for randomization
var minZoom = 10 	     //Min zoom to consider for randomization
var maxZoom = 30 	     //Max zoom to consider for randomization

//Helper functions
function randomFloat(min, max) {
    return min + (max - min) * Math.random();
}
function showAStar(cName) {
  core.setMJDay(randomFloat(minMjDay, maxMjDay));
  core.selectObjectByName(cName, true);
  StelMovementMgr.autoZoomIn(0);
  StelMovementMgr.zoomTo(randomFloat(minZoom, maxZoom),0);
  StelMovementMgr.deselection();
  core.wait(0.1); //Making sure that UI has a moment to catch up
}

//Disabling all
ConstellationMgr.setFlagArt(false);
ConstellationMgr.setFlagBoundaries(false);
ConstellationMgr.setFlagLines(false);
ConstellationMgr.setFlagLabels(false);
GridLinesMgr.setFlagEquatorGrid(false);
GridLinesMgr.setFlagAllLines(false);
LandscapeMgr.setFlagLandscape(false);
MilkyWay.setFlagShow(false);
NebulaMgr.setFlagHints(false);
SolarSystem.setFlagPlanets(false);
StarMgr.setFlagLabels(false);

core.setGuiVisible(false);
core.setTimeRate(0);
core.wait(1); //Making sure that UI has a moment to catch up

for (i=0; i<stars.length;++i) {
  for (ii=0; ii<pictsInSet; ++ii) {
    showAStar(stars[i]);
    var fileName =  ii;
    core.debug(DIR + stars[i] + "/" + fileName +".png");
    core.screenshot(fileName, false, DIR + stars[i], true);
  }
}

core.setGuiVisible(true);

Well then it took almost 5 days (I had some problems with stability), but it worked out well. We’ve ended up with 42.3 GB images of 20 brightest stars – 10.000 each!

Even that directory listing looks impressive!

Adding a first three images of Sirius here for reference.

Huge thanks here belongs to the Stellarium team – this wouldn’t be possible without you!

Next stage – onto some serious machine learning! 🙂

Sebi came with a new project on his own, which I thought it is perfect – let’s use machine learning to guess how many candy are in the jar!

Somehow coincidentally few days later we’ve ended up on the Cyber wargaming in a Lego City MeetUp arranged by Chris Boden.

We’ve enjoyed MeetUp with Sebi a lot and had a good chat with guys from TLR afterwards (namely Billy was just awesome white-hat hacker).

We also caught up with Chris B. and while Sebi briefly introduced him to his new project idea, Chris instantly proposed to use today’s state-of-art machine learning computer – Jetson Nano for it!

You never heard of Jetson Nano? Jetson Nano is a small, powerful computer that lets you run multiple neural networks in parallel for applications like image classification, object detection, segmentation, and speech processing. All in an easy-to-use platform that runs in as little as 5 watts – all magic in size of a cigarette pack.

Well, Chris didn’t just told us about it, but instantly gave a call to Ben and asked him on our behalf if we can borrow one … and Ben agreed – apparently having one spare on his desk!

We had to visit JayCar next day as we haven’t had a power supply strong enough to feed this hungry beast, but Sebi ended up having it working in couple days. Now just to teach it to count lollies! 😀

Getting to the end of our post – allow me here to say huge thank you to Chris Bowen and Ben Duncan – your help allowed us to jump instantly forward a mile! It is awesome to have such a great support from you Noosa guys and always feels welcome for more then a decade!

Thank you all again!

Reading through my common news-feed couple months ago, I’ve stumbled on a new 16MB ArduCam with Autofocus.

Even not having any actual usage for it we decided to get one for $29 AUD.

It took us couple months to find a moment to start experimenting with it, but finally Sebi mounted it on our RPI.

I’ve left all the rest with Sebi and simply following How-To from here he made it working in ~30 minutes. And here comes our first picture!

Not being that impressive we’ve captured one more with Eddie. 🙂

Asking Sebi how he did it I’ve been provided with that link above and following line from terminal:

sudo libcamera-still -o images/test.jpg --autofocus

As per our previous article Gimbal arm, we’ve got seriously misled by this project in past three months. There were too many things happening so let’s just go through several highlights.

Design update

Trying to get around that criteria of having our arm light, but still very firm we’ve progressed for a multiple channels arm:

To a single channel arm with clamps and 20% filling:

Current complete 3D model of our arm then looks like this.

TBA

While it sounds like a trivial thingy, it took quite an effort to get it right. The thing you are seeing on picture below is practically just a garbage due to poor design, where each of these prints is ~200g of wasted filament + 24-36hrs of printing.

Printing challenge

While printing became somewhat common for us, some of those latest 36hrs prints came in as something new. Particular problem was our garage sound proofing – it is far from perfect and while it can be happily ignored through the day it resonates through a whole house through the night causing some unwelcome family discussions.

Let’s have a look how such print looks like in a time-lapse.

Here you may ask why it is being printed in that most inefficient way – but trust me, this is the best way we identified. Bending forces imposed through the printing due to the temperature differences can come with an incredible power on these lengths and kept ripping the print in a pieces without any problems.

Well at the end we’ve finished having pretty nice collection. 🙂

Cabling mayhem

Blueprint below depicts our cabling plan. Whatever is there – in short it actually means that we needed to get 7 different cables through the arm’s central shaft to have it all working.

In some cases it took up to several hours to make it happen! Chickening out on our first go – I cut out a bit of material to actually make it happen, but it really wasn’t needed later on.

This included also changes to all the connectors around and new power bridge development (I’m keeping this one out of this post as there is more about it). Anyway gimbals ended up needed rewiring as well.

All four arms assembly and cabling completed looked pretty satisfying. It took us two whole weekends just to do this.

Trusses replacement

In comparison to all the other tasks this was a back to basics. Old steel stabiliser rods connecting our thrusters needed to be replaced with a light-weight wooden variant before mounting in our new arms. This could be considered as a cosmetic, but still took us some effort to do it right.

The last bit missing was to drill an oval hole in each support leg to be able to lead our cabling through it.

New arms

Finally we can present you – new arms! Enjoy!

Aren’t they beautiful?

As always, if you read all the way here, please drop us a note on what you think – your feedback is our best motivation. 🙂

Next time – new 6V and 25V power bridges and let’s get back to the ArduPilot again!

Months ago, when planning for putting together our new gas bags design, I’ve realised that we’ll need something more reliable to do all the cutting. Spreading a word, we suddenly ended up with a Tooli G3 Laser cutter form Toolbotics!

It looks even better on their Ad – CNC, Laser Toolbotics Tooli 3G Launch!

While it may sound like a fantastic news, it ended up being a big story – it actually might be a good time to get yourself a good cup tea before you’ll start reading.

So it begins, we’ve did the obvious first – assembled the tool and ran it!

Even Sebi & Oli had pretty promising go on that.

However we’ve hit the first obstacle here, to be able to do something sensible we needed to produce a gcode which would tell it what to do. Checking on the vendor’s page solution seems to be simple just get their Plotter! Well not that fast as it needs the Art2Gcode program which does not open because it needs the Adobe Flash service, which doesn’t exist for past X years. Bummer.

So, trying to get something we wrote an email to tooliworlds@gmail.com to get some support there. It worked out that Toolbotics practically doesn’t exist anymore and their support is limited. Anyway someone finally responded and we’ve got our hands on that Art2Gcode app and Sebi has been able to run it somehow on his Windows PC.

We’ve loaded resulting Gcode and loaded it on a SD card, plugged it in the device and .. it couldn’t find any files loaded. So we got back to Toolbotics support again, asking for any advice and they came back with:

… and then many more iterations later it became – that it all can be an SD card reader problem. And that was a proper opportunity to check what’s inside that box! 🙂

Very interesting. Information on boards provided us with few ideas. Main thing here – you can see that the board is modified Mega controller from Makerlab. Its description says that it is a Single board solution, Remix of Arduino mega and RAMPS and it is actually pretty cool!

However we are interested mainly in that SD card support (you can see connections in a blue frame saying LCD/SD support with Mini Panel above). Thinking obvious – SD Card reader is broken, we did a quick run to grab a new one for $5.95.

Well, swapping it with the new one changed nothing – no files seems to be loaded / detected by that thing! Getting already bit frustrated, I’ve asked for another advice and been given that it is very likely main board problem and it needs to be replaced. So I asked if we can be provided with a source code or a firmware to attempt to do some debugging ourselves and ended up in some sort of strange Catch 22 situation where firmware cannot be provided as it is their IP so even they recommend board replacement, there is no way to reload it.

This argument seemed to be good enough that Toolbotics support actually ended up providing whole FW source code! Having it checked by Andrew – he discovered that it is based on a Open-Source 3D printer FW called Marlin, just version 1.x, while they already moved forward a bit.

Still, Andrew’s been able to revive it to get it compile again. Next step was obvious – load it! And this is where things are getting interesting a lot again, by loading the firmware provided over the one present in there, everything stopped working, even those things which seemed to be half-working before. Darn.

I’ll keep you hanging here as this is getting pretty long, while rest assured that this story is not over!

Andrew came back having some fun with CrAIyon – “Craiyon, formerly DALL·E mini, is an AI model that can draw images from any text prompt!”. Some cool pics came out of it, so I put them in a small gallery.

It is fascinating what this technology can do!

UPDATE 2022-09-06 from Viktor K:

Let us know if you’ll get some cool ones, we’ll get them posted here as well!

While reading through the Fatal Flight from Bill Hammack, I’ve noticed numerous references on another book – Airship Design by Charles P. Burgess. I couldn’t resist an opportunity and bought a copy. It arrived shortly and I’ve ended up reading it for past 2 months! There were was so much of interesting information related to our project that I’ve lost track of all of them after while, but dedicated to coming back and do at least a minimal review on some highlights – I came with a plan to pick my top 10 highlights.

While plan is laid, I would still like to start with synopsis on the book’s booklet itself: Originally published in 1927, this volume was intended to fill the dual role of textbook for the student of airship design and handbook for the practical engineer. The design of airships, particularly of the rigid type, is mainly a structural problem; and theoretical aerodynamics has nothing like the relative importance which it bears in airplane design. This is to be expected when we consider that the gross lift of an airship depends solely on the specific gravity of the gas and the bulk of the gas container, and not at all on shape or other aerodynamic characteristics which determine the lift of airplanes. … and it is all there!

Now let’s start with our list itself.

1/ Beautiful historical pictures and schematics

This book is full of them. I’m picking up two of them, bu I’ll keep picking more through our list.

2/ Hydrogen vs. Helium lifting performance.

It is well known that weight difference between weight of Hydrogen and Helium is just about 5%. However it is not that apparent how it translates to the gas lifting power. One of the paragraphs in the Size and Performance section covers this topic in a detail clearly stating that usage of Hydrogen increases overall performance of the airship by incredible 54.5% – this roughly translates into larger payload / reach radius / operations ceiling in general.

3/ Testing with models

Imagine 1920s – no computers, 3D visualisation, well … no calculators, no super computers. Pinnacle of the modern technology was mechanical Enigma Machine. What you do? You use wind tunnels to test your aerodynamics, and underwater models for testing all sort of sheering moments and stress forces. Then you’ll come with equations which will describe how all those observations scale up. Then you build it and learn from your mistakes and repeat. Purely amazing!

4/ Venting & Exhaust trunks

Rapid pressure changes caused by the airship’s steep ascend, descend or just gas temperature changes are clearly one of the prime dangers every airship is facing. Practical way to tackle that is to have some good-sized vents which can prevent popping its envelope. Yep, even this is in, including practical calculation example relating to the overall volume.

There is also an equation providing required vent area on the next page together with a description of exhaust trunks for safe Hydrogen venting from gas bags.

5/ Airship size and its performance

You have an airship of a size X and you are designing it to travel with a certain speed, how many horse powers you need? This is called the effect of increased speed – every cyclist has pretty good practical experience with this. With bit of basic calculations and following graphs you’ll know that for your airship being able to carry 16.000lbs payload with speed of 60 knots, you’ll need it to mount it with power plants totalling 1.450Hp.

6/ Slenderness and Elongation

Those two super-important fitness parameters are main parameters coming from airship’s linear dimensions and volume. There parameters have a direct effect on the airship’s performance. This book provides multiple graphs showing these effects, while to my surprise at the end of this chapter it leaves designer free hand as it seems like some of those parameters and their effects are not that clear.

7/ Materials

Let me introduce you to the state-of-art materials for building airship in 1920s: duralumin, high-tensile steel and hick cotton, painted with aircraft dope containing aluminium to reduce solar heating for envelope! While doing its job, all these materials are today superseded new ones which are lighter, stronger and overall more reliable than anything they could imagine that time. It is actually surprising how creative and resourceful engineers of their time were.

8/ Airship resistance – skin friction

There are multiple parameters affecting overall airship resistance – ability to efficiently propagate through the air and operate. While all of them are important, the most interesting for me was the skin friction – the tangential force of the air actin upon the surface of body. While there are equations provided with indications on how to get these forces, apparently any coarse buckram, unglazed fabric or any other surface imperfection can have significant impact on this ranging with up to 15% performance penalty. Still it is recommended to keep testing, keep testing and then learn from other projects.

9/ Build your own

Whole chapter (called Steps in Design) is dedicated for engineers to be able to assist them with step-by-step design which will fulfil certain performance requirements. It again recommends to check on other projects for inspiration and learn from them. All main and expected design aspects are covered, while paying detail to its controls, ballast, mooring mechanism and finishing with details on passenger cars.

10/ Common airship fallacies

One of the most interesting and the final chapter of this book – what not to do when you are designing your airship. The book clearly warns not to use following inventions:

a) The vacuum airship
b) Compressing gas or air for ballast
c) Artificial control of super-heat
d) Combined heavier and lighter-than-air craft
e) Channel through hull to reduce resistance
f) Wind screen at mooring mast

You might be not surprised that except one – we’ve been clearly considering all of them in our design! I’ll leave you to guess which one was it. 🙂

And that’s all! Really enjoyed this book as well written and while technical still very readable. It already found its place in our library and inspired several updates to our design. Thank you Mr. Burges, your effort won’t be forgotten!

In our previous we’ve got all ready – now wrapping it all up – gas cell’s pressure control!

So Sebi prepared this board below to do the job.

There is an Arduino Nano (that central blue-ish thingy), while that main magic is that black micro-chip-y thing, which is actually an ULN2003 16-Pin Darlington Transistor Array IC. This micro-chip integrates something like SUPPRESSION DIODES FOR INDUCTIVE LOADS – which is quite fancy word for a current relays. It is there to allow Arduino to handle higher voltages for selenoid and air pump operations.

Took few pictures when it’s all mounted to our gas cell.

Having it all connected, we did a first pressurisation test.

So Sebi actually did all the design and coding and testing and here is his working code (if you are really trying to give it a go don’t forget to get this library too).

#include <HX710B.h>

HX710B pressure_sensor;

float currentPsi = 0.0807;
float targetPsi = 0.083;
float targetRadius = 0.001;

String conStatus = "normal";

bool moreOverRide = false;
bool lessOverRide = false;

void setup() {
  Serial.begin(57600);
  pressure_sensor.begin(2, 3);
  pinMode(4, OUTPUT); //input
  pinMode(5, OUTPUT); //output
  pinMode(6, OUTPUT); //motor
}


void loop() {

  if (pressure_sensor.is_ready()) {

    Serial.print("current PSI: ");

    currentPsi = pressure_sensor.psi();

    Serial.print(currentPsi, 4);
    Serial.print(" target PSI: ");
    Serial.println(targetPsi, 4);

    Serial.println((moreOverRide || lessOverRide));
    Serial.println(conStatus);
  }

  if (Serial.available()) {
    targetPsi = Serial.readString().toFloat();
  }

  if ((currentPsi + targetRadius < targetPsi) || (moreOverRide && currentPsi < targetPsi)) {

    digitalWrite(4, HIGH);
    digitalWrite(6, HIGH);
    digitalWrite(5, LOW);

    moreOverRide = true;
    lessOverRide = false;

    conStatus = "need more - 4 - on, 5 - off";
  } else if ((currentPsi - targetRadius > targetPsi) || (lessOverRide && currentPsi > targetPsi)) {

    digitalWrite(4, LOW);
    digitalWrite(6, LOW);
    digitalWrite(5, HIGH);

    moreOverRide = false;
    lessOverRide = true;

    conStatus = "need less - 4 - off, 5 - on";
  } else {
    digitalWrite(4, LOW);
    digitalWrite(6, LOW);
    digitalWrite(5, LOW);

    moreOverRide = false;
    lessOverRide = false;

    conStatus = "all good - 4 - off, 5 - off";
  }
}

Then finally – voila – here comes it all working!

Well, this is it. Now just to build many of them and scale up! 🙂

UPDATE 14th June 2022

Sebi assumed that this is a good opportunity to test his new PCBs and reorganise those electronic parts from breadboard to there.

We also did few more tests with that new setup.

With preps started – in the next stage we started planing for an actual gas bag. Using our brand new whiteboard we’ve drafted this.

Well it might not look that super clear, so I’ve prepared a sketch in the OpenSCAD.

If you are interested, here comes the code.

module GasBagMiddle() {
  D() {
    union() {
      %D() {
        cylinder(25, 25, 25);
        Tz(0.01)
        cylinder(25 -.02, 25-.02, 25-.02);
        Tz(-0.01)
        cylinder(25 +.02, 5, 5);
        Tz(-0.01)
        cube(25+0.02);
      }
      D() {
        cylinder(25, 5, 5);
        Tz(0.01)
        cylinder(25 -.02, 5-.02, 5-.02);
      }
      n=8;
      for(w=[0:360/n:359]) {
        Rz(w)T(15, 0, 12.5)
        cube([20,0.1,25], center = true);
      }
    }
    Tz(-0.01)
    cylinder(25+0.02, 5-.01, 5-.01);
    Tz(-0.01)
    cube(25+0.02);
  }
}

You may now wonder what are you looking at, so that is a model of our gas cell – actually the middle one. It will be wrapped around one of our central ducts – that’s why there is that central hole. It also comes with internal partitioning, to support holding a shape and one quarter is missing as it forms an internal opening for airship’s technical background.

So we started drawing and cutting – a lot.

.. and then gluing for several days …

Last picture comes with the adaptor already glued in, but I took couple close ones when gluing it in as well.

Whole that envelope was quite stable so we couldn’t resist and mounted it on our jet cart.

It looked pretty wild already – and it is not over! Stay tuned!

In preparation of our gas cell project we restocked few parts – couple of air valve selenoids, pack of digital pressure meters and 12V air pump.

First thing first, when pump arrived, I noticed that it is missing some sort of clamp/mount. Got some inspiration from Google pictures around and printed couple of those.

About an hour later got this model out of the OpenSCAD.

After printing it, I couldn’t resist and did another improvement 🙂

.. but then forgot to upload the latest model in a printer, so ended up with the first one anyway. Still it looks pretty good when mounted. What you think?

Second part of our preparations was to come up with an adaptor which would allow connecting three silicon tubes to our gas cell – one for its inflation, one for deflation and third one for a pressure sensor – something like this.

Printed out it came out nicely on the first try.

Sebi dry-connected it to see if is going to do the job.