TNERA

Hey everyone,

I wanted to share the start of my new robotics project, Minone, which is my MVP (Minimum Viable Prototype) for an exploration-focused robot. My goal with this build is to learn and refine SLAM (Simultaneous Localization and Mapping) using simple sensors, focusing on the fundamentals before scaling up.

Instead of jumping straight into complex sensor suites like LiDAR, I’m starting with basic ultrasonic and IR sensors to tackle obstacle detection and mapping. The idea is to deeply understand SLAM implementation—both from a theoretical and practical perspective—before adding more sophisticated hardware.

Right now, I’m putting the basics of the physical robot together using components I already have lying around. The chassis? A wine box top. The drive system? Two old Roomba motors bolted to it, with a recycled caster wheel from a trashed piece of luggage. It’s a real scrap yard robot, but that’s part of the fun—keeping it simple, functional, and iterative.

For the microcontroller, I’m going with an ESP-32S, and motor control will be handled by an L298N H-Bridge, which should handle the voltage needs of the Roomba motors just fine.

For initial sensing, I’m starting with a single Ultrasonic HC-SR04. Yes, it’s extremely underpowered for SLAM, and that’s completely intentional. My goal isn’t to throw advanced hardware at the problem but to push minimal sensors as far as possible. That way, I can deeply understand how to extract useful mapping data before moving on to more capable sensors.

I’d love to hear any feedback on my approach so far—especially if you have thoughts on driving a two-wheeled robot with a trailing caster wheel. I’m already second-guessing the design due to stability issues and occasional tipping forward, so if you’ve dealt with this before, let me know what worked for you. Also, this is my first project using an ESP-32S, so any tips on working with it—particularly for motor control and encoder integration—would be much appreciated!

Minone:

 IMG_0830.jpeg   162,42 Ko   4 téléchargement(s)

Underside of Minone:

 IMG_0832.jpeg   495,17 Ko   3 téléchargement(s)

Roomba wheel (DC motor control, and Encoder)

 IMG_0824.jpeg   389,1 Ko   6 téléchargement(s)

Bonjour Parisian Robot Makers,

Apologies for the slightly off-topic post!

I have a potential opportunity to work in Paris and would really appreciate your advice on the best areas to live. My office will be in Saint-Lazare, and I’m searching for a neighborhood where I could find a 1-2 bedroom apartment with reasonable rent and a convenient commute.

Any tips on things like cost of living (I’m currently based in Germany), apartment availability, or neighborhoods to avoid—or highly. recommended—would be great! I’m also eager to connect with the local robotics scene, so if you know of any great meetups or communities, please let me know. Learning French is already on my to-do list (though my German-learning adventure didn’t go quite as planned!).

Feel free to DM me if you’d prefer to share privately.

Thanks so much for your help!

TNERA

Hi All,

It has been a while since we last talked Inverse Kinematics!  I have been working on a new quadruped and find myself making these calculations again. This time, I had ChatGPT to help and hinder my progress - but that is a different topic!! 

I have a version of code that is somewhat working.  For every bug I found, I created another.  I give an explanation (from my blog), pictures, and code.  please take a look and give me some feedback.  Much appreicated!

- did I miss some simplification?

- easier way to do things?

- something to be carefull with?

 Mojo5_leg-v3-IK-alpha.png   1,87 Mo   18 téléchargement(s)

Calculating the Knee Angle (Theta2)

 

To calculate the knee angle, our first step involves identifying the interior angle between the two legs, L1 and L2, which we'll refer to as beta. Once again, the law of cosines proves invaluable for this calculation. While the deeper mathematical proofs are better left to academia, the simplified formula to compute beta is given by acos((2*L^2 - D^2) / (2*L^2)). This equation allows us to calculate beta, which represents the angle between the leg segments in our model.

 

However, to translate this angle into a form usable by the servo mechanism, additional adjustments are necessary due to the servo being linked to the leg segments via cams. We must take the supplementary angle to beta. This supplementary angle, once processed through the cam system, achieves the effect of pulling the leg segments into the correct position but in a reversed direction. Consequently, we must employ the complement of this supplementary angle to align with the actual geometry and movement direction required by the servo mechanism. This raises an interesting question: could the calculation have been simplified to just beta minus 90 degrees?

 

 Mojo5_leg-v3-IK-beta.png   1,86 Mo   15 téléchargement(s)

 

Code:

 

// Function to calculate and return the servo angles given a target (x, y)
void calcIK(float x, float y, float &theta1, float &theta2) {
  float D = sqrt(x*x + y*y); // Distance from hip to target point  (x hori, y vert always neg)
  // Ensure the angle is within the robot's physical capability
  if (D > 2 * L) {
    // If the target is beyond the maximum reach, approximate values within range
    D = 2 * L;
  }

  float theta = atan2(-y,x); // Angle to target from horizontal, need pos angle its upside down.
  float alpha = acos(D / (2*L)); // Angle between leg segments for target

  // For an inverted servo, use the complementary angle
  theta1 = 180 - ((theta + alpha) * (180.0 / M_PI)); // Adjusting theta1 for the inverted servo
  
  // Beta & Theta2 calculation, knee indepedent of hip
  float beta = acos((2*L*L - D*D) / (2*L*L)); //interior angle between L1 and D
  // Theta2 subtract from 180 to invert angle (complment); bisect beta for independent; adjust for servo rotation
  theta2 = (180 - (beta * (180.0 / M_PI) / 2)) + ADJUST_B;

  Serial.printf("D: %.2f, Theta: %.2f, Alpha: %.2f, Theta1: %.2f, Beta: %.2f, Theta2: %.2f\n",
          D, theta * (180.0 / M_PI), alpha * (180.0 / M_PI), theta1, beta * (180.0 / M_PI), theta2);
}

Hi All,

Has anyone heard of the robot challenge ELROB?

ELROB 2024 - European Land Robot Trial

I guess this is similar to the DARPA robotic challenges. It is open to 'non-profits' and is for demonstration purposes.

It will be held in Trier, Germany on 24-28 June

unfortunately, I don't have my team together.

The sign up deadline is 31 January.

Here are the scenarios for 2024.  On the page, they have PDFs that describe in detail

• Transport - Convoying
  (transport with two vehicles)
  Scenario description
• Reconnoitring of structures
  (3D mapping and search for OPIs)
  Scenario description
• Transport - Mule
  (shuttle between two locations)
  Scenario description
• Search & Rescue (SAR) / CasEvac
  (find and drag a dummy body)
  Scenario description
• Reconnaissance and disposal of bombs and explosive devices (EOD/IED)
  Scenario description
•  

• Will the robots be more successful by automating redundant/dangrous/boring work?
• Or would they really require strong value added services like data intelligence, or the 'killer app' syndrome?

 

• Will it be the labor replacement?
• or the making Ag more digital? Meaning that the value is best found in areas like Computer Vision, and sensors, and data collection.
• Or Are we still missing the 'killer app' that will allow this robotic platform to take off?