I'm just pondering some ideas, but could you instead run the whole robot from a Jetson Tx2 and have ROS so then you can add other sensors and having multiple programs in different languages.

I'm seeing the bottom STP file for the "remotes case" but I don't see the top where the joysticks are located with the switches. Could this please be added :) <3

He,
I love your Open Dog project.
I'm interested in developing a AI (Neural Network), based motion control for your robot and I would like do do it as a group project.

The problem is, that it would make no sense, if you don't wont it and you don't integrated it in to your OpenDog. Also I need your help finding people how are interested in it to.

Please don't mistake me for some on how don't now the challenges, of such a project. My plan is to Model the robot in a 3D environment, to train a Neural Network with reinforcement learning. I used reinforcement learning in the past, and I now that it is clearly possible to train a AI that can work. I don't now how well the trained AI will translate to the real robot. I guess that it will go ok, based on some papers I have read on this subject.

so if you are interested in this, or you have some additional questions, please contact me.

While weeding my garden, I was thinking that opendog (or a lightweight version) could be a great weeding robot!
It would work likes this:
Walk through the garden, find a small plant, make a few pictures, look it up at plant.net, and if it matches a user specified list, pull it out.
Wheels are no option for such a robot, so opendog would be great for this (but a bit heavy). Your projects contain all the elements to make this work
If it was a product, I would buy one!

Hey, I don't know if you already know this trick but you should consider using multiple files for one sketch instead of having everything in one bloated source file. The Arduino IDE makes this very easy:

1. Click the new tab button and name it however you want. It will create a second .ino file next to your original in the sketch directory, and open a new tab in the IDE.

2. Move your functions into the other files it creates, these functions are accessible in the main sketch file the same as if they where in the main file, no complex imports needed.

3. Save hours of scrolling through the big file when you could just switch tabs to find the function/bit of code you want.

It's not very well documented online, but it is sooo useful for code organisation.

p.s. please start using git properly... you could add tags to mark the code commit for each episode. Then note this down in the README for non git users to understand, much nicer than partX folders...

Hi James! I'm thrilled to see your new project open-sourced on github. I have already played around a bit with your model, doing a very rudimentary port of it into URDF format and displaying it in RViz, ROS' visualization tool: https://github.com/IanTheEngineer/opendog_robot

It occurred to me while working with your models, that there isn't a license for your work. Without an open source license, it's not clear who can utilize, modify, and redistribute opendog, and how credit should be attributed to you. I'd recommend choosing a license, adding your copyright to it, and placing it in the openDog repository to be distributed with your code and models:

https://choosealicense.com/

For what it's worth, the licenses for code distributed the ROS ecosystem are typically permissive licenses like BSD, MIT, or Apache 2.0: http://wiki.ros.org/DevelopersGuide#Licensing

Working with releases can optimize merging code from different parts/episodes. The code would not diverge too much from each part as every PR would be against the current and same code base. Redundant efforts are eradicated and productivity improved. Confirmed builders could be instated as maintainers to help overview code changes (this bit has nothing to do with this issue). All in all those are only suggestions.

Hi James, love the project! I just have a few suggestions on how to organise your code; a few small changes that would make contributing to the repository much easier.

By organising the code into "parts" corresponding to your videos you're not really exercising the real power of Git. Instead of having copies of the main dog INO file with each video's changes in a different directory, you should have a single file that you change and make a commit for each video you produce. This would help clean up the repo and mean if anyone makes a pull request with useful changes to the code, it's easy for you to pull those changes into your file and don't have to manually sync those changes into files you have yet to push.

There is a useful discussion on the topic in this StackOverflow question.

There are a number of common structures that could be defined in a common header file so that if you needed to make extensions, you only have to do that in one place.

Cheers,
Jake

Is there a BOM (Bill of material) file for this ?
If I want to do it in my home , I have to buy some stuff I think, like aluminum profile and bolt and nut.
But I don't know the size of each .

And , Great Dog , thank you for your share!

As you discussed in the video, a mini-ITX motherboard mount will be useful. However certain things like large coolers or graphics cards for vision processing might be too heavy and break the motherboard due to the frequent jerking motions of a robot taking steps. Could you maybe design it to have the motherboard mount to the front of a panel and then use a PCIe riser to mount expansion cards flat against another panel or the back of the same panel? That way vision processing could be offloaded to a graphics card freeing up the CPU without having a heavy card shaking about. The cooler issue might be trickier, but you could design a 120mm or 240mm radiator mount and use water cooling, or just use a low profile, lightweight cooler.

Hello James,
you write awesome functional code but have you ever considered to go further into oop? Maybe you discussed it in one of your episodes but I was just wondering why. Also you write a lot of different robot related bits of software that share a few key features. You could also consider writing your own framework related to your projects to save some work. A benefit would be while improving code for a project you improve code for other robots simultanously.

https://github.com/Technician13/QuadrupedInverseKinematic

just copy and paste the code together

Very impressed with the work that you are doing, and enjoy watching the videos.

In the latest you had the issue of maintaining belt tension when the leg under a lot of force/weight... since the force direction is asymmetric (ie always in a particular direction) can you create a upper leg which deliberately flexes a little and creates more tension in the belt as it does.

This maybe could use a cam to push on the tensioner as the leg flexes. As a side effect it would create a little more leg springiness by using the belt elasticity.

In your function dmpDataReady, instead of setting IMUdataReady = 1, try incrementing the value, then in your main loop, read the data IMUdataReady times to clear the FIFO and decrement that counter with each loop.
This will prevent fifo overflow and give you the most recent value from the IMU.
I would have added this to code and created a PR but part 19 isn't up.

void dmpDataReady() {
    IMUdataReady++;
}

...main loop...

// IMU test
while (IMUdataReady > 0) {
    readAngles();
    IMUdataRead--;
}

I would like to know where you got that fancy joystick, or what I should search for.
Maybe you can post the complete parts list here as well
Thanks!

You should use enum (or at least #define) to name constants such as LEFT_LEGS, RIGHT_LEGS,... instead of using number like 0, 1 which decreases the code readability.
for example:

enum LegSides{
    LEFT_LEGS = 0,
    RIGHT_LEGS = 1
};

or just forget the numbers:

enum LegSides{
    LEFT_LEGS,
    RIGHT_LEGS
};

then the function:

double leg(double Z, double Y, double X2, int side) {...}

will be:

double leg(double Z, double Y, double X2, LegSides side) {...}

and call it:

leg(x, y, z, LEFT_LEGS);

further here

I wanted to actually have the cad not the code ??

The check you have on Line 389, to avoid dividing by zero on Line 391 is incorrect. You are ensuring that the dividend (i.e. the number to be divided, X) is not zero, when you should be ensuring that the divisor (i.e. the number that divides the dividend, Z) is not zero.

Therefore the check should be to ensure that Z does not become zero. There is nothing wrong with the dividend (in this case X) becoming zero. As the X approaches zero, so does the value of the fraction - which is correct.

I note that Line 395 then uses the result of the hipHypotenuse, so it is this division that may need to be protected.

(Note: this error is made in multiple places)