Building robots

@inq The issue with Apple slowing down the iPhone to extend battery life was badly reported and the general public do not have the knowledge to understand. I suspect most of us on the forum know how little CPU power is needed to do 90% or more of the tasks a normal iPhone user does. Reading email takes a handful of cycles over a multi second time frame. You could easily reduce the CPU speed to 1/10 and not notice it. Given the choice of shorter battery life vs a slight slowing of the CPU where I wouldn't even notice it I will opt for longer battery life every time. This is a classic fake news case.

Speaking of flash life, of my hobbies is photography and we actually do suffer damaged cards IF we don't know to buy what are called High Endurance cards. The high endurance cards perform wear leveling while the ordinary cards do not. Attached is a link to Amazon.CA for one of the expensive cards I use https://amz.run/6u6s

Hi @inq et al,

  Thanks @inq for some real data .. a pleasant change.

  From me, a couple of data sheet observations from over the years.

• There are a number of different 'electrically eraseable read only memory' (EEPROM) technologies, including but not limited to 'flash' ... and I suspect there are variations on the 'flash' theme when looking at the memory cell level.
  • Each of these different varieties will have their own good, bad, and average qualities, so quantitatively you should be careful to only equate experimental evidence or specification claims to the specific device type they were measured or specified for.
  •  
• My (vague) recall of EEPROM chip datasheet values is they specify both the number of writes, and the retention time. Crudely, they suggest you can rewrite a given cell/block (say) 'm' times, and the contents of the last write will then be retained for 'n' years, possibly mentioning an error rate. It should also mention environmental conditions.
  • e.g. Consider the case of an automobile engine management unit, housed near to the engine, experiencing temperature extremes, etc., where code might be updated multiple times at the begining of its life, but then left unchanged for 20 years, where any corruption is likely to crash the processor... and in the worst case the car also, seconds later!
  •  
• It follows that concerns should consider both the inherent chip capabilities and the usage of the chip.
  • Even a modest temperature increase of say 10degC, might reduce the retention time by a factor of 10 times. (I am not claiming this as an accurate figure, but an educated guess that it will follow Arrhenius exponential laws.)
  • An occasional bit loss may be of little consequence on a long term monitoring project, but will usually crash program code
  • If the data only needs to be retained for a limited period, before it can be ignored or it will be rewritten, a value corruption is much less likely to be experienced.
• As for personal computer experience with SSDs and the like, I suspect many of the problems are due to the operating system collecting a lot of 'data' that isn't really needed, but still involves the processor sorting through it.
  • Many times I have 'freshly installed' Windows on 'old hardware', with very noticeable improvement in performance ... I doubt this is part of a conspiracy, but more the difficulty of keeping everything 'clean and tidy' ... and I doubt that the experience is limited to MS products.
  • Of course, mechanical disks suffering from file segmentation were particularly susceptible due to physical format, but maybe SSDs are not immune, especially when cacheing is taken into consideration. An SSD that is running near 100% full may also have extra problems, but that should be less common in recent times with larger SSDs readily available.
  • Whilst the basic aim of wear levelling systems is obvious, I am less clear about their side-effects. Obviously,if the device has worn to the extent that parts are failing at a high rate, this will be a problem, but is that a common issue with normal usage?

Just a few thoughts ... best wishes all, Dave

Posted by: @zander

↑

Speaking of flash life, of my hobbies is photography and we actually do suffer damaged cards IF we don't know to buy what are called High Endurance cards. The high endurance cards perform wear leveling while the ordinary cards do not. Attached is a link to Amazon.CA for one of the expensive cards I use > https://amz.run/6u6s <

So are you saying that supposedly the card itself has a CPU of sorts that knows where to locate to least used space???  I would have thought that is only in the capability of the device.  A camera in your case or in mine, say as the primary disk in a Raspberry Pi.

Posted by: @davee

↑

 

• • Each of these different varieties will have their own good, bad, and average qualities, so quantitatively you should be careful to only equate experimental evidence or specification claims to the specific device type they were measured or specified for.
  •  
• My (vague) recall of EEPROM chip datasheet values is they specify both the number of writes, and the retention time. Crudely, they suggest you can rewrite a given cell/block (say) 'm' times, and the contents of the last write will then be retained for 'n' years, possibly mentioning an error rate. It should also mention environmental conditions.

 

OH, I see where I stepped in this.  The Arduino has a real EEPROM.  The ESP8266 uses software working on the flash memory to simulate the same Arduino library.  I was only talking about that instance and only on an ESP8266.  And as I mentioned, my test is not exhaustive enough to even account for the ESP8266 board manufacturer using a different batch or even a new flash chip.  All my tests were probably from the same batch of flash chips that happen to come down the line that day.

Posted by: @davee

↑

Whilst the basic aim of wear levelling systems is obvious, I am less clear about their side-effects. Obviously,if the device has worn to the extent that parts are failing at a high rate, this will be a problem, but is that a common issue with normal usage?

I've read that of course SSD drives do have wear leveling and they do have the ability to mark areas as bad and just avoid them.  That kind of ability has been around from nearly day-one of hard disks (at least in the PC era).  It has been my observation that hard disk manufacturers are going to hide this from "common issue with normal usage."  They go so far that even disk testing programs are seeing a virtual map of continuous sectors even though the underlying hardware is riddled with bad sectors.  The map gets smaller, but I've never seen holes in it.  I'd say this is marketing so even geeks think they're getting a better hard disk.

I don't know, but I'd imagine even the Linux distrib on a RaspberryPi has the wear leveling built-in so they don't abuse any single area of the SD card used as the primary hard drive.  It would only make sense.

On these Micro's with built-in flash or using an external SD card as storage, the common libraries SPIFFs and LittleFS did not even have basic wear leveling.  The LittleFS developer did mention it was on his TODO list and he may have gotten around to it.  I don't know, I didn't continue to follow him after writing my own.

@inq wrote:

" 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."

Yet it works for me? Of course you can't rely on a multitasking PC for low level control thus the need for a low level controller or even hardware reflexes when required. The human brain isn't any different. As I touch type this post my high level brain has all sorts of things being processed but my low level motor controllers type away without me thinking about it. I have long forgotten the layout of the keyboard but my fingers just hit the right keys by themselves when given a high level sentence to type.

"I'm cheap."

Depends what you want your robot to do.

A robot that can do anything useful will not be cheap.

"I really like the idea of my bot tooling around my yard like @byron."

Again it depends what you want your robot to do. You might look at the small farm robots that can go up and down rows spraying weeds or herding cattle back to the milking shed.

@inq , I just finished reading your post on flash memory, and to maybe answer your question to @zander (Ron)

"So are you saying that supposedly the card itself has a CPU of sorts that knows where to locate to least used space??? "

So here's a link to that for you to peruse: https://www.usbmemorydirect.com/blog/whats-inside-usb-flash-drive-components/

Yes, the different types of flash memory (Nand & Nor) also have many different life cycles depending on what type they are and what processes your using them for..

Here's the architecture for and SD card:

 and the link to the article: https://www.technewstoday.com/how-do-sd-cards-work/

Regards,

LouisR

@inq I never really thought about it, but yes, I guess I did assume there was some sort of memory management chip. My understanding was that the less clever cards always wrote to the FIRST free area and the high endurance cards wrote to the NEXT free area.

@inq

A good couple of posts, worthy of another re-read, but just some quick remarks, rather off the top of my head and not checked by me to see if I'm correct as a bit pressed for time over the next week, but here goes.

1) I think LittleFS now does wear levelling, or at least someone has produced an additional library to do it.

2) Regardless of using encoders to get equalised wheel rotations or keeping the wheels turning with the same steps from stepper motors,  when used in an outside bot, your bot will probably not go in the intended straight line.  Tufts of grass, weeds on the brick paving, different sizes of stones on the gravel drive will all conspire to twist your bot in an unwanted direction.

In this respect positioning systems of some sort to know where the bot is, like GPS and an IMU sensor could be the way to go, maybe with RTK GPS for accurate positioning.  An alternative could be some cameras using OpenCV to triangulate the bots position.  Yet another is the use of timing some radio frequencies for triangulation.  

This board, which just dropped into my inbox, utilises UWB and mentions getting 10cm accuracy in positioning.   A bit pricey at £54, but a heck of a lot cheaper than RTK.   I'll be reading up about it soon.  Maybe if Bill @dronebot-workshop gets his robot mojo back this UWB stuff would make a very fine dronebot article. 😎 

https://thepihut.com/products/challenger-rp2040-uwb-dwm3000

Also, I don't think stepper motors will be suitable for outdoor bots, unless the bot is to crawl along emulating Brian the snail. 😀   I think the torque of a stepper reduces rapidly with motor speed (but I could be wrong 😀 )

@byron  Hi.. found your snippet about UWB fascinating..and I can see that may yet be the future for such things as range/location. 

as per your "Also, I don't think stepper motors will be suitable for outdoor bots, unless the bot is to crawl along emulating Brian the snail. 😀 I think the torque of a stepper reduces rapidly with motor speed (but I could be wrong 😀 )" Yes , it is the inverse of RPM.

As speed increases (RPM), torque decreases.

Enjoyed your discussion, and have now read a few articles abut UWB..

 Regards,

LouisR

@byron wrote:

"Regardless of using encoders to get equalised wheel rotations or keeping the wheels turning with the same steps from stepper motors, when used in an outside bot, your bot will probably not go in the intended straight line. Tufts of grass, weeds on the brick paving, different sizes of stones on the gravel drive will all conspire to twist your bot in an unwanted direction."

You can navigate the world without GPS or internal encoders if you are connected to the real world using vision and touch sensors. Twist and turn on grass, weeds or bricks or just be moved by a human and an advanced robot can know where it is by opening its eyes and having a look see just the way we do. Wheel encoders are still useful as internal feedback to make sure the wheels are actually turning and at what speed.

Posted by: @inst-tech

↑

@byron  Hi.. found your snippet about UWB fascinating..and I can see that may yet be the future for such things as range/location. 

as per your "Also, I don't think stepper motors will be suitable for outdoor bots, unless the bot is to crawl along emulating Brian the snail. 😀 I think the torque of a stepper reduces rapidly with motor speed (but I could be wrong 😀 )" Yes , it is the inverse of RPM.

As speed increases (RPM), torque decreases.

-- attachment is not available --

Enjoyed your discussion, and have now read a few articles abut UWB..

 Regards,

LouisR

I totally recognize that stepper motors are weaker than a same size brushed or brushless.  And, I can certainly recognize that I would need more torque climbing over bumps or even a grade.  I might have to stay indoors.  😆 

So what kind of motor are you suggesting does not have this problem?  I just looked up both brushless and brushed and found these curves. 

 Is there a typical motor for hobbyist robotics.  I know they're using brushless motors for the FIRST competition like these and I can certainly attest that they accelerate 120lb robots like they're made of air, but they're way over what I'm willing to pay.

Is there a more reasonably priced alternative?  Does is include the encoder or is there a generic encoder that is typically attached to a range of motors?

Hi @inq et al,

  I admit EEPROM is often used as a term for a (usually) smaller memory, possibly with more flexible write/erase capability than a 'flash' memory, but I was mainly using the term in a wider context to include flash (whilst not excluding any other devices), as surely flash is both EE electrically eraseable and retains it data contents through power cycles, which is usually the requirements of a PROM. It is true to say 'archetypal' EEPROMs tend to be specified in terms of write cycles and data retention time, and maybe that is less common for Perhaps there is a better generic term for all memories that achieve these properties, but I can't think what it is. Sorry if I confused anyone.

-------

And whilst the common means of specifying SSD life may be defined in terms of numbers of data writes, I would guess the effects of temperature, retention time reducing after multiple writes, and so on are likely to affect the memory at the cell level in a fairly similar way to other EEPROM-like memory types.

However, in some cases, memory cell data corruption could be masked if the device has an active 'refresh' function' that periodically reads all of the data (independently of any processor reads and writes), maybe rewriting it, and maybe correcting (say) single bit errors using Hamming codes or similar. SSDs certainly have controllers that can get up to tricks, and who knows what Windows, etc. is doing in its spare time and 200+ processes. (These processes might be similar to those used with error correcting dynamic ram, but on a refresh timescale of say weeks rather than milliseconds.)

And obviously any such refresh process assumes the memory is frequently powered up for substantial amounts of time, which is not always true.

---

Furthermore, I am guessing a small flash memory associated with (say) an ESP32 is likely to be more limited in the scope of processes available to it. A read-after-write, with bad sector table and retry somewhere else strategy, to work around bad sectors, roughly equivalent to the old simple hard disc algorithms seems perfectly feasible, especially if the ESP32 processor is doing all the grunt work. I doubt whether written data will normally get refreshed, unless the processor's operating system has special provision.

Hence, I am suggesting that the useful ability of flash memories to withstand multiple writes over the same set of memory cells may be more subtle than just repeatedly write/read/erase cycles until it completely fails. Of course that torture test will tell you something, but in many cases the user will want the data to be retained for an extended period, possibly unpowered, after it has been subjected to a number of rewrites, and the criticality of the data accuracy, the environmental conditions, etc., may all have profound effects on the capability of meeting the user's expectations.

Just a random thought or two to ponder. Hope it makes a  little sense.

Best wishes all, Dave