1. Generate the design concept.
   I first generated the object I wanted as an image using text prompts and reference images. I used both ChatGPT and Gemini for this step. One important thing to keep in mind is to remove unnecessary overhangs that would slow down the 3D printing process later. In this case, the cat whiskers were removed.

2. Convert the image to a 3D model.
   I used Meshy to convert the generated image into a 3D .stl file.

   1. Repeat steps #1 and #2, until the mesh looks perfect. Otherwise you’ll spend more time manually editing the mesh in Fusion360.

3. Refine the model in Fusion 360.
   I imported the STL into Fusion 360, converted it to a mesh, and added the necessary functional features for a light fixture: the light bulb socket hole, mounting holes, and other adjustments.

4. Slice the model.
   I prepared the print using Bambu Lab’s slicing software.

   1. I used Brim and glue stick on the printing bed, to ensure the print won’t warp or detach.

5. 3D print the object.
   The model was printed using PETG-HF filament, and the print took about 7 hours and 30 minutes.

6. Install it.
   Finally, I mounted the fixture and installed the camera bulb.

Here is the process:

The hardware stack:

1. Flight computer:

   1. Raspberry Pi 5 running the latest Rasberry OS

   2. Hailo 8 AI HAT (26 tera-operations per second)

2. Drone components:

   1. SpeedyBee F405 V4 flight controller

   2. M1025Q - GEPRC GPS module

   3. BetaFPV LiteRadio 4 ELRS RC controller. Useful for changing flight modes.

   4. ExpressLRS ELRS 2.4G RX SX1280 Nano RC receiver

   5. TBS Source One frame

   6. PACER V2 P2207 Powerful freestyle - 1950 KV motors

The interface between the Raspberry Pi flight computer and the F405 MCU is done by connecting the F405 T2/ R2 UART2 pins to the Raspberry Pi T1/ R1 pins.

On the Raspberry Pi 5 you have to edit /boot/firmware/config.txt and set these two params:

enable_uart=1

dtoverlay=uart0

You can test the connection by using the following commands in the Raspberry Pi terminal after installing MavProxy in a virtual environment.

mavproxy.py --master=/dev/serial0 --baudrate 921600 --aircraft MyDrone

And have a simple motor-test (spin one motor for one second), after removing the drone props.

Motortest 1 0 20 1 

The build:

I’ve designed and 3D printed a mount, for stacking the Raspberry Pi with the Hailo accelerator under the drone, while keeping the batteries on top. The Raspberry Pi will need 5V and 5A, so a dropdown voltage converter is used. The Raspberry Pi is powered directly via the voltage pins, not the USB, having it’s own LiPo battery.

The software stack:

1. Ardupilot

2. Mavlink

3. Raspbian OS

4. Hailo 8 SDK, installed on the raspberry Pi.

5. Custom Python script, using SCDepth V3 algorithm.

The F405 Ardupilot setup.

While the F405 firmware from Ardupilot comes pre-loaded with all the necessary parameters already setup for flying the drone, they are not really suitable for this use case. PIDs were changed, to make the drone behave better. Here are some examples (new parameters after → ), I won’t get into details on PID tuning:

ATC_RAT_RLL_D: 0.003600  -> 0.001
ATC_RAT_PIT_D   0.003600  -> 0.001
ATC_RAT_RLL_P was 0.080000  -> 0.03
ATC_RAT_PIT_P was 0.080000 -> 0.03

Make the drone to behave slower:
WPNAV_SPEED: 1000cm/s -> 100cm/s
WPNAV_SPEED_DN: 150 -> 75
WPNAV_SPEED_UP: 250 -> 125
WPNAV_ACCEL:250  -> 50

The Raspberry Pi setup.

Latest Rasbian OS was used, and the HAILO app suite:

sudo apt install hailo-all
git clone https://github.com/hailo-ai/hailo-rpi5-examples.git
./install.sh

Next step was to create a Python script that was using depth estimation to navigate obstacles.

My first choice for using a depth model was DepthAnything V2, however it proved to be almost impossible to convert to the HAILO infrastructure. Therefore, until I get more time to work of the DepthAnything V2 conversion, I’ve decided to use SCDepthV3, that was already having the .HEF file available with the HAILO infrastructure.

I’ve decided to use a simple algorithm for the drone navigation: split the video input by a 5x5 grid, take depth measurements for each cell and decide the direction based on this. There are multiple drawbacks on this algorithm, but my goal was to build an MVP, work on the drone controls and then improve it.

Before actually testing the drone in real world, I’ve decided to build a Hardware/ Software in the loop simulation.

The simulation

This is where things got a little bit complicated.

I’ve decided to use FlightGear to simulate the drone and stream it’s output directly on the Raspberry Pi/HAILO board. The Python app will take the stream input, convert it into drone commands and then send it back to the FlightGear sim.

This is the setup:

• Ubuntu VM, running under VirtualBox on a MACBook Pro

• FlightGear3D

• OBS for capturing the FlightGear3D window and streaming it to the HAILO app

The FlightGear setup:

For installing it: 
sudo apt-get install flightgear

For using it: 
Cd ardupilot/Tools/autotest/
./fq_quad_view.sh

Some configs that needs to be changed: 
Disable the debug text: 
Arducopter-set.xml remove -> <nasal> -> debug text

Disable the drone rendering: 
Edit fg_quad_view.sh
--prop::/sim/rendering/draw-mask/aircraft=false

Usage: sim_vehicle.py -v ArduCopter -L Cluj --enable-fgview  —out:udp:192.168.68.100:14550 -V ArduCopter --osd

192.168.68.100:14550 -> this is the IP address for the Raspberry Pi/HAILO board.

-L Cluj is a custom location I've defined, for the CLuj airport.

OBS needs to be started and the FlightGear window to be selected:

There are some more configs to be done with OBS:

OBS settings: 
Service: Custom
Service: rmtp: //localhost/1935:live
Stream key: flighgear

For the Python drone control script, many HAILO config files need to be done:

• Change the resolution of the input stream, to the one of the SCDepth model

• HAILO update to remove the preview window

• Modify the Hailo Pipeline to accept rtsp stream input, in depth_pipeline.py:

    elif self.source_type == “rtsp”:
              source_element = (
                  f”rtspsrc location={self.video_source} name=src_0  message-forward=true ! “
                  + “rtph264depay !”
                  + “queue name=hailo_preprocess_q_0 leaky=no max-size-buffers=5 max-size-bytes=0 max-size-time=0 ! “
                  + “decodebin ! queue leaky=downstream max-size-buffers=5 max-size-bytes=0 max-size-time=0 ! “
  
                  “ video/x-raw, format=I420 ! “
              )

In the end, the python drone control script, will be called like this:

python basic_pipelines/depth4d_mavlink.py  --input rtsp://192.168.68.107:8554/live/flightgear --arch hailo8 --use-frame

Where 192.168.68.107 is the IP number for the FlightGear Ubuntu machine. 

To connect to the sim:

# ---------------- MAVLink Setup ----------------
master = mavutil.mavlink_connection(’udp:0.0.0.0:14550’)
master.wait_heartbeat()
print(”Connected to system”)

I will not get into details on the actual drone control script, however, apart from the direction decision module, it uses MavLink commands to send commands to the drone and some smoothing algorithm to prevent too many unneeded changes of directions.

Here is a sim example. The drone takes off, it will detect obstacles ahead and will avoid them. After it determines, based on the depth of field, that no objects in front of it, it will resume flying straight. This can also be adapted to waypoint navigation.

Conclusions and thoughts for improvements:

• Depth values are highly dependent on lighting conditions. The depth value where the drone decide to change the flight path is hardcoded in my script. I have some ideas on how to improve it, for later.

• When flying forward, drones will rotate around their pitch axis. This will mean that the camera will have a different context based on the speed and pitch angle of the drone. This can be resolved by using a gyro stabilized gimbal, that will always keep the camera pointing straight, no matter the drone orientation.

The flight

On the third flight, the drone decided to go fully rogue, and crash on the roof of my house :). The cause was some bad PID settings. Weaknesses in the frame were corrected in the version 2.0.

The Pi was also destroyed in the process, so I had to buy another one.

Version 2.0.

I’ve decided to build a better landing gear, to house the Raspberry Pi & Hailo 8 boards, while also being able to better absorb hard landings shocks.

Also, I have changed the camera to the module 3 camera, with auto FOV. And, after doing a custom Ardupilot firmware package (*the F405 have only 1MB of flash) I’ve managed to enable the camera stabilization around the pitch axis, using one 5V servo. .

Script was also updated to handle variable speeds when approaching obstacles and better takeoff procedure.

In the next post I’ll share the flight video.

The budget for an IT project is usually made out of personnel costs (as in human resources), NRA costs, CapEx (e.g. perpetual licenses) or OpEx costs (e.g. AWS EC2 or Azure VMs). Based on my previous experience, the bulk of the costs are comprised into the human resources.

We start by planning the project budget, the so called BAC (Budget at completion).

For the human resource, we can have multiple types of contracts, that needs to be differentiated. For this example, we’ll have monthly payments (usually full time jobs) or daily rates (usually contractors).

Other types of budgets can be added: NRA, OpEx or CapEx. All of them should be taken out of our initial project plan.

From the project schedule, we need to use the estimated length of the project. In our case, the project will span for 30 sprints.

We compute the estimated costs per each sprint, until the estimated project end, including resourcing, NRAs, etc.

We add them together, including a contingency between 10-20%, and we have our BAC value.

On our project schedule,, we’ve already reached Sprint 14 and we know we’re behind schedule. What about the costs?

Out of the BAC sheet, we compute the data until Sprint 14. This will be our PV - planned value for Sprint 14.

Actual costs (AC) needs to be computed after each sprints has passed, and the team delivered some product increment.

This is how our costs looks after Sprint 15:

We can see we have a 42700 euros difference between our plan value and the actual costs.

We can add this data into some charts:

Using this additionally to the project schedule data, will give a very good overview on our project status.

By mid project, our project is delayed and running over budget, just like a regular project.

The result was over-boositng, while having -30 degrees of ignition advance. While I didn’t knew at the moment, the engine lost compression on the front rotor, due to apex-seals warping because of the high temperature (probably over 1200C, the EGT probes stoped working).

The mishap happened also because I didn’t properly set-up the engine protection functions in the Haltec Nexus R3 ECU. Lesson learned the hard way.

Even with one and a half rotors, the car did a respectable 407HP and more than 500 Nm of torque at one bar of boost. Not bad for a 1.3 liter engine!

The rebuild process:

The compression numbers clearly indicated warped seals or flatten seals springs. Therefore, before opening the engine, I bought new apex seals from Goopy, new corner seals, and new springs for the apex seals, side seals and corner seals.

Engine was removed from the car:

Disassembly began:

Front stack removed:

Engine was all ok, except the bad front rotor apex seals

Cleaning the RTV and carbon deposits took around one hour.

And then, the assembly process began. The side-seals tolerances were re-checked to have 0.1 mm.

First the front rotor:

And then the rear one:

The most complicated issue is fitting the middle plate, as you have to lift the e-shaft.

Fitting the flywheel:

Fitting the front stack:

And then the oil pump:

After properly tightening the whole assembly to the torque indicated by the book, end-play is measured.

Next step: Dyno time. Again.

These were the main specs I was looking for:

• Rear-wheel drive.

• At least 200 HP at the wheels in stock form.

• A solid chassis that performs well even before modifications.

• Affordable enough that it wouldn’t be financially devastating if something went wrong on track.

• Comfortable enough for daily driving, not just a weekend toy.

• Simple enough to service myself, without requiring specialized tools or expensive maintenance.

What options I was considering

• Porsche Cayman → While first models are pretty affordable, engines could fail because of the bore score issues. Didn’t want to go through the process of repairing it myself. Same issue for the Boxter.

• Honda S2000 → this would have been my first choice, if not the high prices for a good model. I still might buy one, but not use it on the track.

• Mazda RX8 or the Miata MX5→. My choice was the RX8, it ticked all points in my list. The MX5 was under-powered, and I didn’t fit in any of them properly (the NC was the best from this POV).

• Subaru BRZ/ Toyota GT86 → I didn’t find it any better than the RX8, but they were more expensive.

Why the Mazda RX8?

• The Mazda RX-8 stood out as a great option for what I had in mind.

  First of all, it has one of the best chassis designs found in a road car. The chassis is extremely rigid, rated at around 30,000 Nm per degree of torsional stiffness, which gives the car excellent handling characteristics. It also features a five-link rear suspension and double wishbones in the front, a setup that’s well known for delivering precise and predictable handling—perfect for track use.

  Another advantage is that it’s a four-seat coupe, which makes it surprisingly practical compared to most sports cars in this category.

  The layout is also ideal: a front-mounted engine pushed as far back as possible, combined with rear-wheel drive, resulting in a very balanced weight distribution.

  From the factory, it comes with 231 HP, which is already a solid starting point.

  Eventually, I managed to find one that checked most of my boxes: zero rust, several useful upgrades already installed, but with a somewhat tired engine.

  The upgrades included:

  • Coilover suspension

  • Upgraded ignition coils

  • A larger radiator

  • And a few other small improvements

  So while the engine needed some attention, the car already had many of the modifications I would have added myself.

Initial price: 5500 euros.

I’ve decided to repair the rotary engine, and all new seals (apex, side, corner seals), all O-rings, new oil injectors, etc were changed. 8000 km after the rebuild, and quite a few track days, the engine is in good health, having around 7.6 bar compression.

This was my 5-th rotary engine build, so no major issues with it.

Here it is:

Adjusting the side seals tolerances is crucial for a good compression.

The apex seals:

Right before closing the engine:

Measuring the end-play:

Installing it in the car:

Price for the engine rebuild: 2500 euros

New brakes were added, including braided brake lines.

Price for the brakes: 650 euros.

I’ve decided not to go for a full race spec coil-over, but rather use the K-Sport that was already on the car. The spring rates for it are best suited for daily driving and occasional track driving and it’s one way adjustable. Due to the soft spring rates,, I’ve decided to install thicker anti-roll bars.

Price: 500 euros

One thing I didn’t like about the RX-8 was the driver seat and overall driving position. It never felt quite right, especially for track driving.

To fix that, I decided to install a Cobra Nogaro seat along with a SpacerShop steering wheel spacer. This combination allowed me to achieve a much better driving position.

With the new setup, I can now comfortably fit in the car while wearing a racing helmet, and the improved seating support keeps me properly planted during hard cornering instead of sliding around in the seat.

Despite being a motorsport-oriented seat, the Cobra Nogaro is surprisingly comfortable for daily driving, at least from my point of view, so it works well for a car that needs to handle both track days and everyday use.

Price for the seat and the steering wheel spacer: 1100 euros.

Finally, the tires. My choice was to use the Continental SportContact 7 and it’s one of the best tire for daily-ing the car and also track driving, in both dry and wet.

In track day mode, I run the car without the passenger seat and rear seats, any weight savings matter.

Conclusions:

The car can do around 1:54.xx on Transylvania Ring, with street tires and it’s very safe and pleasant to drive at the limit.

Total costs:

And the onboard video, on the track:

Added bonus:

I can use it to drive 3 kids from school (including their back-packs) :) .

Subscribe now

Let’s assume you’re starting a project and need to provide an initial estimate for costs, resourcing, and planning. The Product Manager (PM) or Product Owner (PO) will create the project’s epics and add high-level descriptions.

Next, the Tech Lead and/or the development team review these epics and estimate them at a high level using story points. This step produces the first rough estimate of the overall project scope and effort.

Tools such as Jira—or any other task-tracking system—can be used to create and manage these epics. Most of these tools also allow you to export the data to a CSV file for further analysis or reporting. The details of how to perform this export will not be covered here.

Once the project is approved and development begins, the epics scheduled for implementation are broken down into multiple user stories and tasks. This is where the “magic” will happen.

1. You can use the story-level estimates to compute the adjusted estimate for each epic.

   To set this up in Jira (or your chosen tracking tool), for your Epic issue type, you’ll need to:

   • Create a custom field to store the initial high level estimates (you can call it Tech Lead SP).

   • Use the Jira Story Points field to track the total story points of all its child stories.

   You can either update the Story Points field manually for each epic whenever new estimated stories are added or stories are closed or you can set up Jira automation to update the epic’s Story Points field automatically whenever a child story’s estimate changes. In Jira, you can configure this under:
   Space / Project Name → Space Settings → Automation → Create Rule.

   1. 

2. For the epics that are actively being worked on, set their status to “In Progress”. This helps distinguish them from the remaining epics whose estimates have not yet been refined based on their child stories.

So: epics with “Open” status will have the initial high level estimates and the ones with “In progress“ status will have estimates based on the sum of their child stories.

How to put all this together?

First, you need the total amount of SP, based on the initial estimate (SUM of the Original estimate (Tech lead SP)).

Then you need the actual value, based on the SUM between the 2 estimation columns, but for the “To do“ Epics using the original estimate and for the “In Progress“ Epics using the updated estimates.

=SUMPRODUCT((B5:B79=”To Do”)*(E5:E79)) + SUMPRODUCT((B5:B79=”In Progress”)*(D5:D79))

You can then compute how many sprints you’d need to complete (based on how many working days/ sprint you have), and a start date. You can add more data, like vacation days, bug fixing sprints, bank holidays, etc. to make this as accurate as possible.

The release date can be computed with the Workday formula, where you need a start day for your project and the total days needed for the project execution.

=WORKDAY(N6;J9+J10;3

Showing all this in a chart

First, prepare the data table:

• The Committed and Delivered columns are used to track the team progress per sprint and compute the team velocity based on them.

• The Ideal Estimate is used to compute the estimated optimal release date. It is computed based on the team velocity.

• The Actual remaining is computed based on the Delivered values for each sprint.

  • As you can see in the chart bellow, the gray line will show that the project is delayed.

• The Actual updated will show the updated burn down line, based on the Actual remaining values (the dashed line in the chart).

And the final result, showing we have a delay in our project delivery, compared with the initial estimates:

This can be updated with fresh data (e.g. Jira CSV export) once per sprint, to see where the project stands, compared with the original estimates.

In the next post, I’ll expand this to track the project budget (budget at completion/ planned value vs. actual cost).

Subscribe now