Building robots

@byron wrote:
"Re reading the post thread, I give a nod to @robotbuilder in his recommended use of a laptop computer to be the brains of a bot, communicating with on bot microcontrollers."

Remember I was interested in a medium sized robot with fast processing of visual inputs using my own software not the small compact swarm bots that interests @thrandell

You could use a wifi connection between a small robot to give it brain power. I just never went down that pathway.

@robotbuilder

Posted by: @robotbuilder

↑

Remember I was interested in a medium sized robot with fast processing of visual inputs using my own software not the small compact swarm bots

I did remember, and this remark was not relating to the robot swarm, but rather a post you made further back in the post chain of this tread which I re-read to remind me what it was all about, and I see I was pondering about using many boards, on a bigger board more powerful board on a bot.   Complementing whatever on board bots have with an external helper board is also part of the picture I will have to consider. (sometime when I get round to it.😀)

Posted by: @byron

↑

My understanding is that you have found that using two rpi pico boards in a bot and communicating via i2c to work well and have not (yet?) found the need to use both the pico cpu cores and the PIO abilities of the pico.

I did look into using both cores and the PIO but I couldn’t come up with a use case.  

I recall that maxing out both cores was NOT recommended, instead one core should be used for some light weight process, like monitoring status or whatever.  The Programable I/O sounds interesting but again I couldn’t come up with a use case.  I went the I2C route because I’d seen robot designs that use the technique to split out sensor functionality from actuator control.  Didn’t our host want to use multiple MCUs to control his Real robot?

One Pico feature that I’ve been thinking about is using flash memory to log runtime data.  It sounds doable but flash has a life expectancy of ~20K write cycles, so I’ll need to be careful.

Tom

@thrandell The flash memory in my Mac is expected to last 50 years at least.

Posted by: @thrandell

↑

One Pico feature that I’ve been thinking about is using flash memory to log runtime data.  It sounds doable but flash has a life expectancy of ~20K write cycles, so I’ll need to be careful.

Tom, here is a link to a github on the pico flash storage, that in turn gives a link to the data sheet of the flash storage chip that is used.  It quotes the cycle writes as a min of 100,000 cycles with a 20year retention period.

Maybe a bit more cycles than you think, if this is accurate. 🙂  Its also easy to get a SD card to link to your pico and perhaps that may be better for your data logs?

https://github.com/NegasonicX/Raspberry-PICO2040-Flash-Storage#

@byron

@byron wrote:

"... I was pondering about using many boards ..."

For me it is the Keep It Simple approach. A laptop does it all except for the need for an interface (thus the Mega) and when speed or timing is an issue. You can always expand the number of hardware modules but the core computing is most easily done with a laptop.

I was just thinking after reading all those long winded threads about different versions of hardware that I am really not a hardware guy or a software guy I am more interested in algorithms which are independent of the computer language being used. My main interest being computer vision. A recent link I found of interest is:
https://www.researchgate.net/publication/261397091_2D_Occupancy-Grid_SLAM_of_Structured_Indoor_Environments_using_a_Single_Camera

@thrandell

I would probably opt for vision with swarm robots as well which really only need react with others within sight. It works for biological swarms. The distance measure being the apparent size of the other robot (smaller further away). I don't think the actual identity of the other robot is important.

@robotbuilder

I like your idea.  But I hope you get a running example up and running so I can follow in your footsteps.  Especially as a lot of the vision stuff is programmed in python, maybe you do some good example python programs 😎.   I see your house may soon be buzzing with old carpet sweeper bots with camera's poking out at all angles. 

@byron 

🙂

No I am not going to build a robot vacuum cleaner that has been done.

The robot vacuum cleaners were simply a source of cheap parts to build a robot base to experiment with.

Had I got a robot base to map and navigate the house I might have given it the ability to use a commercial hand held vacuum cleaner.  In other words a generic robot base which can have attachments for various tasks.

Some robot vacuums use simple vision which shows that vision plus say IR obstacle sensors is sufficient to map and navigate a house.

To enlarge an image, right click image and choose Open link in new window.

@byron wrote:

" ...a lot of the vision stuff is programmed in python, maybe you do some good example python programs 😎."

Python relies on fast libraries for vision and other things all written in C++.

You cannot write low level processing using the standard set of Python commands.

Posted by: @robotbuilder

↑

@byron wrote:

" ...a lot of the vision stuff is programmed in python, maybe you do some good example python programs 😎."

Python relies on fast libraries for vision and other things all written in C++.

You cannot write low level processing using the standard set of Python commands.

Well python itself is written in C.  I expect Basic is too.  Just use python to call those libraries, as written in C++, now be a good boy and stop playing with low level processing or you will never get your bot on the road 😎 

@byron wrote:

"... now be a good boy and stop playing with low level processing or you will never get your bot on the road 😎 "

But that has been the fun part for me long before Python or OpenCV existed!!  I like to know how things work not just use them without understanding and better still figure out solutions for myself.

I am not sure that what is needed is even in any library otherwise a complete solution to a home made robot using Python and OpenCV to navigate and map a house would be online?

Yes you can use a library if it has what you want and you replace thinking for yourself with ready made solutions that only require a learning curve to use them.  The problem begins if what you want is not in the library.

This appears to be a beginner source for OpenCV and Python for robotics.

https://www.youtube.com/@murtazasworkshop

If the functions you need are in OpenCV then that works fine else you still have to write your own functions. In one example there is a library called cvzone that has a method called HandDetector but if that method did not exist what then???

 There are other links for anyone really interested in using Python and OpenCV to enable vision in their robot.

https://bigfacerobotics.wordpress.com/

@robotbuilder

Having fun it what its all about, I was just pulling your leg a bit. 😀   All fascinating stuff and I will follow your bot vision experiments in python, C, C++,  Basic, Processing,  or perhaps the new kid on the block Rust.   But don't get too rusty and get those bots on the move 😎 

@byron 

My robot base moves ok and responds to visual stimuli I just haven't got it to navigate and map the house yet.

Past behavior is the best predictor of future behavior so it probably will not happen.  I just haven't been able to muster the energy to act on what I need to do next. Not sure at this time of life there is any point to it anymore.

It was fun learning how to program and connect things to the Arduino but I may never put that to any practical use.

@robotbuilder, @thrandell, @bryon, @zander, @davee

First, I wanted to say thank you.

Like you all have said in this thread, interest working on our projects flows and ebbs.  But reading of your successes and failures does stir the creative juices to work on my own projects.  There are many things I want to touch on that I've read here.  Some are subjective and I'll want to throw in my two cents, but I want to start with one that is just data and fairly objective.

Posted by: @thrandell

↑

It sounds doable but flash has a life expectancy of ~20K write cycles, so I’ll need to be careful.

Posted by: @zander

↑

@thrandell The flash memory in my Mac is expected to last 50 years at least.

Posted by: @byron

↑

Tom, here is a link to a github on the pico flash storage, that in turn gives a link to the data sheet of the flash storage chip that is used.  It quotes the cycle writes as a min of 100,000 cycles with a 20year retention period.

Probably more than you'll ever want think about this subject...

I too was concerned about flash memory life expectancy.  I pretty much use the same ESP8266 WeMos for my programming needs.  I mean the one board... not the type of board.  So this one board gets abused by all my projects through the early stages until they go into the specific project.  Then I break out a new board to actually get inserted.  This one board is probably 5-7 years old and I can't begin to imagine how many wipes, uploads, file transfers, data acquisition cycles it's seen.  I dare say in the tens if not hundreds of thousands of cycles.  It has never even burped.

But on the other end, I have an old Android tablet that gets slower and slower every month and locks up doing simple news article reading and don't think it is long for this world.  (more on that in a minute)  I've also incorporated SSD drives in all my computers, so I really wanted to know the life expectancy of flash memory.

I'm not about to abuse something expensive, but I got (50) ESP8266, ESP-01 boards for about $30.  If you are not familiar with these type of processors, they store the program in flash memory, bring it into RAM at runtime.  This doesn't see any use except during uploads.  But, they have enough flash to allocate as a hard disk of sorts.  And that area can get thrashed at-will.  They're expendable! 😋 

I created a Sketch to wipe the entire disk area, write some data to it and then go back and read and validate every bit of it.  I wasn't sure what kind of behavior would be seen at failure... Would I see software error codes return from the SDK functions?  They all had return codes with explanations.  Or would I start seeing errors in the data?  I had no preconceived idea so checked for several things.

I also instrumented this by getting the time for each of these phases.  Wipe, Write, Read.

Here is the thread on another forum where I did this test and reported on the findings.  It looks like the ESP8266 is nearing end of life, and this forum is defunct, and I'm really sorry to say, my nice pretty graphs showing the results are no longer available, but the source code and text results are still there.  I'm also sad to say... I didn't keep copies of my graphs.  The thread is three pages long as I destroyed multiple ESP8266 boards in the search of answers.  This link has the source code and posts after that have results.

https://www.esp8266.com/viewtopic.php?p=92497#p92497

Here are the conclusions in a nutshell. 

1. I can't speak to quality of memory, but I'd imagine these devices use the cheapest available.  IOW, I wouldn't necessarily want to imply an SSD drive or a Mac has this kind of life expectancy.
2. Good - I did three boards till failure.  Each board has many disk sectors, so I exercising the entire area.  Boards lasted 6844722, 445551, 436746 cycles.
3. Good - There were never any data errors along the way.
4. Bad - The functions never returned ANY errors.  If it returned, it was always good.
5. Bad - When it failed, it totally destroyed the board.  One of the functions would simply block and never return.  The Watch Dog timer would reset the board and it would never start up again.  Also, even though the program flash was cycled only once or twice, the board would never accept any attempt to upload a new program.  The CPU portion and the program flash area was not accessible.

Unexpected - I have never seen any mention this on the Internet.  However, there was the stir some years ago about Apple intentionally slowing down people's old iPhones to supposedly encourage them to buy new ones.  Google/Samsung/etc were also accused.  I don't think they did.  I think it is the flash wearing out!  My Android tablet also is slowing this behavior. 

In all my tests, the memory got slower and slower until they just died.  In all these tests, they started out able to cycle through all the memory at about 20Hz (wipe, write, read, validate).  At the end, just before failure the rate was below 4Hz.  The read speed did not change appreciably, but the wipe and write speeds got steadily slower.  It's a shame all my graphs are no longer available.  The results were almost linear.  

My goal for starting this test was to write my own EEPROM and File System libraries.  At the time, none of the libararies:  Arduino EEPROM, SPIFFS and LittleFS incorporated wear-leveling.  They all just write over the first byte of memory over and over.  So it gets worn out first while the last byte rarely gets used.  I wanted to be an equal opportunity employer, I abused it all equally!  😆 

Because it was predictable, I also incorporated a wear gauge to predict upcoming failure.  I finally abandoned reporting this last aspect in my InqPortal Admin since the numbers were so high (400,000+) and I didn't know if different flash chip brands or even batches would behave the same.  

VBR,

Inq

Now for my two cents...  These are just my opinions how I will approach the problem, but I really think any of the methods described above are totally workable.

1. I do think that multiple processors are the way to go.  I think real-time, single purpose MPU's controlling motors with a simple API, like:  setting speed, distance, and accelerations and it not getting interrupted by having to make decisions and/or reading sensors makes for a smoother driving robot.  Even an Intel, Windows computer trying to do these things will see pauses as the OS shifts to another process.  On my Windows machine right now, I see 194 processes and 2200 threads.  And all but one, I have no idea what they're doing.  With a simple MPU... you know exactly what it is doing at every micro-second.
2. Reuse - Besides, the motive power sub-system on my Inqling Jr bot is well debugged.  It's simple... one ESP82366, two motor drivers, two motors, one sensor.  All self contained and can be duplicated in Inqling 3rd.
3. I don't think any of these MPU's (ESP8266, ESP32-S3, or Pico) are up to doing the higher brain level things like you all have been talking:  AI, Neural Net.  That will need a  significant multitasking environment.  But once it's made the decision, it passes that off to the MPU drive unit.
4. In my case, I want the robot to be as light as possible.  As we all know as every weight increase of the chassis and baggage causes a need to put bigger/stronger motors that require bigger drivers that require more battery power that adds weight and the vicious cycle starts over.  Besides, I won't allocate thousands or even multi-hundreds of dollars to this project.  By minimizing weight, I can keep it way under a $100.  I'm cheap.
5. In the prototyping phases, I'll not have the brain on the robot.  It'll interact via WiFi.  I think it will easily take a significant Windows machine like @robotbuilder uses.  The brain can get its sensor data from MPU's on the bot and set other MPU's to tell it to move and pick up things.  After functionality is established and horse-power determined... if possible, the brain could potentially go back into the bot onto say... a RaspPi 4.  
6. I know this flies in the face of common thought.  I prefer steppers for primary motive force.  But, because of (4) I can use that option.  I can't imagine trying to push around a 100 pound robot with steppers.  Its bad enough having to handle obstacle avoidance issues without also having to deal with coding feedback just to make sure the highly non-linear (regular motors) are doing what is asked of them.  

I really like the idea of my bot tooling around my yard like @byron.  I hadn't thought about using GPS.  I've always been thinking of an indoor only bot.  I received some units recently and I'll have to ponder this concept!  My property is very hilly, and lots of trees.  I got to ponder how get across the stream.  Nah... I'll make that a hard boundary.  🤣 

VBR,

Inq