Mojo5 - Enhancing Performance with More Powerful Batteries (11)

 

Mojo5 - with power bank battery

Welcome back to the "Totally Not Evil Robot Army" blog. In this 11th installment of the Mojo5 series, we’re going to dive into a crucial aspect of building robust quadruped robots: using more powerful batteries to drive hobby servos. Specifically, we'll explore how increasing the available amperage and voltage can significantly improve the performance of underpowered servos and the considerations needed to ensure safe and efficient operation.

The Problem with Underpowered Servos

Building a quadruped robot like Mojo5 with cheap hobby servos often leads to performance issues. Many of these servos, such as the MG995, are slow and lack the torque needed for dynamic movements. Even with a 5V power supply, these servos can become wobbly and unreliable, especially under load. This is where upgrading to more powerful batteries comes into play.

The Limitations of the Original Power Configuration

Initially, Mojo5 used a 5V 12000mAh power bank. While this power source had a high capacity, it was limited to a maximum output of 3A. Given that the MG995 servos have a stall current rating of up to 3A each, the total current demand for the robot could easily exceed 20A during peak operation. This significant shortfall in available current was a primary cause of the robot's poor performance.

Upgrading the Power Source: LiPo Batteries

Based on previous discussions and experiments, we found that using a more powerful battery can drastically improve servo performance. Upgrading to a LiPo battery with a 2200mAh capacity, 7.4V voltage, and a 50C discharge rating provides the needed boost. This battery can supply well over the 20A needed by the servos, addressing the current limitations of the previous power source.

Considerations for Over-Volting

1. Risk of Burnout: Exceeding the servo’s voltage rating does carry a risk of burnout. However, anecdotal evidence suggests that slight over-volting is generally safe if monitored properly. Implementing a voltage regulator could limit the current capacity, which might be counterproductive. In general voltage regulators on servo power sources are not recommended.

2. Separate Circuits for Different Servos: For servos with lower voltage ratings, such as the MG90 (max 6V), consider creating a separate circuit to avoid over-volting. This will add an additional circuit which can be problematic. For my experiments with Mojo5, I used the same circuit.

Practical Application: Experimenting

Initial Setup

1. Battery Connection: Connect the 7.4V 50C LiPo battery directly to the power bus of the PCA9685 servo driver, bypassing capacitors and regulators. This setup ensures the servos receive power directly.

2. Handling Large Wires: Safely connecting XT-60 battery connectors and their thick 12 AWG wires to smaller electronics is challenging. Using a bare copper PCB or prototyping PCBs with multiple copper lines can provide a more robust connection. Soldering all wires together is an ugly but space-efficient solution.

Not Recommended!

In this experiment, I took the short cut and soldered the large wires directly in to a dupont connector. The connector was connected directly to the servo bus. This is not a recommended practice! I better connection with larger wires is recommended. In this particular case, as long as all of the servo motors do not stall, then only brief seconds of +20A current would be expected.  Current greater than 7A for sustained periods of time would destroy the connectors.

Experiment Results

After connecting the 7.4V battery:

• Servo Performance: There was a noticeable improvement in servo actuation. The MG995 servos operated better, with no immediate burnout.
• Heat Management: Monitoring the temperature of connectors and wires is crucial. Using a finger-test method (keeping fingers on components for one minute) can help identify safe current levels. If components become too hot to touch, reduce the current.

To visualize the improvement, I have embedded a short video showing Mojo5's performance with the original 5V power bank versus the upgraded 7.4V LiPo battery. Notice the difference in servo response time and stability.

Long-Term Solutions

While the initial experiments are promising, long-term solutions require more robust hardware:

1. Custom Servo Driver Board: Developing a servo driver board with better connectors and thicker traces can handle higher currents more efficiently. This would replace the PCA9685 board, which is not designed for high current loads.
2. Current Monitoring: Implementing current measurements and safety features like e-fuses can prevent overcurrent situations and protect your components.

Conclusion

Upgrading to more powerful batteries can significantly enhance the performance of underpowered servos in your DIY robots. While there are risks associated with over-volting, careful monitoring and proper hardware can mitigate these risks. As we continue to push the boundaries of DIY robotics, sharing these experiences and solutions will help us all build more capable and reliable robots.

Mojo5 - Mirrored Servo Control for Opposite Side Legs (#10)

Mojo5 - Two Legs with Symmetric Control

Introduction to Mirrored Servo Control (Symmetric Control)

One of the primary challenges in developing Mojo5 was ensuring synchronized movements between the servos on opposite sides of the robot. To achieve this, we employed a straightforward yet effective approach: mirroring the servo movements by reflecting the target angles.

Technical Implementation

To implement the mirroring effect, we introduced a boolean parameter in our Servo structure to indicate whether a servo should be mirrored. The adjustment is applied directly in the servo control function.

void moveServo(const Servo& servo, int pos) {

  pos = max(servo.minPos, min(pos, servo.maxPos));

  int pulseWidth =  map(pos, servo.minPos, servo.maxPos, servo.minPWM, servo.maxPWM);

  pca9685.setPWM(servo.num, 0, pulseWidth);

    if (servo.mirror) {

        pos = 180 - pos;  // Adjust the position if mirroring is needed

    }

    pos = max(servo.minPos, min(pos, servo.maxPos));

    int pulseWidth =  map(pos, servo.minPos, servo.maxPos, servo.minPWM, servo.maxPWM);

    pca9685.setPWM(servo.num, 0, pulseWidth);

}

the following structure is used to define all the elements of the servo

struct Servo {

  uint8_t num;

  int minPos;

  int maxPos;

  int minPWM;

  int maxPWM;

  int minRange;

  int maxRange;

  int minRangePWM;

  int maxRangePWM;

  bool mirror;  //true => adjust IK if opposite side

};

The results of this code are directly observed in the output for the Pulse Width Modulation (pwm) values that are sent to the servos.  Here you can see the servo values are 'reflected' or 'mirrored', symmetrical to one another:

Mojo5 - Symmetric control - pwm values over a rectangle gait

Practical Application and Results

In our setup, the mirror effect (symmetric control) is particularly useful for maintaining symmetry in the leg movements. This approach simplifies the inverse kinematics (IK) calculations, as the same code can be used for both sides of the robot with the mirrored adjustment applied where necessary only at the servo control.

To illustrate this concept, we've embedded a short video demonstrating the addition of a leg from the opposite side of Mojo5. The IK calculations are identical, but the servo angles are adjusted by reflecting the target angles, resulting in a mirrored motion that maintains the robot's symmetry.

Insights on Mirrored Movements

Creating a mirrored movement (symmetric control) for servos is crucial for several reasons:

• Symmetry and Balance: Ensuring that both sides of the robot move in a symmetrical manner is essential for maintaining balance, especially in quadruped robots. Asymmetrical movements can lead to instability and erratic behavior.

• Simplified Coding: By mirroring movements, the same IK code can be reused for both sides, reducing complexity and the potential for errors. This makes the development process more efficient and the codebase easier to maintain. The servo angles are simply adjusted because all servos turn counter-clockwise and have a 0 to 180° range based on their orientation. Servos on the opposite side face differently, so this mirroring adjustment is necessary.

• Consistent Gait Patterns: Symmetrical leg movements are vital for creating smooth and natural-looking gait patterns. Mirroring helps in achieving uniform step lengths and timings, which are important for the robot's locomotion.

Summary

The mirroring technique (symmetric control) we've implemented in Mojo5 represents a significant simplification in controlling symmetrical movements in quadruped robots. By introducing a boolean flag in the servo structure and adjusting the servo angles accordingly, we achieve mirrored movements without duplicating the IK code. This not only enhances the efficiency of our development process but also ensures more consistent and predictable robotic movements.

Mojo5 - Inverse Kinematics in Motion (#9)

I've recently implemented an inverse kinematics (IK) solution to enhance the precision and control of robotic leg movements. Our primary experiment involved programming the leg to execute a simple rectangular movement pattern, with a focus on maintaining accuracy and consistency. Here, I will share some intriguing geometrical observations and challenges we encountered.

Intended Path and Test Setup

For this test, the robot leg will start in the (0,-130) position. Moving clockwise, It steps backward (in my case more positive, note the inverted x axis) to the (50, -130) position. Next up by 25mm to the top. At this time I use a different z position, but it is hard to see. the motion continues around in a rectangle ending at the start.

Planned path for simple gait test. starting at the center bottom

Video Analysis

In the bolow short video, the robot steps through the gait path. The leg is mounted above the table and horizontal to the table, not in a typical robot position. I have traced each step of the path, with a small dot at the end of the foot.

As seen in the video, the motion lacks the expected precision, influenced by several factors:

• Fixture Stability: The fixture holding the leg is unstable, contributing to erratic movements.
• Manual Marking Inaccuracy: Yellow dots indicating key positions were marked by eye, leading to imprecision.
• Servo Calibration: The calibration of the servo points was approximative. At a setting meant to be 90°, the actual angle could range between 85-95°.

Geometrical Challenges: The Skew Issue

One of the more fascinating issues we observed is the skew to the left when the leg is raised vertically. This skew is likely influenced by the constraints of the 'solution space'—the range within which the actuator operates. As a result, there is a slight warping effect in the grid area over which the leg can move.

Mojo5 Inverse Kinematics - geometric skew

Implications of the Skew

• Motor-Driven Distortions: The two servomotors, designed to drive the leg in specific rotational angles, do not guarantee a perfectly perpendicular alignment of the movement path. This introduces a mathematical distortion in the intended trajectory.
• Impact on Gait Creation: While this skew does not necessarily hinder the robot's ability to perform meaningful gaits, it highlights an essential aspect of robotic movement—geometric imperfections inherent in mechanical and software solutions.

Further Research on the Mapped or Solution Space

The space in which the robot can operates can be understood as the geometric area or volume within which the robot can effectively reach and manipulate objects. This space is defined by the following:

• Reachability: Determined by the length of the robot's arms and the range of motion of its joints. The maximum and minimum extents of each joint define the outer and inner boundaries of this space.
• Compliance: In the context of SCARA robots, the vertical compliance allows for certain movements in the vertical plane within the workspace. This selective compliance helps in absorbing forces during tasks like assembly, where vertical give is beneficial.
• Kinematic Constraints: Defined by the robot's mechanical design and the kinematic equations governing its movements. These constraints delineate the paths and patterns the robot can execute.
• Control Resolution: The precision with which the robot's controllers can position its joints also defines the resolution within the mapped space, influencing how finely the robot can maneuver within its reach.

Certainly a very interesting area of study in robotics!

Mojo5 - My Inverse Kinematics Simplified (#8)

Inverse Kinematics pictured by Dalle3, it can be much simpler!

A much simpler approach

In my previous post on Inverse Kinematics (IK), the complexity might have left some readers puzzled about whether there could be a simpler method to achieve the same results. The good news is, yes, there is a simpler way! Thanks to insights from my roboticist friend Oracid over at the French Robot Forum on Robot Maker, I've streamlined the IK calculations for our Mojo5.

Understanding the Basics

The challenge remains the same: given a target point (x, y), we need to determine the angles of the hip servo (S1) and knee servo (S2). The geometric configuration of the robot's leg has not changed; we still deal with the leg segments L1 (upper) and L2 (lower), equal in length, connected at the knee and forming two sides of a parallelogram.

Geometric Simplification

This parallelogram setup allows us to simplify our calculations considerably. The angle from the horizontal to the leg segment L1 directly provides the angle for S1, and similarly, the angle from the horizontal to the side of L2 gives us S2.

Mojo5 - simplified Inverse Kinematics

Simplified Calculation Steps

Calculate Distance D:  First, we determine the distance from the hip servo to our target (x, y) using the Pythagorean theorem:  D = sqrt(x*x + y*y).  Note D plays a very important role in the following calculations for angles alpha and beta. It is also the line that divides our parallelogram in half.

Calculate alpha:  We will use the trigonometric law of cosines. Given that we know the length of our upper leg L1 and the length of D (aka the hypotenuse), we can calculate the angle between them.  We will call this alpha:  alpha = acos(D / (2*L)).  You may notice this is the same calculation that I used previously. More importantly, this angle alpha is the same on either side of the bisection of the parallelogram by D.

Calculate beta:  We will use a much simpler approach. Also using trigonometry, we see that there is a Right Triangle formed by the Y position, X length and the hypotenuse D. it is possible to calculate this angle opposite of y and D.  beta = asin ( abs(y) / D). It must be adjusted to its reflection in the event that x < 0, this is done (in radians) by subtracting PI from beta. Now one more interesting note. The angle we just calculated is the same angle at top horizontal, this makes it more clear how this beta angle will be used in our final calculations.

Final Servo Calculations:  For S1 we can take the value of beta and subtract apha from it.  Like wise to calculate the angle for S2 and can take the value of beta and add alpha to it to find its value.

• S1 = beta - alpha
• S2 = beta + alpha

Hopefully this explaination will help in visualizing the relationships and how to calcuate the correct angles for S1 and S2.  

Here you can view a simplified set of C++ code:

void calcIK(float x, float y, float &s1, float &s2,) {

  float L = 70; //length mm

  float d = sqrt(x*x + y*y);

  float alpha = acos(d / (2*L));

  float beta = asin(abs(y)/d);  if(x<0)beta=(M_PI-beta); 

  s1 = ((beta - alpha) * (180.0 / M_PI));

  s2 = ((beta + alpha) * (180.0 / M_PI));

}

 

Mojo5 - Inverse Kinematics (#7)

Inverse Kinematics

At first glance, one might think that Inverse Kinematics (IK) boils down to simple trigonometry. However, determining the appropriate angles is merely scratching the surface. The real challenge lies in considering the physical arrangement of servos, the reference frame, and the constraints tied to both the servo capabilities and their placement. Collectively, these factors embody the essence of Inverse Kinematics.

For  Mojo5, I've chosen to use two MG995 servos, arranged in a stack. One servo is responsible for the 'hip' motion, and the other controls the 'knee.' The crux of IK in this setup is to map a target position within the coordinate plane to specific angles for these servos. To streamline the calculations, I've made a series of strategic design decisions. The lengths of the leg segments, L1 and L2, are set to be equal, each measuring 70mm. The hip servo is positioned as the origin point of our coordinate system. The mechanism for the knee is somewhat intricate, primarily because the servo controlling it is not mounted directly on the leg. Additionally, I've introduced a concept of 'yaw' movement along the z-axis, although, for the time being, our IK calculations will focus solely on movements within the x and y axes.

When it comes to calculating the necessary angles through IK, the approach is to visualize a triangle formed by the leg segments. Given that L1 and L2 are of equal length, this triangle is always isosceles. While this detail may seem minor at first, it becomes crucial when applying the Pythagorean theorem—a^2 = b^2 + c^2—to determine the distance (D) between the endpoints of the leg segments. This distance is key to assessing the feasibility of reaching a given target (x, y) position. To ensure reachability, D must not exceed the sum of the lengths of the two leg segments, or in other words, D <= 2*L.

Calculating the Hip Angle (Theta1)

To determine the hip angle, one must sum two distinct angles. The initial angle is formed between the horizontal axis and the target point (x,y) at the end of line D in our coordinate system. This can be calculated using the ArcTangent function, specifically arctan2(y/x) in standard practices. However, in my application, I employ arctan2(-y/x). The choice to use a negative y value due to my y values will consistently fall below zero. An alternative approach could involve taking the absolute value of the ArcTangent result to ensure a positive angle.

Following this, it's necessary to find the interior angle between line D and leg segment L1 within our conceptualized triangle. This angle, designated as alpha, can be determined through the law of cosines. In a simplified form, the calculation of alpha is expressed as acos(D / (2*L)). By adding alpha to the previously calculated angle, we derive the hip angle. However, there's a twist due to the servo's counterclockwise incrementation: the actual Theta1 is the supplement of the sum of alpha and our initial angle, mathematically expressed as Theta1 = 180 - (alpha + theta).

Mojo5 - Inverse Kinematics of the Hip Joint

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 - Inverse Kinematics of the Knee Joint

Moving forward

This step concludes the basic framework for the Inverse Kinematics (IK) calculation pertinent to our robotic project. It's important to note that the physical setup of the servos and the joint mechanics imposes certain limitations on movement. Preliminary observations suggest the knee joint is limited to 90 degrees of motion, while the hip joint can achieve approximately 130 degrees. These constraints are not absolute; certain hip positions may permit additional knee movement, although these specific interactions remain to be fully mapped out.

Mojo5 - Video Update, Next IK (#6)

The development of Mojo5 steadily progresses, we've put Mojo5's new leg design through its paces. This latest test, captured in a YouTube Short, showcases a significant enhancement in the design, specifically in the addition of a 'yaw mount'. Although the abduction servo—responsible for the 'yaw' movement—is not operational in this iteration, the primary focus was on the leg's up/down movement capabilities.

One notable improvisation was the use of a hastily clamped mount to a flexible support. This setup was crucial in providing the freedom of movement required while still managing to lift a weight of 370g. It's a testament to our iterative design process, where even makeshift solutions can lead to valuable insights.

On the Horizon: Inverse Kinematics

Moving forward, our journey takes a calculated turn towards the precision of Inverse Kinematics (IK). IK stands at the intersection of design and mathematics, simply translating desired leg positions into specific servo angles. This mathematical approach is the cornerstone for designing diverse robot gaits.

Before we dive into the complex world of gaits, our immediate next steps involve crafting a robust design, delving into the mathematics, coding the solution, and rigorous testing. Stay tuned for our next update, where we'll share our progress in making these calculations a reality for Mojo5.

Mojo5 - Moving forward in the design (#5)

In our latest chapter of the Mojo5 saga, we're diving deep into the tangible world of robot building, where every breakthrough is hard-won, and every detail counts. This update is all about the real, hands-on progress we've made since last time, focusing on practical challenges and our solutions.

Here's what we've been up to:

Refining the Yaw Axis: We've successfully printed and assembled the new components that accommodate Mojo5's improved yaw movement. This time around, we're talking about the nuts and bolts—literally. Using 30mm M3 screws, to provide the Axis for the Yaw. Now, it is important to consider the build order as the 30mm bolt is added through the servo mount to the yaw frame. The locking nuts and Yaw Gear have to be added before passing through the frame.

Mojo5 - New 3rd Axis added to design

In the photo you can see the original paper sketch, and the 3D printed version. The previous post has the openSCAD version.

Putting Strength to the Test: We didn't stop at design improvements. To really see what Mojo5 can handle, we added a 370g load to its leg. It's essential for us to keep testing the limits and capabilities of our design, especially when it comes to real-world functionality. You can catch this test in action on our YouTube channel https://youtube.com/shorts/EplPBtQ46vw , where we've captured the whole process.

Streamlining the Design: while always on iterating the next improvement, we've started to pare down Mojo5, removing unnecessary parts and integrating a smaller Abductor Servo. This step might seem like we're taking things away, but in reality, we're optimizing for efficiency and performance. Sometimes the best part is the part you leave out - Engineering saying.

Mojo5 - The next iteration, removing un-required structure

Looking Back and Charging Ahead

These updates are more than just progress; they're a testament to the iterative nature of building robots. Each step, whether it's a new screw or a test under load, teaches us something vital about our design and its possibilities.

And as we dive into refining Mojo5 further, removing the extraneous and focusing on what truly matters, we're reminded of the essence of hobby robotics: it's a journey of constant learning, adjusting, and, most importantly, enjoying the process.

We Want to Hear From You

Your thoughts, feedback, and ideas have been incredibly valuable throughout this project. As we continue to navigate the complexities and joys of robot building, we're eager to hear more from you. What challenges have you faced in your projects? How do you approach problem-solving and iteration?

Let's keep the conversation going. Stay tuned for more updates as we push forward, one prototype at a time.

Catch you in the next post!

Mojo5 - Rethinking for the Yaw (#4)

Hey everyone! Diving into the heart of our Mojo5 robot project, we’ve hit that exhilarating moment where stepping forward means transforming everything from the ground up. Realizing this early in the prototyping phase? Priceless.

In this fourth installment, we’re rolling out the 'Yaw' – and yes, for our savvy crew following along, that's our latest dive into giving our robot an extra degree of freedom. This isn't just any move; it's what will let our robot's foot pivot with finesse, moving in and out from under the hip, enhancing its agility.

Mojo5 "yaw" mount around servos mount

Our solution? Introducing a lateral axis by creatively engineering a yaw mount that wraps around our existing servo setup. For those of you who’ve been with us, you know the servos and mounts are already pushing our size limits. So, in a stroke of insight, we decided to rotate the entire servo mount by 90 degrees. It’s a straightforward yet revolutionary tweak that cuts through our design challenges, though it does mean we’ve got our work cut out for us updating the OpenSCAD code. But, considering we're still early in the design phase, it's the perfect time for such ambitious changes.

Working in the CAD system really shines here, allowing us to simulate and verify our modifications in real-time. We managed to dial in the yaw movement to achieve +30 and -30 degrees of motion by adjusting just one variable. It’s clear, though, we’re not done iterating; we’ll need to push beyond these angles for the mobility we’re aiming for.

Mojo5: Yaw at +30 degrees

Figure: Yaw at -30 degrees

These figures highlight not just the potential of our design but the iterative nature of robotics itself. While 'Yaw' may be our current terminology, it's the concept and the progress that truly matter.

As we navigate through these updates, your insights and enthusiasm fuel this journey. The path of rapid prototyping is fraught with revisions, but each step brings us closer to realizing the full capabilities of our Mojo5. Stay tuned for the next leap forward!

Note: the correct term for "yaw" would likely be abduction and adduction:

• Abduction is the movement away from the central axis of the body or, in this case, moving the leg outward from the body's midline.
• Adduction is the movement towards the body’s central axis or moving the leg inward toward the body's midline.

Mojo5 - Testing the Leg Design (#3)

Mojo5 - Leg Design Test setup

It has been a few months since had some focus on this robot. As a stalled project, it always sits in the back of your head. The next task was to test the configuration to see if this design would be strong enough to lift its own weight in addition to the additional weight of the robot - Chassis, controller, battery, etc.

This weekend, I had a clear desk and I set up the test stand - which failed immediately, snapping my quick clamp with a loud snap. After some time, it occurred to me that I could have the 'chopsticks' extend out in two directions and this would be sufficient to test. Voila!

The robot Leg design with its cam and push rods was easily able to lift 450g + in addition to its own weight. I could not easily strap any additional weight to it. But, I am quite satisfied with this amount of payload for the moment!

Hey - did you notice I am using a Champagne Cork for the foot! :)

A more RUGGED robot platform for Exploration

continuing on the these of robotic design, with the help of AI (robotics) tools... 

 It seems our last attempts resulted in an unexpected robot! The broad pink and white stripes, soft lighting, and big goofy grin resulted in a "Total Adorable Robot".

Extra Adorable, Totally Not Evil Robot

However, I do not think that that Robot would survive very long in the Sonoran Desert!  There for, back to the discussion, and lets add some design that would work in a sandy, rocky region:

The first in the conversation, when reminded that the robot needed operate in rocky or sandy environments, it added broad wheels in an awkward arrangement.  I could imagine this also as a treaded solution. The bigger innovation perhaps is having the sensor platform as a (potentially) pivoting top component over the drive chassis. The streamlined frame looks like it would handle wind storms much better. The front sensors and display may need some protection and covering. overall, this is a much more robust robot.  But where is the manipulator arm?

The next variation of the prompt placed the robot in an icy, rocky environment and requested it have a manipulator that inspects geology:

The wheels of this Robot are considerably more realistic. It is also quite plausible that this robot would fall over. If you examine closely, there is a suggestion of the manipulator arm jutting out between wheels, but it gets blended into the axel and is lost. 

The next request required that the manipulator be the focus of the image.

This version has even more rugged wheels and a top structre that looks like it could support a wide variety of payload. The manipulator arm is placed in a difficult position, but looks robust and effective.

The Rugged, Wheeled Hexapod:

What if the Wheels of the robot were replaced with rugged manipulators with wheels? The robot could crawl over rocks. Here is a potential variant:

I like this concept robot a lot. It would require very strong actuators and some compliant joints. By having some wheel motion capability at the end of the manipulators, the robot could roll and climb in difficult terrain. The top structure has the appearance of a turret, to move to present its sensors in all directions.

There is a lot of potential with a robot design like this.

For those interested in learning how OpenAI's ChatGPT and DALLE-3 work, the last three images were all generated using the exact same prompt. Here you can see how variation is introduced when executing the same prompt.

and once again:

Prompt: 

A robust, medium-sized exploration robot designed for rugged terrains, now uniquely featuring six multipurpose manipulator arms, used for both agile movement and examination. The robot has no wheels and moves by crawling on these manipulator arms. The body of the robot is adorned with broad pink and white stripes, presenting a friendly appearance. It has smooth, rounded contours, similar to an animal-like form. A digital display on the front shows a goofy grin, adding to its welcoming demeanor. The manipulator arms are made of strong, lightweight material, matching the robot's color scheme. These arms are intricately designed, demonstrating their flexibility and dexterity as the robot crawls across a challenging landscape, using them to navigate as well as examine geological features. Soft, warm lighting and clear branding with labels like 'Research Robot' and 'TOTALLY Not Evil!' are included in the design, with a focus on the unique functionality and design of the manipulator arms in the rugged environment.

Interesting what might actual make these images unique.  Once rendered it would be almost impossible to re-render the exact same picture.  See for yourself how very different they are drawn, given the same instructions.

Of course, they are all supposed to have six arms, and the last two only have four! They are also each supposed to have "Research Robot" and "Totally Not Evil!" stickers on them. It seems we stil have some more learning and progress to get DALLE3 on task, even when it was in a moderated thread with ChatGPT.

A Robotic Platform for Remote Exploration

A Robotic Platform for Remote Exploration, Sensing, and Monitoring

Earth Exploring robot concept that is "Totally" Not Evil!

Me and another Robot (LLM), design a robot for earth exploring!

let's design a robot platform for remote exploration, sensing, and monitoring.  What components would it need?

Designing a robot for remote exploration, sensing, and monitoring involves a combination of hardware and software components, each tailored to the specific requirements of the environment it will operate in and the tasks it will perform. Here's a detailed breakdown:

Hardware Components

1. Mobility System: 

   - Type: Depends on the terrain. Wheeled or tracked systems for ground, propellers for aerial, or thrusters for underwater exploration.

   - Material: Durable and lightweight, like carbon fiber or reinforced plastics.

[x] let us consider going for a rocky, sandy terrain with some vegetation, should be able to climb up a moderate slope.

2. Power Source:

   - Options: Solar panels, rechargeable batteries, or fuel cells.

   - Consideration: Longevity and environmental impact.

[x] electric and rechargeable, certainly. perhaps with multiple ports, incase someone wants to share a few watts of power.

3. Sensors:

   - Environmental Sensors: Temperature, humidity, atmospheric pressure.

   - Navigation Sensors: GPS, IMU (Inertial Measurement Units), lidar, sonar.

   - Specialized Sensors: Chemical sensors, radiation detectors, biological sensors.

[x] leave lots of room for sensors, that is what this is all about.

4. Communication System:

   - Options: Satellite communication for remote areas, Wi-Fi or Bluetooth for urban environments.

   - Redundancy: Essential to ensure constant communication.

[x] multiple options, use them all. perhaps even piggybacking on someone's iphone like an airtag?

5. Data Storage and Processing Unit:

   - Type: Onboard computer with robust processing capabilities.

   - Requirement: Must handle large amounts of data from sensors.

[x] bigger the better. just put it in a safe environment.

6. Robotic Arm or Manipulator: (why not?)

   - Capabilities: Picking, sampling, or minor manipulation tasks.

   - Design: Lightweight and flexible.

[x] absolute!  what is a robot without a manipulator or two, three...

7. Protective Casing:

   - Purpose: Protect against environmental conditions like temperature extremes, water, dust, etc.

   - Material: Dependent on the environment (e.g., waterproof materials for underwater robots).

[x] this will be extreme use them all.

8. Camera System:

   - Types: High-resolution visual, infrared for night vision, possibly 3D cameras.

[x] need cameras, many! we are all watchers for where this robot can go.

9. Emergency Systems:

   - Components: Emergency shut-off, self-diagnostic capabilities, fault-tolerant design.

[x] this robot is on its own, it will need to be self-reliant. not sure on the shut-off though?

Software Components

1. Operating System:

   - Type: Real-time operating system for immediate response to sensor inputs.

[x] both OS and controller, ROS2 is a good start, with subcomponents and watchdogs on controller circuits.

2. Navigation and Mapping Software:

   - Function: Path planning, obstacle avoidance, and real-time map generation.

[x] SLAM! Bam, thankyou mam!

3. Data Analysis Software:

   - Purpose: Process sensor data to extract meaningful information.

[x] let us do some on site, and send the rest to the mothership.

4. Communication Protocol:

   - Design: Secure and reliable, able to handle varying signal strengths.

[x] assume sparse and periodic communications, this is reality really.

5. AI and Machine Learning Algorithms:

   - Application: Autonomous decision making, pattern recognition, predictive maintenance.

[x] the fun part!

6. User Interface:

   - Features: Remote control capabilities, data visualization tools, alerts and notifications system.

[x] all of the above. lets give it some on-board UI, as well as the remote operations.

Additional Considerations

- Modularity: Designing the robot with interchangeable parts can enhance versatility and ease of maintenance.

[x] done!

- Scalability: The design should allow for easy updates and integration of new technologies.

[x] absolute

- Sustainability: Consider the environmental impact of the robot during its lifecycle.

[x] be kind to earth.

- Legal and Ethical Compliance: Ensure compliance with regulations in areas of operation, especially for data handling and privacy.

[x] don't hurt Hooomans!  after all it must be TOTALLY Not Evil!

- Safety Features: Crucial if the robot operates in public spaces or near humans.

[x] hey, don't hurt the meatbags!

Speculative Technologies

- Swarm Intelligence: For tasks that require large-scale monitoring, using a group of smaller robots working in a coordinated fashion.

[x] oh yeah! Robots that have robots!

- Advanced AI: For autonomous decision-making in unpredictable environments.

[o] so easy to say, what does this even mean anymore?

- Wireless Power Transfer: To recharge without physical connectors, enhancing the robot's autonomy.

[x] or better yet, lets harvest it from 'sources'

I think it would need to look friendly so that it is not abused by Hooomans that find it. 

Absolutely, the robot's appearance plays a crucial role in how it's perceived and treated by the public, especially if it's operating in areas where it might encounter people. A friendly, non-threatening design can help to mitigate the risk of abuse or vandalism. Here are some design aspects to consider for a friendly appearance:

Design Elements for a Friendly Appearance

1. Color Scheme:

   - Selection: Choose soft, approachable colors. Pastels or bright, non-intimidating colors like light blue, green, or yellow can convey friendliness.

   - Purpose: Avoid aggressive or military-like colors that might be perceived as threatening.

[x] lets go with broad Pink and White stripes.

2. Shape and Form:

   - Design: Rounded edges and smooth contours are generally seen as more friendly and less aggressive than sharp angles and points.

   - Inspiration: Take cues from popular consumer electronics or characters in family-friendly media that are known for their approachable designs.

[x] Animals have rounded edges too.

3. Size and Scale:

   - Proportion: Not too large to be intimidating, but not so small as to be easily tampered with. A medium-sized build can be optimal.

   - Aspect: Humanoid or animal-like features can be engaging and relatable.

[x] medium is good.

4. Facial Features or Equivalent:

   - Display: If applicable, incorporate a simple, digital face or emotive lights. Expressions like a smile or blinking lights can create a sense of friendliness and approachability.

   - Interaction: Features that react to human presence (like turning towards someone when they speak) can foster a sense of interaction.

[x] true! maybe with a goofy grin on it.

5. Sound and Voice:

   - Tone: A friendly, non-threatening voice for any audio communication.

   - Sound Effects: Gentle, pleasant beeps or musical tones instead of harsh or alarming sounds.

[x] beep bop! Hello!   -- thanks R2D2!

6. Branding and Signage:

   - Labels: Clear, friendly branding with logos or mascots that suggest helpfulness and positivity.

   - Information: Displaying its purpose (“Research Robot”, “Environmental Monitoring”, etc.) can help people understand its presence and mission.

[x] should clearly state that it is "TOTALLY Not Evil!"