Building a PC contr...
 
Notifications
Clear all

Building a PC controlled Robot

22 Posts
5 Users
7 Likes
863 Views
ElectricRay1981
(@electricray1981)
Member
Joined: 1 year ago
Posts: 119
Topic starter  

Hi All,

As promissed I would create a topic about my robot project. So here it is, I have been bussy for some weeks now and have tried several things some things worked and some not. But first things first and I will write down here what hardware I'm using and what my goals are.

Hardware

  • ESP Wroom 32 (15 pins)
  • This yellow motors which many people use for their robot projects. The ones I use are 3..9 Vdc controlled.
    image
  • Opto-Coupler speed sensors with LM393 as schmitt trigger
    image
  • For power supply I have chosen for 4x18650 Li-ion battery of 3100 mAh. I connected 2 in serries and those 2 pairs in parallel. In case my words were confusing below a circuit.
    image

    To power the ESP when on the workbench for testing I use a USB cable, when I let it drive I have a seperate 7805 to get 5 V for the ESP as power supply, the voltage regulator on the print is reducing it to 3.3V

  • To control the motors I use the TB6612FNG, to spare two pins on the ESP I placed on a PCB the 6612 and connected. I did this because in the future I would like to connect more and it was not the most difficult job to solder it this way. 
    image

Goals

  • I want to be able to control the robot from my desktop via WiFi. For this I have chosen MegunoLink I have been able to create WiFi communication with the ESP and can send commands to it and receive data.
  • Most important when sending a drive command it needs to drive straight.
  • When the robot is driving straight I want to add more sensors such as an Ultrasonic Sensor, Temperature and Humidity, maybe a display to read out battery voltage or maybe other parameters.

This is how the assembly looks like at the moment of creating this post. Offcourse this will not be final way of wiring everything but for testing purposes this is easier. I know there are sticking out some wires which I used to check if the PWM signal and speedsensors worked ok. Thos wires mad it easy to connect my scope.

Front view between the motors:

image

Side view

image

Top view

image

 

No the main issue and I think it is a very important thing to solve is making the robot drive straight. When starting this project I just send a PWM signal to both motors and let the motor drive forwards and hopefully in a straight line. But it did drive forwards only not in a straight line and therfore I thought I need to find a way the wheels of the motors rotate a the exact same speed cause this would make the robot drive straight. I thought as a newbie into robot building this was a logical step to do. I took the speed sensors and send them to a PID control loop. But the speedsensors had some pretty high spikes and this may make the PID controller work too much (hence maybe I'm not sure about this).

I have tried than filtering the signal with a moving average algorith and an exponential algorithm, both algorithms made the signal more stable and with less spikes. Offcourse filtering comes with some cons, and this was that the signals were lagging so the actual processed speed was lagging atwhat the PID controller had to do on a specific time. Last thing I did on some good advise from @davee I chose to use a handwritten algorithm which was must faster and seems to work decent but there are still spikes in the speed readings.

Now while writing this topic on my project and wrote the specs of the motors and power supply I noticed one thing thats worth mentioning and maybe have gotten me off track. I regulated on speed in m/s and the output of the PID controller is a PWM signal (8 bits so 0 - 255) but the motor specs are 3 to 9 V. This makes me think now that I need to figure out that if I say drive 0.25 m/s if that is enought voltage for the motors to run properly. This is something I have not checked and just think about this while writing this post, so even writing this post has allready some benefits)

Nevertheless my main question here for now is, is it anyhow the correct way to make the robot drive straight by controlling the speed of the motors. Maybe there is a much better way. Does it make sens to do this with PID control or should go start investigating other possibilities. Because at the end I think it should be possible to make this robot drive straight. And I would be very happy to make that work.

I have tried to give all the information I have at the moment and share them with any interested reader. If there is any information missing I am happy to share that if needed. 

Thanks in advance for any opinions and advice.

Grtz Ray

 

Grtz,
Ray


   
Quote
(@davee)
Member
Joined: 3 years ago
Posts: 1641
 

Hi @electricray1981,

  An interesting and informative article to open this new thread.

----

  As I commented in the previous thread, it was difficult to know if the differences between left and right were due to the sensors or the motors (or even both).

  An article I came across, after looking at your new message ... suggests adding  capacitor to clean up the spikes from the encoder ... could be worth a try ..

https://www.electroschematics.com/motor-speed-sensor/

Note, the article shows it with a HC-020K module, but the text says "I recalled that I encountered the same problem with the FC-03 module mentioned earlier. So, I applied my trick again and it worked like a charm", implying it works with the FC-03 that you have chosen.

I also note you say you have an oscilloscope, so as well as checking to see what effect the capacitor makes,  I also recommend you use to measure the waveforms and use it to compare the pulse rates that the microcontroller is reporting. (From the text, I presume the author of the article also did this.)

-------

Your problems might all be motor related, so you might not notice any difference to the overall performance of the system, but 'cleaning up' the sensor side of the system, to make sure it gives the most reliable data, means you have a solid base to tackle the real problems.

----

By the way, I don't what safety precautions you have, but as a start, I would make sure you have a fuse in series with the battery connections, keeping the wire from the battery to the fuse as short as possible, so that if you accidentally short the batteries, the current flow will be interrupted. Those batteries can deliver a high current, as well as catch fire and explode if they are mistreated.

-----

Best wishes, Dave


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Member
Joined: 1 year ago
Posts: 119
Topic starter  

@davee 

Hi Dave thanks again for a detailed comment. I'll study the article further but this could surely help a bit and clean up the measured signal. I will post result of the measurements later on.

I skimmed the article and I noticed that the author did also computed the rpm value a different way as I do. He/she is counting the pulses over a fixed timeperiod. So in the function which is called by the interrupt only a count++ appears. I think this is exactly what @zander tried to explain to me in his last post at previous topic. This way there is less work in the ISR and the code won't be blocked. Fixing this will be the next step.

Posted by: @davee

By the way, I don't what safety precautions you have, but as a start, I would make sure you have a fuse in series with the battery connections, keeping the wire from the battery to the fuse as short as possible, so that if you accidentally short the batteries, the current flow will be interrupted. Those batteries can deliver a high current, as well as catch fire and explode if they are mistreated.

You are right about this and I will change this, Ill need to order some fuses with a holder and a decent power button would harm as well.

Grtz,
Ray


   
DaveE reacted
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 3 years ago
Posts: 6856
 

@electricray1981 That is a great post, Ray. You are on the right track and @davee has added some good ideas. I don't see anything I can add, other than are you may be expecting too much from hobbyist-level parts. A good resource person for this would be @inq, he just finished a small robot and posted a video where I think it was able to drive straight. Try tagging him at @inq. I am sure he can point you to an online resource. Good luck.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2042
 

Posted by: @zander
@electricray1981 A good resource person for this would be @inq, he just finished a small robot and posted a video where I think it was able to drive straight.

He used stepper motors.

 

 


   
Inq reacted
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2042
 

@electricray1981 

He/she is counting the pulses over a fixed timeperiod. So in the function which is called by the interrupt only a count++ appears. 

That is how all the examples I have seen use the interrupts to count pulses.

As you have an oscilloscope you should be able to see how clean the square wave pulses are.

 

 

 


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Member
Joined: 1 year ago
Posts: 119
Topic starter  

@zander

Posted by: @zander

I don't see anything I can add, other than are you may be expecting too much from hobbyist-level parts.

Maybe you are right and I am to critical or expecting to much of the hobbyist parts. Let's be honest this is no NASA material for the new Mars Rover. 🤣 

Grtz,
Ray


   
Ron reacted
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
 

Posted by: @zander

@electricray1981 That is a great post, Ray. You are on the right track and @davee has added some good ideas. I don't see anything I can add, other than are you may be expecting too much from hobbyist-level parts. A good resource person for this would be @inq, he just finished a small robot and posted a video where I think it was able to drive straight. Try tagging him at @inq. I am sure he can point you to an online resource. Good luck.

I've already mentioned, I prefer using the stepper motors as drivers in this thread.  Digitally precise, and consistent to each other.  You tell them both to move 10,000 steps and if you're wheels are equal in circumference... it'll be a perfectly strait line.  I'm rooting for @electricray1981... I'd like to see how a regular motor / encoder / PID solution will work, and... I think he has the proper experts posting in.

My first robot was just as @electricray1981 is attempting.  I NEVER got it to go in a strait line.  Even the motors/driver heating up causes slight changes in behavior enough to take it on a drunk'n tangent.  As a side benefit, you could cook eggs on it.  It also goes through a pair of 18650's in no time at all.  Whereas the Inqling Junior will run for well over an hour on the same batteries.   I just dug Chester out of the attic.

PXL 20230304 143302427

 

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
robotBuilder
(@robotbuilder)
Member
Joined: 5 years ago
Posts: 2042
 

@inq 

 I NEVER got it to go in a strait line.

However it is possible 🙂

One thing @electricray1981 might like to try is dead reckoning using the encoders.  In theory you can always compute the POSE (2d position and direction) of the robot base at any time.  This will show any left or right drift and the direction to move to get back on track. Over time the computed POSE will drift away from the real POSE thus the need for sensors to reset where it is and in what direction it is pointing.

I also notice that some use a gyro sensor including some commercial robot vacuum cleaners to keep on track.

 

 


   
ReplyQuote
Ron
 Ron
(@zander)
Father of a miniature Wookie
Joined: 3 years ago
Posts: 6856
 

@inq WOW, that is great info Dennis. I too have a similar kit but have not built it yet due to inadequate workspace and ill health. Both those issues will be resolved this summer so by fall I will be hard at it. I too was looking to buy a scope even though I was skeptical as to their utility. I found your article on the logic analyzer and will go that route instead. Are you using the free or paid version of the software? I see their software is available not only for Mac but even M1 compatible!

Can I trouble you for a link to the analyzer you are using? I have one but I am afraid it may be a piece of junk.

First computer 1959. Retired from my own computer company 2004.
Hardware - Expert in 1401, and 360, fairly knowledge in PC plus numerous MPU's and MCU's
Major Languages - Machine language, 360 Macro Assembler, Intel Assembler, PL/I and PL1, Pascal, Basic, C plus numerous job control and scripting languages.
Sure you can learn to be a programmer, it will take the same amount of time for me to learn to be a Doctor.


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
 

Posted by: @robotbuilder

However it is possible 🙂

That I have no doubt since most people seem to go this route.  I just took the easy way out.  I was more interested in the AI than making the silly thing move in a strait line.  It takes no CPU cycles to keep steppers on the strait and narrow and I wanted to reserve those CPU cycles for my interests. 😆 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Member
Joined: 1 year ago
Posts: 119
Topic starter  

Well just finished some measurents with funny result but I think I will leave it as it is as adding the C of 100 nF made things even worse. But the good news is this I probably have discovered where the pulse come from.

I measured the pulses from the speed sensors first before adding a C.

1st measurement @ PWM output 75
It is hard to see on the screen shot I know but pulse frequency is het 51.02 Hz. With this value I can compute the speed. We don't have LATEX options here so:

21.74/20 = 1.09 Hz for 20 pulses,
multiplying this by the Wheediameter and PI:

1.09 * 0.0664 * PI = 0.227 m/s

Pulses at PWM 75

To compare this calculation with what the GUI on the screen shows I turned on the WiFi connection:

Pulses at PWM 75 WiFi connection

Now a lot of spikes appeared but nevertheless the GUI showed me a speed of 0.22 m/s but fluctuating a bit. So I thought the C will be a good solution but when I carried out the same mesurement 

2nd measurement @ PWM output 75
So I have the same output to the motors but only added the C on the speed sensor. The result was as below the signal is less squared and still noise when I connect over WiFi. But the weir thing is that my GUI told me now the the speed was 0.47m/s even though the cursors on the scope show me the exact same frequency.

Pulses at PWM 75 WiFi connection and C

 This all makes me conclude the I can better work without the C cause now things are worse. Eventually this was a good test cause I guess those spikes come from the WiFi connection.

Next will be fiddling with the parameters of the handcoded algorithm to see if I can smoothen a bit more and see if I can tune the PIDto make the best of it. Further I probably have to except that this indeed as @zander mentioned this is hobbyist material.

 

Great test though

 

Grtz,
Ray


   
ReplyQuote
Inq
 Inq
(@inq)
Member
Joined: 2 years ago
Posts: 1900
 

Posted by: @zander

@inq WOW, that is great info Dennis.

Don't want to hijack the thread - Are you talking about this post I did about oscilloscope vs logic analyzer? https://forum.dronebotworkshop.com/postid/30513/

The software is free and the link is in that post.  I didn't know they have a paid version.  The hardware is  shown in a couple of posts above that one https://forum.dronebotworkshop.com/postid/30501/ and is a dime a dozen (actually ~$12) on almost any Amazon, eBay, AliExpress.... etc.  Just search for logic analyzer and sort on cheapest... you'll get dozens of hits.

 

3 lines of code = InqPortal = Complete IoT, App, Web Server w/ GUI Admin Client, WiFi Manager, Drag & Drop File Manager, OTA, Performance Metrics, Web Socket Comms, Easy App API, All running on ESP8266...
Even usable on ESP-01S - Quickest Start Guide


   
ReplyQuote
(@davee)
Member
Joined: 3 years ago
Posts: 1641
 

Hi @electricray1981,

  There is indeed something weird going on if those pulses are the same timing, but your software is reporting different pulse timing.

With a 'digital waveform' like that shown, the normal approach is ensure the hardware reports the timing with respect to the transitions through approximately mid-voltage of the pulses, so that the little spikes at the top and bottom of the pulses are totally ignored.

I am wondering if the 'little' spikes are actually narrow, but of much greater than magnitude than your scope is suggesting. The microcontroller may be able to 'see' those spikes and hence could mistakenly count them.

This is not a criticism of the scope, but a natural consequence. You say the pulse frequency is about 50Hz, so each pulse top or bottom will have a length of about 10 milliseconds, whilst WiFi data rates are in the MHz, typically 10s of MHz region, and the carrier frequency is 2.4GHz, all of which suggests any WiFi related breakthrough will occur in very much shorter periods of time than that represented by a single pixel of the scope.  Hence the scope will be unable to show the 'real' situation.

Sometimes, speeding up the timebase, and playing with the trigger controls will help to show these sneaky pulses.

Of course this is all speculation on my part. These are just things to look out for.

....

I wonder if you have some power distribution issues. ESP32 boards have a reputation of having inadequate decoupling, especially with respect to current demands when WiFI is active. You might like to investigate the effects of adding decoupling capacitors, etc. Unfortunately, this can be quite a tricky problem to investigate and fix. 

Best wishes, Dave

 


   
ReplyQuote
ElectricRay1981
(@electricray1981)
Member
Joined: 1 year ago
Posts: 119
Topic starter  

@inq 

First of all I think this should be a topic in geenral so if tools come up in the topic I'm all in. 

I don't have a logic analyzer because I never had to use one but a scope is something I use on a regular base here at my hobby workbench or for work. I bought around 3 or 4 years ago a OWON scope the VDS2062 for around 260 eu. This device has helped me so much for private stuf but also for stuff at work. It is light compared to a Fluke scope. It is accurate enough for the stuff I use it so for me it's perfect.
The free software that comes with it are the screenshots I use in previous posts. Also not bad but the screenshot unfortunately doesnt show good the settings and cursors, the could/should make this a bit better IMHO.

OWON makes prety nice stuff I also recently bought a extra multimeter from them it is a decent device ut a bit slow. I mean with slow that when I measure a resistor with my Fluke 87V I have immediatly the value but the OWON multimeter takse a couple of seconds. But for home use compared to the the difference in price it is a nice device. 

I thought logic analyzers are just for analyzing e.g. serial communication and monitor the bits that are passing by?

Grtz,
Ray


   
ReplyQuote
Page 1 / 2