DEV Community: Liam

Robotics Concepts for Beginners

Liam — Tue, 08 Sep 2026 20:18:12 +0000

Introduction: Why Robotics, Why Now

Robotics is everywhere. Over the years we have seen products from the Romba, to Boston Dynamics dog to self-driving cars and now humanoid robots. This robots are made to handle differenet circumstances then a automationous machine in a factory. They go through differenet process to make them into what they are. Using fundamentals and concepts to help shape how each robot works. So weither you are a hobbyist, a student or a merely curious, in this post we will discuss the core concepts of robotics.
Robotics Concepts for Beginners

What Is a Robot, Really?

Oxford diconary defines robot as "a machine that can perform a complicated series of tasks by itself". This is the very basic idea of a robot. Robots can complete tasks that a automatious machines can't do. Robots can think and decide on what they need to do and how to act apon that. So what counts as a robot then? Does a dishwasher count? No, I wouldn't think so. A dishwasher has set programs, it does count if there is 1, 5 or 30 dishes. Maybe a smart thermostat? Well it can detect if a room is colder or hotter then x amount and change accordingly so it must be a robot. Well a thermostat can't tell if the outside world is summer or winter. It can't tell if you the individual is roasting or shivering in their room. It cant't tell if their is people even in the room for there to be a need to be on in the first place. The user still has to control it.

Take a Roomba for an example. A Roomba can clean a house unsupervised at a desired timed. A Roomba uses multiple sensor and trained data sets to learn and understand it's envirnoment. It maps your floor layout and will clean surfaces based on that. However let's say one day you deciede that you want to move your couch or you left a box in the middle of your living room. A Roomba has the ablility to notice that the floor plan has changed and is able to make the decision to go around that object. A user just has to set it up, pick a time and let the robot doe it's magic.

The Three Building Blocks: Sensors, Actuators, and Control

A robot only really needs three things. It needs a way to take in information about the world, a way to physically do something about it, and something in the middle that decides what that something should be. Sensors, actuators and a controller. Every robot you have ever seen is some version of those three parts bolted together.

Sensors are how a robot perceives. A camera gives it sight. An ultrasonic sensor or a lidar unit measures distance by firing out a signal and timing how long it takes to bounce back, which is how your Roomba knows the wall is 30cm away and not 3cm. A bump sensor is about as simple as it gets, it is a switch that gets pressed when the robot physically walks into something. A gyroscope tells the robot which way is up and how fast it is tipping over, which is the only reason a two wheeled balancing robot stays upright at all.

Actuators are how a robot moves and acts. If sensors are the senses, actuators are the muscles. Motors spin the wheels. Servos rotate to a specific angle and hold there, which is what you want in a joint or a steering mechanism. Grippers open and close so the robot can pick things up. On their own they are dumb lumps of metal, they just do what they are told.

The controller is the brain, and it sits between the two. It reads what the sensors are saying and it commands the actuators to respond. For beginners this is almost always an Arduino or a Raspberry Pi. An Arduino is a microcontroller, it runs one small program over and over forever with very precise timing and no operating system to get in the way. A Raspberry Pi is a full computer running Linux, so it can handle cameras, vision and networking, but it is worse at the kind of split second timing that motors like.

So put it together with a robot that stops before it hits a wall. The ultrasonic sensor reports that the wall is 20cm away. The controller checks that number against a rule you wrote, something like "if the distance is under 30cm, stop". The controller then cuts power to the motors. Sense, decide, act. That is the whole loop, and it is running dozens of times a second.

How Robots "Think": Control Loops and Feedback

Forget robots for a second and think about driving down a road. You are not holding the wheel perfectly still. You are constantly looking at where the car is in the lane, noticing it has drifted slightly right, and nudging the wheel back left. Then you check again. That constant cycle of look, compare, correct is a feedback loop, and you run one every time you drive.

Robots do the same thing, and the difference between a good robot and a frustrating one usually comes down to whether it bothers to check its own work.

Open loop control is acting blindly. You tell the robot to drive forward for three seconds and you hope that gets it where you wanted. It has no idea whether it actually moved. If a wheel slips on a rug or the battery is a bit low, the robot has no clue and no way to fix it. Closed loop control is when the robot checks. It drives forward, reads a sensor, sees that it has only travelled half as far as it should have, and keeps going until the sensor agrees with the goal.

You will eventually run into something called PID control, and all it really is is a clever recipe for deciding how hard to correct when you are off target, so the robot does not overshoot and wobble back and forth forever. Do not worry about the maths yet, just know the name so it is not scary when you meet it.

Making Robots Move: Kinematics and Degrees of Freedom

Hold your arm out in front of you. Your shoulder can swing your arm up and down, side to side, and rotate it. Your elbow bends one way. Your wrist bends, tilts and twists. Every one of those independent movements is a degree of freedom, and your arm has around seven of them. That is why you can reach around a corner to grab a mug, and why a cheap robotic arm with three joints cannot.

Degrees of freedom is just a way of asking how many different ways a robot's body can move through space. Kinematics is the follow on question, if I move this joint by this much, where does the hand end up?

Different bodies are good at different jobs. A wheeled robot is simple, cheap, efficient and stable, and it is completely useless the moment it meets a set of stairs. A legged robot can handle rough ground and steps, but it is far more complicated, it burns through battery, and it spends most of its processing power just not falling over. A robotic arm does not go anywhere at all, it stays bolted to one spot and does precise repeatable work in the space it can reach, which is exactly what a factory wants.

If you are starting out, start with wheels.

The Software Side: Programming and a Word on AI

Programming a robot sounds intimidating until you realise what you are actually writing. You are writing the rules for the sense, decide, act loop. Read this sensor. Compare it to this number. Turn this motor on or off. That is it. The complexity comes later from stacking a lot of small rules on top of each other.

There are a few sensible places to start. Block based coding, the Scratch style drag and drop stuff, is genuinely good for getting the logic into your head without fighting semicolons. Python is where most beginners land next, because it reads almost like English and both the Raspberry Pi and most hobby kits support it. ROS, the Robot Operating System, is the thing to graduate toward, it is a framework that handles the messy plumbing of getting sensors, motors and vision talking to each other on serious robots.

One thing worth clearing up early. Not every robot uses AI, and the two words are not interchangeable. A line following robot is following a fixed rule you wrote by hand, if the left sensor sees dark, turn left. It will do that same thing perfectly forever and it will never get better at it. A robot using machine learning is different, it has been shown thousands of examples and has worked out its own rules from them, which is how a robot can recognise a cat sitting in the hallway when nobody ever wrote a rule describing a cat. Most hobby robots are the first kind, and that is completely fine.

Types of Robots You'll Encounter

Type	What it does	Where you'd see it	Beginner friendly?
Industrial arms	Repeat precise movements all day	Car factories, packing lines	No, but small desktop versions exist
Mobile robots	Move around a space on wheels or tracks	Vacuums, warehouse bots, delivery bots	Yes, this is the usual starting point
Humanoids	Balance and move like a person	Research labs, tech demos	No, very hard and very expensive
Drones	Fly and carry a camera or payload	Filming, surveying, agriculture	Yes, and cheap kits are everywhere
Educational kits	Teach the fundamentals in a box	Classrooms, your kitchen table	Yes, start here

If you are buying or building your first robot, you are realistically choosing between a mobile robot, a small drone or an educational kit. Everything else is something to admire on YouTube for now.

Getting Hands-On: How a Beginner Actually Starts

Buy a kit. I know it feels like cheating, but sourcing your own motor driver, working out why it is drawing too much current and discovering three weeks later that you bought the wrong voltage regulator is not learning robotics, it is learning procurement. A kit gives you parts that are guaranteed to work together, so when something breaks you know the problem is your code and not your shopping. An Arduino starter kit, a Raspberry Pi kit or a LEGO Mindstorms style set will all do the job.

For a first project, build an obstacle avoiding car. It is two motors, one ultrasonic sensor, a controller and a chassis. The robot drives forward until the sensor says something is close, then it stops, turns and carries on. It sounds trivial, and it teaches you almost everything from this post at once. You will wire up a sensor and read real values off it. You will drive a motor. You will write the sense, decide, act loop yourself. You will discover that the sensor gives you a mad reading now and then and you need to handle it. That last one is the real lesson.

For free learning, the Arduino Project Hub and the official Arduino docs are worth your time, and the Raspberry Pi Foundation publishes free beginner projects on their site. On YouTube, DroneBot Workshop is excellent for the electronics side and James Bruton is great for watching someone build ambitious things and hit problems out loud. For getting unstuck, r/robotics and the Arduino forums are active and generally patient with beginners.

Now set your expectations. Your first build will not work. Something will be wired backwards, a motor will spin the wrong way, or the robot will drive confidently into a wall while the sensor swears it is clear. This is normal and it is the job. The people who get good at this are not the ones who got it right first time, they are the ones who found it funny enough to try again.

Common Beginner Misconceptions

"Robots are basically like the movies." They are not. Real robots are narrow and a bit stupid. The most advanced humanoid in the world would struggle to make you a cup of tea in an unfamiliar kitchen.

"You need to be a maths genius." For your first year, you need to be able to compare two numbers and know what an average is. The heavy maths shows up in advanced control and motion planning, and by the time you need it you will actually understand why.

"Robots and AI are the same thing." A robot is a body that senses and acts. AI is one possible way of doing the deciding part. Plenty of robots use no AI at all, and plenty of AI never touches the physical world.

"It is too expensive to start." A decent Arduino starter kit with motors and sensors costs less than a night out. The expensive part of robotics is the stuff you do not need yet.

Conclusion: Your Next Step

Strip everything else away and this is the mental model you keep. A robot senses the world, decides what to do, then acts on it, and it does that over and over. Sensors, controller, actuators. If you can point at those three things on a machine, you understand its basic shape.

So here is the next step. This week, order an Arduino starter kit and build the obstacle avoiding car. Do not read another ten articles first. Get the thing on your desk and get it driving into a wall, then fix it.

If you do build it, leave a comment and tell me what went wrong first. It is always something.

Popular Programming Languages and Their Use Cases: What the Numbers Are Telling Us

Liam — Sun, 23 Aug 2026 21:02:04 +0000

Rankings of programming languages tend to move slowly. Ecosystems have inertia, codebases outlive the developers who wrote them and the cost of switching a production stack keeps most teams where they are. So when a widely watched index like the TIOBE Programming Community Index shows some movement, it's worth taking not as noise but as a signal about where developer attention is and where hiring demand is heading towards.

Here's the current top ten with each language's share of the index and its year-over-year change:

Rank	Language	Share	Change
1	Python	23.88%	+8.72%
2	C++	11.37%	+0.84%
3	Java	10.66%	+1.79%
4	C	9.84%	−1.14%
5	C#	4.12%	−3.41%
6	JavaScript	3.78%	+0.61%
7	SQL	2.87%	+1.04%
8	Go	2.26%	+0.53%
9	Delphi/Object Pascal	2.18%	+0.78%
10	Visual Basic	2.04%	+0.52%

Python's Generational Run

A +8.72% year-over-year swing is enormous for a language that was already number one. Python now commands nearly a quarter of the entire index, that's more than C++ and Java combined. Of course this isn't a fluke of methodology. It reflects Python's position as the default 'glue' language of the AI and data era. If your work touches machine learning, data pipelines, scientific computing or automation then Python is the path of least resistance. The surrounding tooling such as NumPy, pandas, PyTorch, the whole scientific stack keeps this alive.

For working developers, the practical implication is less "should I learn Python" and more "Python is now table stakes." Even if it isn't your primary language, it's increasingly the language your data scientists, ML engineers, and platform teams expect you to be conversant in. Its weaknesses is still there however. With runtime performance, packaging headaches, the GIL. These are well known but they've done nothing to slow adoption, largely because the performance-critical paths get pushed down into C extensions anyway.

The Systems Languages Hold Their Ground

C++ and C together still account for more than a fifth of the index and C++ is quietly up +0.84%. That stability is the point. These languages own the domains where you cannot afford abstraction overhead such as operating systems, embedded systems and real-time systems like game engines, databases, browsers and high-frequency trading. C's slight dip (−1.14%) doesn't signal decline so much as gradual intrusion by safer alternatives. It's worth noting that a lot of the "new" systems work is happening in Rust, which isn't in this top ten but is the language most often mentioned as C and C++'s eventual successor for memory-safe systems code.

Java's +1.79% is the underrated result here. A language frequently written off as legacy is growing and for good reason: it remains the backbone of enterprise backends, Android and large-scale distributed systems. The JVM ecosystem, modern language improvements and an immense hiring pool keep it firmly relevant. If you build server-side software at scale then Java and its cousin Kotlin are still where a huge share of the jobs are.

The C# Question

The most jarring number in the table is C#'s −3.41%. That's a steep single-year drop for a mature, well-supported language. C# remains a first-class choice for .NET backends, Windows desktop software, Unity game development and increasingly cross-platform work. A drop in an index isn't the same as a drop in production deployments. Still, if you're a C# developer, it's a reminder that mindshare is a competitive resource and the .NET ecosystem's future is tied to how visibly it competes outside its traditional Windows-and-enterprise home.

JavaScript, SQL and Go: The Quiet Essentials

JavaScript at number six almost undersells its reality. TIOBE tends to underweight JavaScript relative to its actual footprint because so much of its use is implicit in web work that never shows up in the searches the index measures. In practice, JavaScript (and TypeScript on top of it) is unavoidable for anyone building for the browser and its reach through Node.js extends well into backend and tooling territory.

SQL's presence at number seven, up +1.04%, is a healthy sign that the industry still recognizes data access as a core skill rather than an afterthought. It's not glamorous though but nearly every application eventually talks to a relational database and fluency in SQL routinely separates developers who can reason about performance from those who can't.

Go rounds out the credible growth story at number eight. Built at Google for exactly the kind of networked, concurrent, cloud-native services that now dominate infrastructure, Go has become a default for microservices, CLI tooling, and DevOps software. Docker and Kubernetes were both written in it. Its combination of simplicity, fast compilation, and strong concurrency primitives makes it an easy recommendation for backend and platform engineers.

And Then There's Visual Basic

Now for the entry that made me do a double take. Visual Basic sits at number ten, and it's up +0.52%. Delphi/Object Pascal is right above it at number nine, also climbing. In a top ten otherwise defined by AI, cloud and web, we have two languages whose cultural peak was arguably the late 1990s, growing in 2026.

I'll be honest this is the part of the rankings I'd treat with the most skepticism. I don't believe teams are starting new greenfield projects in Visual Basic in any meaningful numbers and no one should read this table as a reason to learn it. What VB's persistence actually measures is the astonishing durability of enterprise software. There are millions of lines of VB and VBA quietly running finance departments, manufacturing lines and government back offices and every one of those systems needs someone to maintain it. That maintenance work is real, it pays and it's often less contested than the crowded fields around Python and JavaScript but it's a career of tending existing systems, not building the future. The lesson isn't "VB is back." It's that code, once it works and touches money, almost never dies on schedule. Legacy is a use case and it's a lucrative one for the people willing to do the unglamorous work.

What to Actually Do With This

If you're a working developer reading these numbers as a career signal rather than trivia, a few takeaways hold up. Python is a skill worth having regardless of your specialty because it's where the industry's center of gravity now sits. The systems languages and Java aren't going anywhere, and depth in them remains genuinely valuable precisely because fewer people invest in it. JavaScript and SQL are close to mandatory for full-stack and application work. Go is the smart bet if you're moving toward cloud infrastructure. And the long tail of the list with VB, Delphi, is a reminder that maintenance is a market too even if it's not the one anyone puts on a conference badge.

Rankings like TIOBE are a lagging, imperfect proxy. They measure attention, not truth. But read it directionally and it tells a coherent story: the languages that win are the ones that own a clear use case and keep the friction low for the people trying to get real work done. Pick your tools accordingly.

Automating Receipt Tracking with Python OCR

Liam — Sun, 28 Jun 2026 07:37:02 +0000

I do most of my grocery shopping at Lidl, and like a lot of people I have a vague, unreliable mental model of what things actually cost. Was that block of cheese €2.49 last week or €3.29? Is the "special" actually special? The receipt has all of that information on it and it just evaporates the moment the paper hits the bin.

So I built a small app to capture it. Lidl Receipt Manager reads my Lidl (Ireland) receipts, builds a searchable price history of every product I've ever bought, and turns that history into tick-off shopping lists with a live running total. It runs on the desktop as a PyQt5 app and on my phone as a native Android .apk.

This post walks through what it does, how it's designed, and the part that ate the most of my time. As well as what it actually takes to package a Python app into an Android build.

What it does:

The feature set is deliberately small and focused on the one job: turning receipts into useful data.

Import receipts three ways. Photograph the receipt and let on-device OCR read it, pick an existing image file, or just paste the receipt text in. The paste path always works, which matters more than you'd think (more on that later).
A product price database. Every line item from every receipt is stored. Those rows get rolled up per product into an average, minimum, and maximum unit price, a count of how many times I've bought it, and when I last did.
Search as you type. Filter the product list instantly.
Shopping lists. Add a product and it comes pre-filled with its latest known price. Add manual items too. Tick things off as you walk the aisles and watch a live "remaining" total count down.
Duplicate-safe imports. Receipts are de-duplicated by their transaction ID, so accidentally importing the same receipt twice won't double-count anything.
Fully local and offline. Everything lives in a local SQLite database. Nothing is uploaded anywhere, not the photos, not the prices, nothing. Even the OCR runs on-device.

The design philosophy: a shared core, two skins

The most important design decision in the whole project is this: the desktop app and the Android app share the exact same brain. The parsing logic and the database schema are identical across both. Only the UI layer differs.

The repository reflects that split cleanly:

.
├── lidlReceiptManager.py     # Desktop app (PyQt5) a single file
└── android/                  # Android port (KivyMD)
    ├── main.py               # Touch UI (KivyMD bottom-nav)
    ├── core/
    │   ├── parser.py         # parse_receipt() is shared with desktop
    │   ├── db.py             # SQLite layer (same schema)
    │   └── ocr.py            # ML Kit on Android, pytesseract on desktop
    └── buildozer.spec        # APK build config

The desktop app is a single self-contained file. When I ported it to Android, I pulled the three things that have nothing to do with the UI, the parser, the database, and OCR, out into a small core/ package, and rebuilt only the presentation layer on top of them.

That gives a layered architecture where the dependency arrows all point inward:

   PyQt5 UI                 KivyMD UI
 (desktop main)          (android/main.py)
        \                     /
         \                   /
          v                 v
        core: parser · db · ocr
                   |
                   v
              SQLite file

Both UIs are "dumb" as they collect input, call into core, and render whatever comes back. The parser is pure standard library with no UI dependencies at all.

The parser

The parser is the heart of the project, and it's just careful regular expressions over the receipt's plain text. Lidl Ireland receipts have a predictable shape: a store header, a transaction ID (TRN-ID:), a date, a block of line items, and a TOTAL. Each line item is a name followed by a price and a single-letter VAT
class.

parse_receipt() does two passes. The first sweeps the whole receipt for the metadata such as store, transaction ID, date. The second walks line by line building up items: a price line starts a new item, a following 2 x 1.49 line attaches a quantity to it, and a trailing -0.50 applies a discount. Deposit lines and visual noise (rows of dashes, stray EUR/Copy tokens) are filtered out. At the end it computes a net unit price per item and returns a tidy dictionary:

return {'store': store, 'date': rdate, 'trn_id': trn_id,
        'total': total, 'items': products}

Because it's pure text in, pure dict out, it's trivial to reason about and it behaves identically no matter which app calls it. The Android copy is lifted verbatim from the desktop original, that's a deliberate choice so parsing behaviour can never silently drift between the two platforms.

The database

The data layer is a thin wrapper around SQLite with four tables: receipts, purchases (the individual line items, with a cascading foreign key back to the receipt), lists, and list_items. There's no ORM and no migrations machinery just CREATE TABLE IF NOT EXISTS and a handful of hand-written queries.

The price-history "rollup" that powers the product view isn't a stored table at all; it's a single GROUP BY query that aggregates on demand:

SELECT name,
       ROUND(AVG(unit_price),2) AS avg_price,
       ROUND(MIN(unit_price),2) AS min_price,
       ROUND(MAX(unit_price),2) AS max_price,
       COUNT(*) AS times,
       MAX(rdate) AS last_seen
FROM purchases p JOIN receipts r ON p.receipt_id = r.id
GROUP BY name ORDER BY name COLLATE NOCASE

Duplicate protection is enforced at the schema level as trn_id is UNIQUE and checked in code before insert, so re-importing a receipt returns a 'duplicate' status instead of doubling your data.

The one real change between platforms is where the database lives. On desktop it defaults to ~/.lidl_receipts/receipts.db, exactly as the original did. But on Android, ~ isn't writable, so the data directory is injectable: the Android app passes in its private user_data_dir and everything else stays the same.

class DB:
    def __init__(self, folder=None):
        folder = folder or default_data_dir()

There's also a small Android-specific concession, check_same_thread=False, on the connection because Kivy may touch the database from clock callbacks on a different thread than it was created on.

Pluggable OCR

OCR is the one piece of "core" that genuinely must differ by platform, so it's designed as a pluggable backend with a two-function public API: ocr_available() and image_to_text(path). The module sniffs the environment once at import time:

ON_ANDROID = 'ANDROID_ARGUMENT' in os.environ or hasattr(sys, 'getandroidapilevel')

On the desktop, it uses Tesseract via pytesseract, even auto-detecting the Tesseract executable in the usual Windows install locations so you don't have to fiddle with PATH.
On Android, it reaches into Google ML Kit's on-device text recognizer through pyjnius, which lets Python call Java/Android APIs directly. The text recognition model is bundled into the APK, so it runs fully offline with no Google account and no network round-trip.

That ML Kit call is a nice little window into how Python-on-Android actually works. You grab Java classes by name and call them as if they were Python objects:

from jnius import autoclass
InputImage = autoclass('com.google.mlkit.vision.common.InputImage')
TextRecognition = autoclass('com.google.mlkit.vision.text.TextRecognition')
...
task_await = getattr(Tasks, 'await')   # 'await' is a Python keyword!
result = task_await(recognizer.process(image))

There are real-world wrinkles baked in here: the gallery picker hands back a content:// URI while the camera returns a plain file path, so the code builds the right kind of Uri for each. And await is a reserved word in Python, so the Java Tasks.await() method has to be reached via getattr. Little things, but exactly the kind of friction you hit when bridging two runtimes.

The two UIs

The desktop app (PyQt5) is a classic two-tab desktop layout: a Products tab with an import toolbar, a search box, and a sortable table of every product with its price stats; and a Shopping Lists tab with a split view of lists on the left and their items on the right. It's styled with a bit of custom Qt stylesheet to look less like a 2005 application.

The Android app (KivyMD) rebuilds the same two screens for touch using a Material Design bottom navigation bar into Products and Lists. The receipt import buttons become big tappable "Photo / Image / Paste" buttons, list items become rows with a checkbox and a delete button, and the whole thing is laid out in KivyMD's declarative KV language right inside main.py.

The one genuinely tricky bit of the mobile UI is threading. OCR can take a second or two, and you must never block the UI thread, so image import spins the recognition work onto a background thread and then marshals the result back to the main thread to update the screen:

def worker():
    text = ocr.image_to_text(path)
    self._parsed_main(parse_receipt(text))   # @mainthread-decorated

threading.Thread(target=worker, daemon=True).start()

KivyMD's @mainthread decorator makes that hop back onto the UI thread clean.

Building the Android APK: the part nobody warns you about

Here's where things get real. Writing a Kivy app is the easy 20%. Packaging it into an .apk that installs and runs on a phone is the other 80%, and it's full of sharp edges. Here's the path I landed on after a fair amount of trial and error.

Test on the PC first

The single biggest time-saver was realising I didn't need an Android build to iterate. KivyMD runs on the desktop, so I could develop the entire UI and data layer with a plain python main.py and a fast feedback loop. Only camera capture is phone-only; everything else behaves identically.

But getting the desktop preview running surfaced two Windows gotchas worth knowing:

Python version matters. Kivy 2.3.0 has no Windows wheels for Python 3.13/3.14, so you have to pin to Python 3.11 or 3.12. (uv python install 3.12 makes this painless.)
KivyMD 1.1.1 is broken out of the box on modern setuptools. It's distributed only as an sdist, and modern setuptools silently drops all of its non-Python data files when building it, the .kv layouts, the GLSL shaders, the fonts. The result is cryptic FileNotFoundError: ... label.kv at import or ... header.frag at first render. I wrote a little helper, fix_kivymd_kv.py, that downloads the official sdist and copies every missing data file back into the installed package. One command and the preview runs.

The actual build: Buildozer on WSL2

The packaging tool is Buildozer, which orchestrates python-for-android (p4a) to cross-compile CPython, your code, and all the native dependencies into an APK. The catch: Buildozer only runs on Linux/macOS. On my Windows 10 machine, that means WSL2 (Ubuntu).

The one-time setup is a hefty apt install (JDK 17, the Android build toolchain, autoconf, cmake, libffi, libssl, and so on) plus a virtualenv with Buildozer and a pinned Cython. Then the build itself is one command:

buildozer -v android debug

The first run is a commitment: it downloads the entire Android SDK and NDK and compiles everything from scratch so about 20 to 40 minutes. Subsequent builds are minutes. One important tip: build inside the WSL filesystem (~), not on /mnt/c/..., because building across the Windows/Linux filesystem boundary is slow and hits path issues.

The `buildozer.spec` is where the real decisions live

The build is configured by buildozer.spec, and almost every line in mine exists because something broke without it. The highlights:

Requirements: python3,kivy==2.3.0,kivymd==1.1.1,pyjnius,plyer,android. pyjnius is what lets me call ML Kit; plyer provides the camera and file picker; android provides the permissions API. Notably, Pillow is deliberately omitted as it's only used by the desktop OCR fallback, and on Android OCR is ML Kit, so PIL would just add a fragile native build for no benefit.
ML Kit as a Gradle dependency. This is the elegant bit:

  android.gradle_dependencies = com.google.mlkit:text-recognition:16.0.0

That one line pulls Google's on-device text recognition into the APK at build time and bundles the Latin model so it works offline.

Pinned versions everywhere. This is the hardest-won lesson. p4a is pinned to the v2024.01.21 release, which builds Python 3.11 because the p4a master default targets Python 3.14, and Kivy 2.3.0 does not compile against 3.14 (private CPython C-API functions it relies on, like _PyLong_AsByteArray, changed or were removed). The NDK is pinned to 25b to match. KivyMD is pinned to 1.1.1 in both the build spec and the desktop requirements, because KivyMD's API churns between releases. In this corner of the ecosystem, "just use the latest version" is how you lose a weekend.
Permissions and targets: CAMERA plus storage read/write, target API 34, minimum API 24, building for both arm64-v8a and armeabi-v7a, and accept_sdk_license = True so the first build doesn't block on an interactive license prompt.

The APK lands in bin/, gets copied back across to Windows, and installs either over USB with adb or just by tapping the file on the phone. On first launch it asks for camera and storage permissions, and from then on it's a self-contained, offline little app.

Lessons learned

A few things I'm taking away from this project:

Separate the brain from the skin early. Pulling the parser, DB, and OCR into a UI-agnostic core meant the entire Android port was "write a new UI" rather than "rewrite the app." The shared core is the reason two apps can stay in lockstep.
A pluggable seam is worth it where platforms genuinely differ. OCR was the one thing that had to change per platform, and giving it a tiny two-function interface kept that difference from leaking everywhere else.
Always leave an escape hatch. OCR is magic when it works and useless on a crumpled receipt in bad light. The "paste the text" import path costs almost nothing and means the app is never completely stuck.
Mobile packaging is a versioning minefield. The code was the easy part. The real engineering was discovering the exact combination of Python, Kivy, KivyMD, p4a, and NDK versions that actually build together and then pinning every one of them so it stays buildable.

The end result is exactly what I wanted: I photograph my receipt on the way out of the shop, and over time I've built up a private, offline, searchable history of what everything actually costs and a shopping list that knows the price of
things before I get to the till.

Making my own Sonar System

Liam — Sun, 28 Jun 2026 07:08:30 +0000

Initial:

In my boredom I designed and made my own sonar detection system with a few parts and an Arduino. I used a ultrasonic sensor to detect objects in the way with a servo to get a measurement over 180 degrees. I connected the ultrasonic sensor to pins 9 for the trigger and 8 for the echo. The servo used its own library that would take the servo degree as an int. Click here to go to the github page.

int trigPin = 9;
int echoPin = 8;
int servoPos;

To start off I initialised the ultrasonic sensor and got a reading off it, using the reading to get a distance in centimetres. To get better results, I added a noise filter by getting 20 samples and using them to get the average distance from the sensor. The more samples I got, the more consistent the measurement were. However this could cause the Arduino to take longer to do each calculation, so I kept it to 20 samples.

int getMeasurement(){

  //Get 15 samples
  for(int sample =0; sample < 20; sample++){
    filterMeasures[sample] = ultrasonicMeasurement();
    //delay(10);
    }


  //Filter samples by ascending
  for(int i = 0; i < 19; i++){
    for (int j = i + 1; j < 20; j++){
      float swap = filterMeasures[i];
      filterMeasures[i] = filterMeasures[j];
      filterMeasures[j] = swap;
    }
  }

  //filter noise
  double sum = 0;
  for(int sample = 5; sample < 15; sample++){
     sum += filterMeasures[sample];
  }

  distance = sum / 10;

  int intDistance = (int)distance;

  return intDistance;

}

float ultrasonicMeasurement(){
  //20 microsecond pulses to trigPin
  digitalWrite(trigPin, HIGH);
  delayMicroseconds(10);
  digitalWrite(trigPin, LOW);

  //Use echoPin to measure pulses
  durationUs = pulseIn(echoPin, HIGH);

  distanceCm = 0.017 * durationUs;

  return distanceCm;

}

Next, I added the servo motor control, so I used a for loop to set the degree the servo was supposed to be. This made it straightforward to record the servo's position and log the distance at each angle. This would mean the servo would move to the set degree and then get measure the distance before moving again. So, with that I managed to get the servo to move smoothly from side to side. However, when the ultrasonic sensor was getting it measurements, it seemed like some were a little random or even plain wrong I had both parts were sharing the 5V rail and I fixed randomness by using another 5V power supply for the servo. This allowed both to get a good supply of power.

Serial.println("Loop one");
  for(int x = 0; x <= 180; x+=1){

    servoControl(x);
    delay(75);
    int currentMeasurement = getMeasurement();
    servoPos = x;
    posArray[servoPos] = currentMeasurement;
    Serial.print("Pos: ");
    Serial.println(servoPos);
    Serial.print(currentMeasurement);
    Serial.println(" cm");
    //delay(30);
  }

  Serial.println("Loop two");
  for(int x = 180; x >= 0; x-=1){
    servoControl(x);
    delay(75);
    int currentMeasurement = ultrasonicMeasurement();
    servoPos = x;
    posArray[servoPos] = currentMeasurement;
    Serial.print("Pos: ");
    Serial.println(servoPos);
    Serial.print(currentMeasurement);
    Serial.println(" cm");
    //delay(30);
  }

Finally, I went to FreeCAD and designed a case that held everything together. The Arduino would be seated under everything with the servo and ultrasonic sensor mounted on top of the case.