Smart Motor Driver for Robotics

Hi, 

The last time I wrote here was a long ago. Today I want to show you a robot made with SAMI. 

In this demo you can see that the robot follows a straight path, then turns some times and after all returns exactly to the start point. Proving the precision of the controller:

Specials thanks to my friend Emily Velasco for the cover picture n.n

It was  a long time wihout writing updates in this project. So today I want to tell you how this thing is going. First of all it was a succes, the boards are selling very well on tindie and a lot of people seems to like it. 

Also in a few weeks a team of kids will be using them in a robot contest, and they have a great chance to win thanks to SAMI and how easy is to use them in a robot to program paths. Here is a small video that te kids send to me:

Thank you very much for all! 

I hope to have time soon and make some improvements thanks to the community feedback :)

Hi, I just want to let you know that the first batch is already on sale on Tindie, get yours here:

https://www.tindie.com/products/15726/

Thank you

I am happy to announce that SAMI will be available to purchase soon, I have some new motors with different gear ratios for final testing and at the same time I ordered required components for production and cool packaging materials are on the way to my house for this first batch. So stay tuned!!!

I have panelized the boards for production and it looks like this:

I hope that SAMI will be available for sale soon, thanks for all your support.

Remember all files are available on the project repository, this is my very first panel for automatic assembly so any advice will be useful.

Today I want to talk about the development of the project, limitations and future improvements that could be done to achieve an even better and powerful Smart Motor Driver.

As mentioned earlier in a previous log there are some limitations with the hardware and some things that only work in an ideal world. The first of all is about precision in Auto-Stop feature, a brushed DC motor can't be controlled to move exactly to a wanted position. Is just not possible, the encoder handles the measurement of this movement and working together with the PID control it does the best it can to move it to a desired position. The gearbox also plays a great paper in this, with a greater reduction relation it comes a bigger resolution and higher precision in the movements because the motor control doesn´t need to be that fine and the error gets reduced significantly. 

However with a lower reduction relation in the gearbox the error in position grows because the motor movements are just not enough small to allow have that precision. Another important thing that can affect the precision is the inertia, so PID gains should be tuned properly to reduce influence of the inertia. Things that not exist in an ideal world, but in reality are present. 

Also the encoder in SAMI uses only one channel, so it is less precise and can't detect direction of a movement induced by an external force in the system. All control algorithms on board suppose that only minimal external forces will be present, so take that in account when designing a solution with SAMI. The motor chosen in an application should be strong enough that an external force can't easily affect it. 

I designed SAMI to be cost effective and useful in many robotics applications. And I think I got it right, for a normal robot movements is more than enough to the the job right in a super tiny solution. However I know there is applications that require a lot more of precision in the same tiny package, like a prosthetic hand or a robot arm. This is why I am designing a second SAMI with more resources that allow to have a much better performance, but also more expensive. 

The main changes will be the addition of a full quadrature encoder (2 channels), motor current sense capability and a more powerful microcontroller, this will be distributed in a 2 PCB design to continue as a tiny solution. And this will be Pro edition of SAMI.

With a better encoder SAMI precision will be 4 times better and reduce errors significantly. Also it will allow to use your DC motors as a servo and hold their position even with external forces actuating on them. Current sense can be used to detect limits at calibration in a linear actuator implementation. Opening the door to a hole new universe of applications, prosthetic hands can now be done better and cheaper than before. 

And maybe one of the coolest feature will be that SAMI will be capable of record a movement and them repeat it. You will be able to program a robot arm by moving it with your hand while recording the movements with the encoder and them repeat it automatically sending it back to the motors.

Soon SAMI will be available for sale and after that I will start working in the Pro edition. I have come with a beatiful open-source project with a lot of potential to change how robots and technology helps people live better. For me is a small contribution, but I think together as a community we have the power to do great things and help others using SAMI.

Thanks to support the project.

In this log I want to share a great new function. Somebody suggested me that it will be cool and useful that SAMI can be controlled also by sending angles, not just distance. So this is what I have done. The auto-stop function now accepts data in angles, not just as plain distance. So for example now you can ask SAMI to move 360°  directly to do a full wheel rotation instead of sending the wheel circumference as distance to obtain the same result.

This was done as an easy upgrade, the code that does this is in the side of the library. Not in SAMI firmware. So is enough to download the new library to get the new function. You should know that SAMI receives/sends travel distance by encoder ticks and them the library converts this encoder ticks to distance using the wheel diameter as described in a previous log. 

This allow us to just make a new equation for convert this encoder ticks to angles instead of distance. And it looks like this:

Where steps are the encoder ticks, gear is the gearbox relation of the motor and angle is the desired angle to move. And then we add the new functions in the Arduino library to do conversions in angles for both directions (get and set): 

int32_t SAMI_2BRobots::getAngle(void) {
   	int32_t value = (int32_t)read32(SAMI_REG_DISTANCE_0);
     	value = (int32_t) ((double)(360*(double)value)/(3*(double)getGear()));
	return value;
}

void SAMI_2BRobots::setAngle(int32_t value) {
     value = (int32_t) (((double)(3*(double)getGear())/360)*(double)value);
    }

 As you can see is the same as done in distance conversion, just using the new equation.

Here you can see a small demo, firts its moves 360°, then -180°, after that 90° and finally -270° to return to the same start position.

The new library update is already available with the example included.

Thanks for reading :)

Hi

Today I wanted to show you a small video about the PID control typical reactions.

In the next video you can see a robot with 4 wheels, when I grab one to stop it at the time of release it an overshoot is caused. Next the wheel stabilises its speed but the distance gets a little bit off, so the motor now moves forward until it reach the desired position. 

Also you can see that the other wheels don't move until the one I grab finish its movement, them every wheel continues with the sequence.

This is ideal in a robot because it allows to sequence complex movements routines and automatically waits every motor is done before continue. This is done thanks to my library for Arduino that checks the "isRunning" flag to coordinate the sequences. This code is in the examples.

However this also introduces a new problem into the equation. What happens if motors gets slightly unsynchronized? Well the robot will not navigate so precisely or even do weird things in extreme scenarios. To correct this you should do a check in your master controller and keep things synchronized by getting is something unexpected happens. Also is a good idea to use a IMU to completely take off the error, other kinds of sensors can help too. 

What I want to say, is that SAMI would not make a miracle by itself. But together with clever programming and joining forces with other sensors can be an unbeatable navigation system. 

Thanks for reading :)

Today I am going to talk about something that is included on the Arduino library for SAMI. It is a little program that allow to obtain automatically the gains required for the PID control algorithm for both speed and distance controllers. 

It is based on the Ziegler-Nichols method, it is not too accurate but will do the job for most applications. Fine human tuning may be necessary in some cases. After all the fun is in experiment and watch the different reactions of the system with different values. 

This time I didn't do the job alone, the calibration code uses jack01 autotuner library and is already modified to work straight forward with SAMI for easy setup. However you must download his library separately to respect his amazing work with this Arduino Library.

Let's say no more and watch it in action:

Remember, this example and other useful ones about how to use SAMI are available in my Arduino Library. You can install it directly with the Arduino IDE Library manager, just serch "SAMI" and install the one that says my name on it ;)

Today I wanted to document how the auto-stop code works, this is now one of my favorite features of SAMI because it allows to do any other thing in the main controller while SAMI takes care of speed and traveled distance and then stop automatically using precision PID control. With some extra sensors like an IMU and a little bit of coordination in the main control to all SAMI's it can really do a big difference when controlling robot movements. 

So here is the code that powers this feature:

if (I2C_buffer.data.DISTANCE != 0 && loadDistance == 0) {
                        loadDistance = 1;
                        auxDistance = I2C_buffer.data.DISTANCE;
                        I2C_buffer.data.DISTANCE = 0;
                        stable = 0;
                    } else {
                        calculate_pidM(calculate_pidA(auxDistance));
                        if (auxDistance >= I2C_buffer.data.DISTANCE - ATS_tolerance && auxDistance <= I2C_buffer.data.DISTANCE + ATS_tolerance) {
                            stable++;
                            if (stable > stable_time) //travel distance stable at desired value for at least some time
                            {
                                loadDistance = 0;
                                M_control(0);
                                I2C_buffer.data.START_STOP = 0;
                            }
                        } else {
                            stable = 0;
                        }
                    }

As you can see when you first set the desired distance it loads into a temporal variable and then clears the register and sets a flag to know that it has been set-up. After that the algorithm starts running, we use the previously discussed PID control equations, but this time using the desired distance as the setpoint, the encoder traveled distance as an input and the output is going to be the RPM's to run the motor. They can't be higher that the RPM's limit set by the user. 

Now this is the important part, we have a flag to stop the motor when we reach the desired position, otherwise it will run forever making the motor overheat and also shaky due to the algorithm trying to hold the position. So to prevent that I have make a clever condition that basically waits some time before disabling the controller only if it is stable in the desired position. Obviously the desire position has a range up and down, because it will be almost impossible for a common DC motor to make too precise movements.

After the algorithm stops the motor when done, also clears the running condition flag in the driver. So now the host controller will now that SAMI has done and is ready to receive a new order. Pretty useful for sequencing moves in a robot without the "delay thing" hassle.