Contribute to cmodi306/stock_market_alert development by creating an account on GitHub.

Many automotive brands argue about the usage of sensor for driving assistance systems, claiming that theirs is the best. The question is, is theirs really flawless? If not, what is actually the perfect sensor system? You know, the magical combination of LiDAR, radar, cameras, GNSS, IMU, ultrasonic, thermal, probably a ToF sensor duct-taped somewhere, that will finally make perception flawless. No edge cases. No missed detections. No weird false positives in foggy industrial zones. Just clean point clouds, crisp images, and perfectly aligned timestamps flowing through ROS2 like a garden of messages.

If there’s one thing Python developers collectively agree on, besides PEP 8 and the fact that "import this" is a fun Easter egg nobody uses, it’s this: writing documentation is that one task we all procrastinate harder than cleaning the lint filter in a shared apartment dryer. We all want clean, readable docstrings and user guides. We also want to keep shipping features, fixing bugs, and pretending that “I’ll document it later” is a real plan. Spoiler: it never is. But we’re in a pretty interesting era now. Large language models—ChatGPT included—aren’t just toys for generating fantasy world lore or “explain quantum physics like I’m five.” They’ve quietly become extremely competent at turning your messy Python source tree into documentation that won’t embarrass you in front of other developers.

You’ve probably noticed that your GPS can tell you you’re somewhere in the area, but not exactly where you are. That’s fine when you’re ordering pizza, but not when you’re flying a drone or programming a robot to dock itself precisely. A few meters, even centimeters of error might mean a missed landing pad, a wrong turn, or a confused machine. This is exactly where RTK — Real-Time Kinematic positioning — steps in and makes GPS behave like a pro. In this post, we’ll go beyond the surface. We’ll look at what RTK really is, how it works behind the scenes, what “RTK correction data” means, and how that data is actually received from a base station or server.

Learn how to use gpsd to read, parse, and manage GPS data on Linux. A clear, practical guide for developers working with GPS hardware.

Let’s talk GPS. Not the “turn left at the big tree” kind that you cursed at when you missed an exit, but the kind that helps self-driving cars, drones, and anything that to navigate in free space. GPS, or Global Positioning System, is basically a constellation of satellites shouting “I’m here!” while your receiver goes, “Cool… where am I?” For humans, it’s usually “you’re five minutes away, traffic sucks, also don’t take that exit.” For machines, especially self-driving cars, it’s a vital system. The fundamental need of a GPS system is to help machines like self-driving cars to navigate.

In the previous blogs, we initially defined a robot vehicle in URDF and then defined the same vehicle using Xacros by creating templates and reusing them. In this last blog of the series (I guess), we are going to add motion to that vehicle and make it run in the virtual map. In the end, the vehicle will move like this: So let's get started: Defining the Transformation Writing the Vehicle Interface Node Configuring CMakeLists.txt and package.xml files Results What's Next Defining the Transformation In the previous post of this series, we create…

Been a while since I posted the first part in this ROS2 tutorial series, so let's start with a quick recap. In the last blog, we created a simple robotic vehicle model that looked like this: And the URDF that generated it looked something like this: <?xml version="1.0"?> <robot name="simple_vehicle"> <link name="base_link"> <visual> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <box size="2.0 1.2 0.4"/> </geometry> <material name="red"> <color rgba="1.0 0.2 0.2 1.0"/> </material> </visual> <collision> <origin xyz="0 0 0" rpy="0 0 0"/> <geometry> <box size="2.0 1.2 0.4"/> </geometry> </collision> <inertial> <origin xyz="0 0 0" rpy="0 0 0"/> <mass value="200.0"/> <inertia ixx="16.0" iyy="66.7" izz="80.7" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <!-- Left front wheel --> <link name="fl_wheel"> <visual> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length= "0.2"/> </geometry> <material name="black"> <color rgba="0.1 0.1 0.1 1.0"/> </material> </visual> <collision> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length="0.2"/> </geometry> </collision> <inertial> <mass value="10.0"/> <inertia ixx="0.45" iyy="0.45" izz="0.25" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <joint name="fl_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="fl_wheel"/> <origin xyz="0.9 0.8 0.0"/> </joint> <!-- Right front wheel --> <link name="fr_wheel"> <visual> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length= "0.2"/> </geometry> <material name="black"> <color rgba="0.1 0.1 0.1 1.0"/> </material> </visual> <collision> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length="0.2"/> </geometry> </collision> <inertial> <mass value="10.0"/> <inertia ixx="0.45" iyy="0.45" izz="0.25" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <joint name="fr_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="fr_wheel"/> <origin xyz="0.9 -0.8 0.0"/> </joint> <!-- Left rear wheel --> <link name="rl_wheel"> <visual> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length= "0.2"/> </geometry> <material name="black"> <color rgba="0.1 0.1 0.1 1.0"/> </material> </visual> <collision> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length="0.2"/> </geometry> </collision> <inertial> <mass value="10.0"/> <inertia ixx="0.45" iyy="0.45" izz="0.25" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <joint name="rl_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="rl_wheel"/> <origin xyz="-0.9 0.8 0.0"/> </joint> <!-- Right rear wheel --> <link name="rr_wheel"> <visual> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length= "0.2"/> </geometry> <material name="black"> <color rgba="0.1 0.1 0.1 1.0"/> </material> </visual> <collision> <origin xyz="0.0 0.0 0.0" rpy="1.5708 0 0"/> <geometry> <cylinder radius="0.3" length="0.2"/> </geometry> </collision> <inertial> <mass value="10.0"/> <inertia ixx="0.45" iyy="0.45" izz="0.25" ixy="0" ixz="0" iyz="0"/> </inertial> </link> <joint name="rr_wheel_joint" type="continuous"> <parent link="base_link"/> <child link="rr_wheel"/> <origin xyz="-0.9 -0.8 0.0"/> </joint> </robot>

Pathetic Programming is a series I started to build absurd programs with Python. With already two blogs in the series namely: Creating a Random Excuse Generator with Python and Are You Even a Real Python Programmer? Take This Useless Quiz to Find Out, I thought it was now time for the third one. And this time, we are making our code talk back to us.

In ROS2, if you have ever worked with coordinate transformations, you’ve likely encountered the acronym URDF at some point. It stands for Unified Robot Description Format. Sounds formal, almost intimidating, doesn’t it? Yet behind that technical name lies something surprisingly straightforward and incredibly powerful—the way ROS2 understands what your robot looks like, how its parts fit together, and how they move. Think of URDF as the architectural blueprint for your robot’s digital twin. Without it, ROS2 can’t simulate your creation, visualize it, or plan its movements effectively. Whether you’re working on a robotic arm, a wheeled rover, or a complex humanoid, URDF is the essential language that bridges mechanical design with software.

If you’ve ever tried to explain Bayes’ theorem to someone at a party, you know the look you get. That glazed-over, polite nod that says “I’ll remember your name but not a single word you just said.” And yet, Bayes’ theorem is one of those quietly powerful tools in the machine learning toolbox that’s simultaneously simple, annoyingly subtle, and sneakily everywhere. To warm you up, let’s start with the simple example. Imagine you go to the doctor for a routine check-up, and they run a screening test for a rare condition.