Continuing 3D Case Design

The next step in designing the case was adding the screw hole for the universal tripod screw. I found that the thread I would be using was a 1/4-20.

After a bit of research I also found that the best way to get the screw hole to fit was to use a 1/4-20 heat-set insert. How it works is you heat the insert (I will do it with a soldering iron) so the surrounding plastic softens and flows around the insert. Once cooled, it will provide strong threads that I can screw into.

After looking for a bit on Mouser I found a 1/4-20 heat-set insert that would work fine. Its mounting hole size is 8mm so I made a hole on the case bottom with a 4mm radius.

Heat-set insert: https://www.mouser.es/ProductDetail/RAF-Electronic-Hardware/2520X312C?qs=DPoM0jnrROVGMGB%252BYFYT%252BA%3D%3D

Next, I designed a slot across the width of the case base so that the PCB could slot in vertically. But this alone wouldn't be enough to keep the PCB stable, so I added two mounting holes on it. And two respective holes (1.1mm radius) on a small strip on the right inside of the case. These two would give the PCB a bit more stability. Originally I had designed just a small 3x1mm (or similar) pad with only one mounting hole on it, but I realized that this would be very likely to break and would not give it much stability.

Original:

Updated:

I still didn't feel the PCB was going to be too stable so I needed to add a firm way to secure the PCB. Before I could do this I gave the case a cover and made the screw holes aligned with ones on the case. Lastly, I added the final touch, which was two strips on the case cover aligned with where the PCB will be positioned, so it could slot in. To achieve this I also had to make the PCB a bit taller, because otherwise the Pi would be in the way.

PCB:

Cover:

At the start of the journal I was completely unfamiliar with FreeCAD, but over these changes I got a better feel for it and now I feel ready to make those final cutouts to the case.

P.S. I pushed my 3D case design changes to GitHub: https://github.com/adrirubio/odins-eye

End:

Starting 3D Case Design

The last step before building the project is designing the 3D printed case. The first thing I researched into was what tool I could use to build the 3D printed case. After looking at different options I came across Fusion 360, but when I went to download it I found that it wasn't very Linux compatible (the operating system I am using). To get it running on Linux I would have to run a Wine script or run a Windows VM, both options are kind of a headache.

So I looked for a different tool. And... I found FreeCAD. Here are some its perks:

• Native Linux support
• Free and open source
• Modular & extensible
• Active community

The only downside is that it's a bit less beginner friendly compared to Fusion 360. I downloaded FreeCAD's AppImage for Linux and gave it running permissions. The bad thing about AppImages is that there is no app on the computer. It's just a file that you can run from the terminal or inside files. To solve this problem I made a simple script in .local/share/applications to create an app for FreeCAD. It used a logo I found and downloaded online as the app logo.

Once I had downloaded FreeCAD and created the app I did some research to get familiar with 3D design and FreeCAD. I soon got the basics down, created a new project and added a rectangle in the sketcher. I modified the properties to match the PCB which will be placed sideways on the horizontal (long) side of the case. I made the length 102 mm and the width 70 mm.

Then I extruded the rectangle and made it hollow with an outward wall thickness of 3 mm. Next, I made the inside corners of the case filleted. Lastly I placed the M5 holes for the case cover in the four corners that I had filleted and also added a fillet to the side and bottom corners.

All this took longer than it should have because I had some difficulties here and there. One difficulty was that I couldn't manage to get the four holes that the cover screws onto fully constrained and it kept saying 2DoFs. Another problem I ran into was that the holes didn't end up being fully symmetrical, so I had to go back and fix the sketcher. Eventually I fixed all these problems and I now have the basic shape for the case. The next step is giving the case all of its cutouts, screw holes, cover and more.

Proof Of Concept (POC)

It is extremely satisfying to find that something that you designed actually works. So, yes, the TF-Luna, together with my measurement code, can calculate the speed of cars, people and bikes. But it only started working reliably a bit ago because I ran into a few problems along the way.

The first code I worked with was the code I had already pushed to github in the last journal. By the way, the code for the arduino was created by Claude. I have experience with C++ but I would have to take the time to get the TF-Luna up and running with the design and it would probably work worse than what Claude built. This is why I chose this approach.

I went outside to the road in front of my house and prepared the sensor, set it at 20 degrees, and connected it to the computer. When I ran the code and ran past the sensor, it sometimes output a speed and sometimes didn't. And even when it output a reading it didn't always feel accurate. It was clear I had to make some changes. The first change was to update the detection lock. Sometimes the system locked so I added a 5-second timeout. I also updated the hardcoded timing constant. It used a hardcoded time of 0.05s but actual measurement times varied based on I2C communication, delays, etc.

Slowly but surely, it started getting accurate readings. It still wasn't perfect but it was getting there. Some other changes made were:

• Lowering signal threshold: 100 to 20
• Removed direction checks
• Reduced min distance change: 8cm to 5cm
• Replaced hardcoded timing with actual timing measurement using micros()
• Accepted 1 valid reading per burst instead of requiring 2

Next, I got my bike out and tested the sensor. The outputs were very convincing because if I went a bit faster it would get speeds that looked quite correct. Lastly, my dad drove the car past the sensor and the lidar outputs matched up with the speed at which he was driving.

POC pictures:

Finalizing Speed Measurement Method And Updating PCB Design

I told Claude to replicate python least squares fit code in C++, to run it on the Arduino IDE. Then I tried moving past the sensor at different speeds. The outputs weren't very reassuring. It sometimes said 200km/h and others said 30km/h, so there was a big difference and none of them were accurate.

I had to make a change. I found some problems with the least squares fit measurement method. The first problem was that processing was very slow, it had to take lots of measurements and would take around 0.2 seconds. I later calculated that a car travelling at 50 km/h moves around 2.78 m every 0.2 seconds. That’s fast enough that the laser will likely end up the side of the vehicle instead of the front. This totally breaks the math because a car is basically just a moving rectangle. While the front is moving towards you, the side is esentially a wall moving past you. To the sensor, that side panel looks like it isn't getting any closer, which feeds faulty data into the least squares formula and ruins the result.

The least squares fit also required a lot of measurements to be accurate, around 20 in the code, which put a strain on the processing speed. It was also way less accurate for smaller objects like bikes because the sensor tends to flicker between the actual object and the background. Even without those issues, if there was just a tiny bit of random noise in the data, the math would try to fit it anyway and give you an inaccurate line.

In the process of trying to find solutions to these problems, I came across the option of using two TF-Lunas, which I actually have. At first look, it seemed like it would make the data much more accurate. But I later decided that it wasn't worth it. At most, the distance between the two would be 5cm (because I wanted them both on the same case). I would have to rewire the schematic, route the PCB for another socket, and buy a new piece. The only advantage of the second sensor would be getting more readings in less time. I also decided that it wasn't worth it because I want the speed camera to be an affordable option.

Finally, I came up with a new idea: 'Burst - Gap - Burst'. The speed camera is placed at a 20 degrees angle facing the road. The TF-Luna has a baseline distance. When this baseline changes the TF-Luna will take 3 quick measurements. If any of these has a large difference compared to the other two, or gets too close to the baseline it is removed. Then these readings are averaged. This way if there was any noise in any reading it doesn't affect the end result as much. Then we pause for 0.03 seconds so the car can advance a bit. Lastly, another three measurements are taken and averaged. To get the vehicle speed, you subtract the finish distance from the starting distance and divide by the time (0.05s between average points) then the cosine of the 20-degree angle is applied to get the correct speed.

This should be very accurate because it only takes 0.07s, the car would have to be travelling at around 120 km/h for the readings to start getting inaccurate. It reduces the impact of noise on the finished speed and should work great on small and big objects.

Another thing I looked at was how to get the system perfectly placed at 20 degrees relative to the road. I thought about finding an app on the phone and rotating it until it said 20 degrees, but I decided that wasn't a good idea because it wasn't standalone. I decided to add an accelerometer/gyroscope sensor to the PCB. I wired and routed it with a custom footprint for the 8-pin connector.

Amazon: https://www.amazon.es/-/en/GY-521-MPU6050-Accelerometer-Gyroscope-Transducer/dp/B07BVXN2GP/
Mouser: https://www.mouser.es/ProductDetail/TE-Connectivity/535541-6?qs=ZDXmSm13592BeyHKSexOiA%3D%3D

Checking Parts And Connecting The TF-Luna

All the parts for the PCB arrived, so I checked them all to make sure that they were correct. Thankfully all of them worked as intended. I bought three sockets for the TF Luna to see which was the best fit. All of them connected, so I will use the 0530470610‎ because it matches the footprint I've got on KiCad.

At first it seemed to work because it started printing distances, but once I looked closer, I found that the data was not accurate at all. It was reporting about 20 cm when the nearest wall was actually around 2 meters away.

After trying to fix the code and many wiring changes that didn’t solve the issue, I switched to using I²C. On the TF-Luna, I²C requires connecting the additional GND pin (pin 5). I used a test script I found online, and it worked perfectly.

I think the UART was dropping bytes/frames because it was running at a high baud rate. I²C works better for this application because it communicates in controlled, master-initiated transactions rather than a continuous high-speed stream like UART.

Once I knew I²C worked better than UART, I updated the PCB schematic and routed the new GND trace in the PCB Editor. I also adjusted the PCB width from 105 mm to 102 mm because JLCPCB adds $24 if the board is larger than 102 mm in either width or height. This is why the last quote came out to $32. Now it’s much cheaper.

Final Changes To The PCB

I added some final changes to the PCB before actually downloading the Gerber files. The first change I made was to add a User.Comment addressing the USB-C receptacle clearance violation in the DRC report.

Next, I added some text to the PCB with the title, date, and my name. I also created a simple logo for the board using Sora and then converted it using KiCad's image converter. I placed the logo next to the text. It looks better now.

Lastly, I double-checked everything, including running a final DRC. I downloaded the Gerber files and made sure to correct the settings. I converted all the files into a ZIP file and uploaded them to JLCPCB to get an instant quote.

The PCB is looking practically finished!

Front:

Back:

JLCPCB Quote:

Routing The PCB

Today the TF-Luna arrived with all the correct cables. Yesterday I bought the parts for the PCB/carrier board to confirm the footprints were correct, and they should arrive in a few days.

The first change I made to the PCB to get started with the wiring was to define the board's copper fills. When I added the fill zone I selected GND to be the default net that connects to the leftover copper. This way I have all my GNDs wired.

I did some research on how to route the PCB, and soon I was confident to give it a shot. I started wiring from left to right on the PCB layout. First the oled connector, then the tf-luna connector, later the LED, and lastly the resistors and the USB-C. All of these were connected to the Pi header.

In essence, wiring itself isn't all that difficult; the hard part is deciding which layer a trace should go on and when to place vias and when not to.

After routing the board, I ran the DRC to check rule compliance. I got a few hole clearance violations and two starved thermal relief violations, but none were too serious. I fixed the thermal violations and adjusted the DRC rules to 0.20 mm to match JLCPCB’s specifications, while the actual clearance on the PCB remains 0.194 mm, which is close enough that the difference is minimal.

Once I finished routing, I decided to improve the part labels and make the PCB a bit more readable. I made a few small changes here and there and almost wrapped up the PCB design.

Front:

Back:

Starting PCB Design

Before I could start designing the PCB, I made sure to correct the board setup. I did this by importing the settings from the JLCPCB_1-2Layer board from the following repo:
kicad_templates

Another setting I decided to change was updating the cursor from small crosshairs to full window crosshairs. Once I had completed these steps I was ready to insert the footprints into the pcb editor.

At this point I watched a few tutorials that gave me a better idea of how the pcb editor works. One thing I did was modify the Raspberry Pi zero 2 W header footprint to have an outline that represents where the actual pi zero sits. I updated the rule area of the header to keep out pads and footprints, and I used the "Create Lines from Selection" option to give it an outline.

At this point I needed to stop and think. I had all the footprints but I needed to find a compact way to arrange them, allowing every part to be near the desired position, while keeping few crossover points.

After lots of trial and error I found a design that I was happy with. Here are some reasons why I went for this design:

On the front side:

• The Pi has good placement.
• The TF-Luna connector is on the left, which is where it will go.
• The USB-C receptacle is centered on the edge.

On the back side:

• The power-on LED is centered and on the right, which is where it will go.
• The 7-pin oled connector is on the right, which is where the oled will go.

I added the outline for the board with a height of 50 mm and a width of 105 mm, it fit nicely.

Front:

Back:

Assigning Footprints

I've successfully assigned a footprint to each part in the schematic and found a corresponding one in either Mouser or DigiKey. Some parts were easier to find than others, but I’m pretty sure they all match.

I started with the green power-on LED. I looked on Mouser for one that could work and found this one:
https://www.mouser.es/ProductDetail/Lumex/SSL-LX5093GD-125?qs=sGAEpiMZZMvVL5Kk7ZYykVwAM0Y%252B7BnPXhjUQ8KQTN8%3D

It has a forward voltage of 2.2V and a forward current of 25mA and because I know that the input voltage is 5V, I calculated that the resistor needed to be around 112 ohms so I decided to buy a 120 ohm resistor. I also changed the resistor in the schematic to a 120 ohm because it used to have a 1K resistor:
https://www.mouser.es/ProductDetail/YAGEO/MFR-25FRF52-120R?qs=oAGoVhmvjhydMkhPrSnrfg%3D%3D

Next, I looked for the two resistors I needed for the USB-C receptacle that are both 5.1 kOhms. I chose the same type as the 120 ohm one, the only difference is that the resistance is 5.1 kOhms:
https://www.mouser.es/ProductDetail/YAGEO/MFR-25FBF52-5K1?qs=oAGoVhmvjhxSFmIFo3hmQQ%3D%3D

At this point, I decided to look for the correct USB-C receptacle, and here I had to look harder because there were many to choose from and many that wouldn't work. It had to be USB 2.0 and have 16 pins. In KiCad's footprint editor I settled for the USBCReceptacleGCTUSB4105-xx-A16PTopMnt_Horizontal. After a bit of searching I found the exact model on Mouser, the same USB4105-GF-A and made sure it was right by looking through the datasheet:
https://www.mouser.es/ProductDetail/GCT/USB4105-GF-A?qs=KUoIvG%2F9IlY%2FMLlBMpStpA%3D%3D

The next footprint I looked at was the Conn01x07Pin, which is the socket for the oled. I didn't have to search much and found two that would work. After checking with chatgpt I decided the best option was this one:
https://www.mouser.es/ProductDetail/TE-Connectivity/5-534237-5?qs=GYgf5PdsjzmjeTI%2Fz24JQA%3D%3D

Next, I looked for the pi zero's 2x20 socket and found a similar one to the oled's socket above (also from TE Connectivity):
https://www.mouser.es/ProductDetail/TE-Connectivity/7-534998-0?qs=xDp7PGUNC%252BvXOzVmHiDmow%3D%3D

I also looked for the pin header that I could solder onto the pi zero and that would mate with the header above. I looked into the documentation and found that the AMPMODU MOD IV series mates with the AMPMODU MOD II series, which corresponds to this pin header:
https://www.mouser.es/ProductDetail/TE-Connectivity/2-826942-0?qs=xF5SkmKSM77XAsaLR3kF3A%3D%3D

The last item I had to find was the connector for the TF Luna. This was also the hardest to find. I looked into the TF-Luna’s documentation and it didn’t mention what connector it comes with. After looking at some reddit posts and forums I found that it was either a JST or a Molex Picoblade. After a bit more research I still wasn't convinced. I decided to unscrew the back (pcb) of the old TF Luna I had. Then I could get a closer look at the connector. For this one, I went on DigiKey and found three that might work. One is a Molex Picoblade, which I believe is the same (or at least very similar) as the connector on the TF-Luna. The second one is an Amphenol ICC (FCI) which looks very similar, and the last one matches the model I used in KiCad’s footprint editor. Because they are all very cheap, I am going to buy all three.

First: https://www.digikey.com/en/products/detail/molex/0532610671/699098
Second: https://www.digikey.com/en/products/detail/amphenol-icc-fci/10114828-10106LF/2658933
Third: https://www.digikey.com/en/products/detail/molex/0530470610/242857?s=N4IgTCBcDaILIHsA2BTAHgAgKwGYAMALAOwC0eAbAIx4gC6AvkA

Wiring the Schematic

I started by laying out the different parts of the project, placing the inputs and power connections on the left, the processing in the middle, and the outputs on the right. This setup made it easier to visualize how data and power would flow through the system. Before wiring the sections, I spent some time researching and watching a few tutorials to make sure I understood everything. I also looked at a few example schematics to double-check pin configurations.

For the plug, I found that I would actually need a USB-C receptacle because I just needed it for charging the circuit. I only connected the necessary power and ground pins and included the proper CC resistors for charging negotiation, then moved on to the 6-pin connector.
The 6-pin connector was fairly easy because, using the pinout diagram from the TF-Luna we had bought, I connected 5V, RXD, TXD, and GND. The last two pins aren't used in this model.

At this point, I connected 5V, GND, RXD, and TXD to pins 2, 6, 8, and 10 respectively on the raspi's GPIO header. I moved on to the 30-pin connector, and here I had some problems. I originally wanted this 30-pin connector because it has no extra PCB border and is great for custom enclosures. The problem is I would have to connect around 20–25 of the 30 pins.

I would also have to add capacitors with different values and deal with a large number of pins. This is highly error-prone, and iteration with hardware isn't quick. In the end, I decided to delete the 30-pin connector and use the 7-pin connector, which would represent a header for an OLED like this:
https://www.amazon.es/-/en/HiLetgo-SSD1331-Display-3-3V-5V-Colorful/dp/B0813BB3K7

I wired this 7-pin connector and, lastly, wired the LED, which I decided would be green, using a 1 kΩ resistor. Once everything was wired, I added some no-connect flags on a few unused pins, and a small note on the USB-C. I finished by fixing two or three warnings from the ERC.

Starting The Schematic

The TF Luna arrived, but because of an ordering mistake, it didn't have the right cables so I couldn't connect it to the breadboard. I could buy the cable separately, but I found one that has all the right cables and is quite cheap, so I decided to buy it. Unfortunately, it will take around two weeks to arrive, so I decided to get started with the schematics.

TF Luna: https://www.amazon.com/Wishiot-TF-Luna-Single-Point-Terminal-WiFi_Lora_32/dp/B09PZ559ZB

This is my first time designing schematics, so to begin with, I looked at some of the guides Blueprint offers. I began by trying EasyEDA. Created an account, started the project, and got a better idea of what components I needed. I started inserting some of the components into EasyEDA. At this point, I needed to get the basics down so I looked at some tutorials. One that helped a lot was this one: https://www.youtube.com/watch?v=R_Ud-FxUw0g

After these tutorials, I thought that I might also have a look at KiCad, so I downloaded it, created the odins-eye project, and having a better idea of what I was doing, I started to get a good feel for it. After following this tutorial for a bit: https://docs.kicad.org/6.0/en/getting_started_in_kicad/getting_started_in_kicad.html, I decided that I was ready to begin designing the speed camera.

The first thing that I looked at was the raspi's 40 GPIO pin header (2x20). Because there wasn't the exact model I needed, and also because I needed to get familiar with KiCad, I decided to design my own. Which I am quite proud of.

Next, I inserted a 6-pin connector which represents the JST connector. I also added the USB-C plug, a 30-pin connector which represents the ZIF connector for the 0.96 oled, one LED with a corresponding resistor, and two more resistors for a voltage divider to measure the battery.

This is where I’m up to so far:

Updated Speed Measurement Method

I realize that measuring the speed of a vehicle from a video is extremely difficult. There are so many variables that come into play. Now I see how silly my idea was. Here are some of the things that make my original idea so challenging:

• You need to know the real-world distance the car actually travelled
• The video's timing is often unreliable because the frame rate isn't constant
• The camera's angle and lens bend the image

So... I decided to have a long chat with Gemini about other options. I looked into the doppler radar but realized that for it to work I would also need an amplifier, a sperate analog circuit, because the signal would be too weak and noisy for the raspi to read directly. I also looked at the microwave motion sensor but that didn't work because it would detect 360 degrees, so it would also trigger objects moving behind it.

More Messy Iteration:

Then I had a eureka moment; I realized that maybe we could somehow use the TF-Luna lidar to measure the speed of vehicles. Very soon I realized that this could work, here are some reasons why:

• It uses a narrow laser beam, so it will only detect cars passing in front of it
• It's electronically simple, you can connect it directly to the raspi's GPIO pins (via I2C)
• It has very low power consumption and won't put any strain on the power bank (much more efficient than the camera-only method)
• It's extremely fast, at 100Hz, the sensor can check the distance 100 times per second
• It's very compact and it was already in the original design

https://www.amazon.es/-/en/Benewake-TF-Luna-Compatible-Pixhawk-Raspberry/dp/B0DKCSF8C5

Now I would like to briefly explain what a lidar is and what it does. A lidar works by shooting a tiny beam of light and measuring exactly how long it takes for that light to bounce off an object and return.

My first idea on how to get speed was to use the Pythagorean theorem, to use it there would be one fixed distance in the code (a) the perpendicular distance to the side of the road, and we would use the lidar to measure the diagonal distance to the car (c). Using the Pythagorean theorem we would solve for the car's true position along the road (b = sqrt(c^2 - a^2)). By taking two of these measurements in say 0.1 seconds, we could determine the distance the car travelled and divide by the time to find the speed.

The only problem with this method is that it wouldn't be fully drop-and-go because you would have to make sure that (a) is the same in the code as in real life and if not change one of the two. What I am looking for is a completely stand-alone speed camera that starts working without having to be placed at any specific distance.

Knowing this I looked into some other options and found a very promising one; the least squares fit option. In this one the lidar is placed facing the road at roughly 45-degrees angle (I plan on designing a lock on the case). The lidar sends a distance reading every 0.1s until it detects an object in its path, once this happens it starts sending distance readings every 0.001 or 0.005 (I haven't decided yet) and because the object is getting closer at an angle, the distance will decrease as long as the lidar isn't hitting the side of the vehicle. Then it fits a straight line through the readings. The slope of that line tells how fast the distance is shrinking. Because the sensor is tilted, it divides that slope by cos(θ) to get the real speed of the object moving across its view.

To prove this concept, I built some simple example code in python (which I might have to replicate in C++ if speed is a problem) to test the basic idea. I would ask chatgpt to generate a set of distances and the corresponding signal strength and I would test it, honestly I think this might actually work:

Code:
https://github.com/adrirubio/odins-eye/blob/main/firmware/speed-calculation-code.py

To see how this works I bought a TF-Luna lidar to try both of these methods out. It still hasn't arrived but when it does I plan on seeing which of the two speed measurement methods works better and do a proof of concept.

Research and Project BOM

I started brainstorming how a DIY speed camera could be possible 3 days ago, and I am quite content with the basic idea I have after a few hours of project and parts research. My original idea was for the speed camera to have a stand that can rotate and follow vehicles while they pass, but I quickly realized that this would overcomplicate the project too much because I would have to design a stand from scratch. I settled for a universal stand where the speed camera and sensor are inside a 3d-printed case that screws onto it. I also wanted a touch screen where you could do some sort of onboarding every time you turned the speed camera on, but this idea was also quickly discarded because the onboarding would be unnecessary and small oled displays usually don't have touch capabilities. I needed the project to be standalone because my idea was for it to be in front of my house and gather data from the passing vehicles. I thought that having a battery holder and a slide switch to turn on was a good idea, but, after talking it over with my dad we decided that it was a better idea to have a power bank that would connect to the pcb/carrier board inside the case through a type-c plug.

After lots of research and modifying the design several times I ended up with the following base idea that I will build on top of:

The system is controlled by a raspi zero 2w that has a raspi camera module 3, a TF-Luna lidar, and a small, possibly 0,95 inch oled display connected. It works by detecting a vehicle before it passes using the lidar which triggers the camera module 3 to start recording. From the recording it can get the speed using the frames-per-second and distance, it understands using AI what object passed and in the case of it being a car, its license plate. It'll get power from a power bank that can be mounted on top of the 3d-printed case. The lidar and camera will be situated on the front side of the 3d-printed case and on the back will be the oled display and a small green LED that turns on when the pcb/carrier board gets power. Lastly, using the pi's wifi it can send notifications to my phone.

I made the project BOM which you can check out in here: https://github.com/adrirubio/odins-eye/blob/main/bom.csv. I also made some rough sketches with the base idea I have up until now, but none of these are permanent.

Messy Iteration:

Complete Design:

PCB/Carrier Board: