Inqling Junior - Robot Mapping, Vision, Autonomy

@inq

No questions yet, but most certainly encouragement 👍.  I keep getting distracted from my robot project, latest impediment is the repair of some sections of my kitchen garden fence that succumbed to some storm winds back in February.  (its one new fence post put up, 10 to go 🙄 and I worked bloody hard in the midday sun).  

But advice .... well I hope you know about the curse of the Robots.  A lot get started, but few make the finish line.  May the force be with you. 

I will be following alone and making copious notes of everything you do.  

Posted by: @byron

I keep getting distracted from my robot project, latest impediment is the repair of some sections of my kitchen garden fence that succumbed to some storm winds back in February.  (its one new fence post put up, 10 to go and I worked bloody hard in the midday sun).  

I hate it when life gets in the way of my projects.  I've got a shed to build and I procrastinate during the mid-day sun.  🙄 ... truth be told... I procrastinate even when its cloudy and in the morning and in the evening.  😋 

Posted by: @byron

But advice .... well I hope you know about the curse of the Robots.  A lot get started, but few make the finish line.  May the force be with you. 

Thank you... and as you see in the Inqling robot, I take small baby steps.  Although simple, it achieved all goals set for it.  It communicated data, it was controllable, it moved.  SCORE!  The fact that it moved like a college student after a three day bender... well... Grace and sophistication were not on the expectation list.  😆 

Junior isn't much of a stretch.  I'll be standing on the shoulders of giants by using two projects I found on the Internet for the hardware side.  I'll get it balancing and moving.  If I run into any rough spots, I have this forum and many experts in just about any aspect.  Its not like I'm bashful about offering or asking for help.

😉 I'm just dying to come up with some projects to use the MQTT stuff you taught me through.  I think it'll be the next best thing to sliced bread for the proper projects around the house.  

The vision, mapping and automation is mostly all software and I've got a pretty good idea how to approach those problems.  Should be fun.  

VBR,

Inq

Posted by: @byron

@inq

But advice .... well I hope you know about the curse of the Robots.  A lot get started, but few make the finish line.  May the force be with you. 

It depends on what your end goal is.  It was always my goal to have a practical working (doing jobs) robot. Toy robots are great to develop the basic skills to build an autonomous robot with mapping and vision but building one large enough to do useful things is another ball game particularly in terms of cost of hardware.

Help with A4988 Adjusting

I imagine, this thread will have few followers, so I'll add problems I encounter as separate threads hoping I hit a broader audience.  

https://forum.dronebotworkshop.com/motors/mal-justed-a4988/

Thanks,

Inq

@inq 

Good luck with your robot project, I hope it can work in the end!

I've also noticed that you do much more testing for this robot than I did with mine.

I have almost never used a breadboard as a "testing board" for the circuits in my projects, instead        using directly whichever board I wanted for the finished result.

And I usually try to not base my projects on anything that someone else made, since that would seem less interesting to me.

Well, I guess everyone has their own way of building things.

Have a nice day

Valerio

Posted by: @valerio

I've also noticed that you do much more testing for this robot than I did with mine.

I have almost never used a breadboard as a "testing board" for the circuits in my projects, instead        using directly whichever board I wanted for the finished result.

I must not be as comfortable with my hardware prowess as you.  I like to build them up in small steps on the breadboards.  Case in point with my last post... if I had just gone strait to robot, and if one A4988 was maljusted, I would have some hot-mess trying to figure out what was wrong.  

Posted by: @valerio

And I usually try to not base my projects on anything that someone else made, since that would seem less interesting to me.

I would agree completely on the software side... as evidenced by my library... that rides on top of Espressif core code.  It does not rely on Ivan Grokhotkov's work and it does all web server, web sockets, and application event logic.  I also wrote the EEPROM and the file systems that are not based on SPIFFs or LittleFS.  Both use wear leveling which none of the Arduino libraries had when I started my versions.

I will only be using the Internet based balancing robots software to get the first stab.  As stated above, the primary goals for Inqling Jr on the software side that will be totally written by me include:

• Mapping
• Optimal path creation between known points of a mapped area.

Once those are working, I will consider Inqling Jr a completed success. 

Its bad luck to project too far ahead, but... Inqling Jr is just one step on the path.  I've already started CADing up Inqling the 3rd and have scoped Inqling the 4th.  So you see, I don't only use baby steps at the component level, I do it at the milestone level.

Using Inqling Jr, I will be replacing the balancing software with a clean sheet software design.  The new software will be able to balance with an arbitrary CG.  If you note with all hobbyist level balancing robots, they are absolutely dependent on a known and fixed CG.  They simply use gravity to detect down and assume that the CG is fixed somewhere above the wheel contact points.

Having a weight added at runtime that moves the CG one way or the other will cause those robots to fall over.  I will endeavor to make mine compensate based on a dynamic CG... like:

That feature is required for Inqling the 3rd.  

VBR,

Inq

Posted by: @inq

I must not be as comfortable with my hardware prowess as you.  I like to build them up in small steps on the breadboards.  Case in point with my last post... if I had just gone strait to robot, and if one A4988 was maljusted, I would have some hot-mess trying to figure out what was wrong.  

I don't think it is really hardware experience...it is most likely just a lack of patience.

But I managed to make most of my projects work in the end, in some way or another.

Also you also seem to do multiple versions of the same project on after the other.

Regardless of how Zalophus turns out, I don't think I would do the same.

In general I never try to restart a design right after finishing it, I prefer to do something completely unrelated.

Moving on to another topic, did you make any other robots or microcontroller projects before Inqling Senior?

I have created one other robot... well... just a remote control job.  I named it Chester.  I think it used the same motors/gears/driver you're using on Zalophus???  

It convinced me to never use plain motors again. 

1. It was pretty slow.
2. You could cook eggs on the driver
3. Motors were very noisy using PWM.  I even adjusted the PWM frequency in an attempt to reduce noise.
4. The motors were very non-linear.  Even if you balanced the speed of two motors at one speed so it would go in a strait line, at another speed, it would veer.  Try it a second time at the calibration speed and it would veer.  You would have to have some kind of Gyro/Magnetometer feedback loop to make it simply drive strait.
5. It's why I use stepper motors for drive units.  Strait as an arrow!

I think its still up in the attic somewhere, but I couldn't find any pictures.  I simply wasn't impressed enough to memorialize it in photos.  Here is the CAD image. 

• The motor units could snap in/out  (Green/Yellow Clips).
• Metal motor portions stuck out over the aqua shelf. 
• Aqua center raised platform held the motor driver.
• Purple piece held the round master toggle switch.
• Two 18650 cells were housed in the Blue box.
• WeMos ESP8266 was mounted on top of Blue box.
• The Orange piece out the back was just a skid that slid over carpet and smooth floors easier/lighter than a caster unit.

I know you'd prefer to do it yourself, but if you're even remotely interested in the them, I can upload the STL files for you.

VBR,

Inq

Footwear (100 mm)

Wheels - 4 halves, ABS, time 3:35, 32 grams

Tires - 2 treads, TPU, time 1:14, 14 grams 

@inq 

The gearmotors are similar, but not the same.

The GM9 has a much higher torque (almost six times) and slightly lower RPM than the typical yellow motors that are sold on amazon.

Considering that it's a bit more expensive, I hope it does not have these issues you talked about.

And speaking of close-loop control, I actually planned to implement something similar on the Zalophus, using motors with magnetic encoders mounted on.

However, said motors would have had a really high stall current (2.8A vs 700mA of the GM9)

and to increase battery life and decrease stress on the driver (which is rated for a maximum of 2A)

I decided to use standard gearmotors, since encoder control was an extra feature.

If possible, I would like to get the .stl files.

I may learn something by taking a look at them.

Have a nice day

Valerio

@inq

@inq wrote:

I have created one other robot... well... just a remote control job. I named it Chester.
It convinced me to never use plain motors again.

1. It was pretty slow.
2. You could cook eggs on the driver
3. Motors were very noisy using PWM. I even adjusted the PWM frequency in an attempt to reduce noise.
4. The motors were very non-linear. Even if you balanced the speed of two motors at one speed so it would go in a strait line, at another speed, it would veer. Try it a second time at the calibration speed and it would veer. You would have to have some kind of Gyro/Magnetometer feedback loop to make it simply drive strait.
5. It's why I use stepper motors for drive units. Strait as an arrow!

This looks like an interesting project. After looking at some self balancing robots on utube using two stepper motors I am tempted to follow one of the builds.

UPDATE

OK... @davee got me back between the guardrails with the A4988.  https://forum.dronebotworkshop.com/motors/mal-justed-a4988/#post-30847

Also, I going to try a different method to move the ToF sensor.  Above, I mentioned, I was going to use two servos for "eye" pitch and yaw.  Two things changed my mind... (1) the servos are rather noisy and abrupt.  (2) More importantly, they only go +/- 90 degrees.  I would like +/- 180 on the yaw axis and Inqling 3rd will need +/-180 on pitch as well.  

After going through the A4988 thread (above) I've gotten more comfortable with using stepper motors and I happen to have some of these in my parts bin.  And since I haven't smoked any A4988's yet, these $1.40 darlings can drive 2 more stepper motors...

I've tried them out and I am able to throttle down the current with A4988 and use any voltage on them from their rated 5V up to the voltage that the main drive motors will use... either 14.8V or 22.2V.  Them being a lot smaller than the stepper motors should allow me to 3D Print a smaller eyeball.  They're very quiet so it won't have that servo noise and I'll be able to know exactly what angle they're at for the mapping algorithms.

Now... time to start dink'n with the sensors.

VBR,

Inq

UPDATE

Been around the house mostly doing other duties and can't really research/download drivers well because of bandwidth issues.  So, when time permits to the project, I've been doing mostly CAD and printing.  At the library now... can download/research, but can't do projecting since the workbench/equipment doesn't transport well...  Besides, the library frowns on soldering smoke.

Designed

• Wheels / Tires (Printed)
• Motor Boxes (Printed)
• Battery Box for 4 18650 cells (Printed) 
• Battery Box Ends / Fenders (Printed)
• Laying out components for Electronics Layer
• Electronic Box (TBD)
• VL53L5CX "EyeBall" w/ 2DOF using Steppers (TBD)

Posted by: @valerio

And speaking of close-loop control, I actually planned to implement something similar on the Zalophus, using motors with magnetic encoders mounted on.

However, said motors would have had a really high stall current (2.8A vs 700mA of the GM9)

and to increase battery life and decrease stress on the driver (which is rated for a maximum of 2A)

I decided to use standard gearmotors, since encoder control was an extra feature.

Actually this is to anyone that has an opinion.  I was weighing @valerio comment here and had some thoughts and wonder what real robot builders do...

As I mentioned about my Chester robot above using motors was just a big C.F. for me.  It is my belief that no matter how good a pair of motors are there is no way the robot is going to travel in a strait line at every speed without some kind of feedback.  There are just too many variables...

1. Manufacturing variability will cause one to run faster with the same current.  No way you're going to find a matched pair at every speed.
2. One wheel may have a miniscule circumference difference.
3. One wheel may slip on the floor.

Encoder - Using an encoder may solve the first problem, but it seems to me that you would be adding a lot of feedback coding that would not be totally effective.  It won't solve #2/#3.

Stepper - Steppers solve the first issue without any feedback coding required.  At least you can be assured if you tell it to move 100 revolutions, both motors WILL turn exactly 100 revolutions!  I wouldn't think cost is an issue.  I spent $17 total for two stepper motors and two A4988 drivers.  How much would it cost for similar performance for a pair of geared motors, encoders and an appropriate dual motor driver?  I would think it would be more expensive.  3D Printing has brought stepper motors down into mass produced / commodity pricing. 

That leaves problem #2/#3

In other words, to solve these, you STILL would need some kind of feedback.  I have several ideas, but maybe... I haven't thought of all of them.  I want to hear what real robot hobbyists/designers/engineers use. 

How have you... or would you tackle a robot needing to travel 100 meters in a strait line???

• Without human RC feedback
• Outside (if you were thinking GPS) but Inside also.

VBR,

Inq