encoder based navigation

Hi @robotbuilder,

  The 'standard' stepper motors are 200 'whole' steps per revolution, which is of the same order of resolution as the 300 counts per revolution as the encoder, and using the 'better' controllers, each step can be divided into fractions of steps, often called microsteps. The division ratios available depend upon the controller, but 16 microsteps is readily available, and I think I have seen up to 256 microsteps per step, though as that makes a microstep equate to less than one-hundreth of a degree, I have my doubts about the mechanics of the motor being anything like that precise.

In addition, the precision of a step might be inaccurate to say 3-5% of a step, which with 200 steps per resolution, is 1/4000 of a revolution, or about 1/10 of a degree at 5% error of a step. But note, this is generally not a cumulative error, just the positioning to a given angle.

This appears to be about an order of magnitude more precise than the 300 counts per revolution encoder.

---

With stepper motors, if they are mechanically overloaded, then it is possible for them to lose whole steps.

I think the adverse motion will consist of one or more groups of 4 whole steps at a time, which result in a noisy and obvous snatch, if the extruder motor on my 3D printer, when it is 'maltreated', is a guide.

In general, this could be due to the load being too stiff, or by trying to step it too fast. However, providing the motor is driven in a conservative manner, this should not happen.

Some stepper motors in 'professional' applications are provided with additional encoders, and I think some controllers can detect the unusual current demand patterns, as part of fault detection strategies, but these measures are not normally provided in 'cost sensitive' applications.

-------

I think is reasonable to suggest that a reasonably implemented and conservatively driven stepper motor system would achieve at least as precise control of the angular rotation of the motor shaft as a different motor with a 300 count per revolution motor.

----------------

The stepper motor solution is able to maintain full torque at very low speeds, whilst a brushed motor will tend to stall if the speed is reduced to a very slow speed. The encoder may be able to inform the controller of the actual rotation to a high accuracy, but it may tend to stall and overshoot, making precise control difficult.

-----------------

I suspect the limiting factor in models, like but by no means limited to @Inq's family of bots, is between the wheels and the ground.

Note that in the video, the 'ground' surface is almost mirror like in flatness, and the tyres were smooth.

This is unlikely to be replicated in say an average school gym, that Inq is using, and he admits his homeprinted tyres are not idea for hard surfaces. Also, he has had problems with his printed wheels not being precisely perpendicular to the axles, etc.

----------------

In short, the robot in the video has been well made, and credit to the builder, but I don't think there is anything exceptional in the motor/encoder that even a basic stepper motor drive of the type Inq uses, (as do the cheap 3D printers like Creality,) could not reproduce, given the time and effort on anciliary issues like precision made wheels and tyres, a mirror flat floor, and care taken with the controlling software, etc.

---------------------

Maybe a better question is to consider whether absolute positioning is practical for a bot, unless it is required to operate in a perfectly flat floor, etc, situation, which is far from the typical world most people live in. Obviously it helps if the bot is fairly predictable in its motions, but some feedback as to its actual position is surely required to correct for inevitable errors.

---------------------

Just my view .. others, especially @Inq will no doubt have theirs.

Best wishes and thanks for sharing the video which is am informative demonstration of what is possible,  Dave

@davee 

Maybe a better question is to consider whether absolute positioning is practical for a bot, unless it is required to operate in a perfectly flat floor, etc, situation, which is far from the typical world most people live in.

Thanks for the feedback. I have played with this little stepper motor where the gearing no doubt gives finer movements (lots of steps for a small movement on the output shaft). I had thought of using them to drive wheels on a very small robot. Like lots of of my thoughts they usually don't translate to action.

This one uses stepper motors.

A flat floor and narrow grippy wheels helps. I remember a robot that used encoders to navigate and it would reset its position by pressing against flat walls. It had wheels that looked like a gear cog. However you are correct dead reckoning quickly loses positional information.

Encoders are useful to monitor the motor and compute its rate of rotation even if not used to navigate except maybe to get a rough idea of positions or distance moved. My problem was the occasional glitch in the values being returned which made them useless.

https://forum.dronebotworkshop.com/user-robot-projects/getting-the-motor-encoders-to-work/

I have recently acquired another set of vacuum robot geared wheels with encoders that use the hall sensor which when I get time I will try out to see if I get better results. I managed to work out the connections and test it with an Arduino Uno and hopefully will get the time and interest to continue. It also has a direction pin. 

A useful robot needs to know where it is and how to navigate to somewhere else. The beer fetching vacuum robot video I posted is an example of how these machines can go to any location the user enters into their mobile phone app.

Strictly as far as Dead-Reckoning is concerned I agree with @davee.  Logic dictates that within the resolution of the encoder or stepper motor steps they are comparable.  Any error, especially in DR is associated with variation of wheels and the surface.  Either encoder or stepper would have the same problems with the same wheels/surfaces.  The advantage of the stepper motor micro-stepping is simply more/rev.  The InqEgg position accuracy is 0.034 mm.

As @davee mention, surface is a problem, but even variation in 3D printed wheels can be compensated for in calibration.  Although no one wants to re-live these calibration videos, they start here:  https://forum.dronebotworkshop.com/postid/33699/

The summary... the wheel diameter of my 3D printed wheels were compensated for by:

• Left wheel diameter = 98.345 mm
• Right wheel diameter = 98.200 mm

Although my final test for dead reckoning accuracy was not 4 - 90° turns, it did go further and had 2 - 180° turns.  You should also recognize the 50 year old planked floor is a nice acid-test.  Basically DR can't be done here.  Some more active, sensor based positioning will be required.

Those steppers w/ gearing are accurate and I've also consider them for a pen plotter bot for my grand-children, but they're slow as mud.  Top speed is only about 25 rpm.  My Inqling Sr used them.

All that being said, I have found an Achilles heel of stepper motors compared to encoders.  Using the AI, it is reported in the ACAA paper that the Genetic Algorithm can learn even the irregularities of DC motors including the difference in each motor and the starting PWM  voltage needed to get any movement.  They were able to eliminate any calibration, hard-coding or even PID coding. 

The advantage these DC motors have over steppers (in an AI design) the requested speed setting can go from negative extreme to positive extreme or go from zero to full speed in one time step.  Steppers simply can't handle that.  Whereas steppers will just lose steps and simply stop completely and chatter at you, DC motors, simply grunt their way up to the desired speed and the AI will handle the acceleration required transparently.

I started looking for encoder stepper motors.  What I found (or actually didn't find) were ones that could do what I want.  Maybe you all have some better ones.  

I could not find any that could handle say... pushing a 1Kg bot and could also run from 0 to 1000 rpm.  And could do this for say under $15US each including the driver.  No encoder motors I ran across could handle this while the steppers on the InqEgg do it fine.  

@inq 

I did indicate that dead reckoning wasn't practical as a stand alone navigation system because it will quickly lose positional information even under ideal conditions. I then added how they can be useful as a feedback system to monitor the state of a motor. This could also be useful as input to a trained neural network.

The key part of your post I would say was,
"Using the AI, it is reported in the ACAA paper that the Genetic Algorithm can learn even the irregularities of DC motors including the difference in each motor and the starting PWM voltage needed to get any movement. They were able to eliminate any calibration, hard-coding or even PID coding."

Evolving solutions is an interesting part of research. My reservation is we will end up with evolved systems we don't understand just as we don't understand in detail how evolved biological neural control systems work. When they fail we don't know why and can't predict when that might happen next. This might result in the need for robopsychologists as predicted by Isaac Asimov!  When a robot with an evolved brain starts doing weird stuff we have a problem just as we have a problem with people and all the weird stuff they do.

Evolved or not I like to understand how things work. This is why I noted how your sim bot turned a corner and thought about why that might be happening. Mine did the same thing. I doubt you can evolve that out with the current neural network.

Hi @inq and @robotbuilder,

   An interesting conversation so far I think.

Expecting/Using the AI to compensate for mechanical and electrical limitations has an obvious economy in (maybe) not needing to add extra hardware or software, but maybe should only be used as a way of 'stretching' the performance a little, and not expecting it to turn an ugly duckling into a swan, or even a pretty duck.

I am not entirely convinced about the speed limit arguments of stepper motors ... that is not to say limits they don't exist ... more that they are being asked to do different things.

Plus the present stepper motor controller/drivers tend to need a lot of persuading to produce fast, well controlled current waveforms. I can see the obvious economy in trying to get the AI to do the persuading, but I suggest it is one of the cases, where maths, physics and sensors for a 'hard-traditionally-coded' solution may still be appropriate, assuming factors like mechanical loading are relatively predictable or measurable.

All of the brushed motors I have come across have refused to play nicely at lowish speeds, so I assume to use them in an application requiring accurate positioning, they will have a considerable gearing factor built into their transmission chain, whilst stepper motors are functioning with quite a large wheel, directly attached to the motor spindle. The stepper motor performance is only possible, because the motor probably has 50 poles, giving 200 steps per revolution, if the controller/driver can only put 'full' current or 'zero' current through the coils at any one moment, and a great many more 'microsteps' per revolution, if the controller/driver can control the two current flows in a more 'pseudo-analogue' fashion. In a 'fairer' world for electric motors, there might be more of a continuum between the two motor types,  possibly with less poles in the stepper motor, extra gearing and 'smarter' controller/drivers .

I note that BLDCs (brushless DC motors) appear to some live inbetween the two other worlds. Their electrical drive waveforms have much in common with microstepped stepper motors, albeit there are three (instead of two, or four) coils to drive. As for speed, they are used to directly spin the propellors on airborne drones, so I assume this would not be a limitation for other applications.

I can certainly believe that stepper motors with built-in encoders, costing less than $15, are rarer than hen's teeth. However, if you can manage the mechanical issues, such as connecting to the motor shaft, magnetic encoders with quite small angle resolutions are certainly advertised, at pretty low prices, and I assume at least some of them work. Whilst, high precision would be 'nice', perhaps the main thing with stepper motors, is spotting when they jump one or more whole steps. If a step is 1.8 degrees, or 1/200 th of a revolution, then this is a guide to required resolution, which 'sounds' like it might be achieveable at low cost. Of course, in practice, it might still be very difficult. Motors with a short shaft at the 'back' end as well as the main shaft, would be a good start.

I think it might also be possible to monitor the motor current waveforms, and detect unexpected behaviour, removing the need for extra sensors, but this could be a challenging exercise.

------------

Please don't think I am totally disregarding other motor types and approaches, just pondering how far this type can be pushed.

Best wishes, Dave 

Posted by: @davee

↑

I am not entirely convinced about the speed limit arguments of stepper motors ... that is not to say limits they don't exist ... more that they are being asked to do different things.

Well they definitely have speed limits.  In the post I just added to InqEgg, the steppers will pretty much rocket from zero to 135 rpm without worrying about throttling.  Asked to do 0 to 165 rpm and no dice.  Between 135 rpm and 410 rpm (1500 mm/s), I could still manually throttle it up and keep it stable, but if I pushed too hard, it to would spin-out.  Above 410 rpm, I could not consistently accelerate slow enough to keep it speeding up.  As you say, I would imagine most of this is a limitation of the drivers.  However, I have a paper on my high-end TMC2209's that got them up to 3000 rpm (which would equate to InqEgg doing 25 mph!) but he said the back EMF finally burned out the driver.  So even they have limitations  (well above anything I'd ever want 😎)  But understanding these limitations get into your background.  

Posted by: @davee

↑

All of the brushed motors I have come across have refused to play nicely at lowish speeds, so I assume to use them in an application requiring accurate positioning, they will have a considerable gearing factor built into their transmission chain, whilst stepper motors are functioning with quite a large wheel, directly attached to the motor spindle.

You'll note in the video that there is some stuttering back and forth to get it to find the step it wants.  This is obviously the hardest aspect on a DC motor/encoder... using just enough voltage/current to move it.  Getting over the threshold might just give two or more steps.  While at the other extreme, steppers don't need to hem and haw.  They are simply told to go to the desired step. 

Posted by: @davee

↑

I note that BLDCs (brushless DC motors) appear to some live inbetween the two other worlds. Their electrical drive

Our FIRST team group uses very, high-end motors/drivers for their bots.  They start out at about $350US and go up from their (for the motor alone).  But they are powerful and precise.  Four of them will drive a 120 lb bot to speeds that would seriously injure someone.

Posted by: @davee

↑

I can certainly believe that stepper motors with built-in encoders, costing less than $15, are rarer than hen's teeth.

They are starting to get some on high-end 3D printers, but since I've only once missed steps on a print, I've never really looked into it.

Posted by: @davee

↑

Please don't think I am totally disregarding other motor types and approaches, just pondering how far this type can be pushed.

I'm not sure which ones your talking about, but I couldn't find any motors/encoder/driver that could do what a $12 stepper/driver can do speed or accuracy wise.  As long as I can keep it from missing steps, it's all gravy.  

Hi @inq,

  From your latest reply, it looks like we are pretty much 'on the same page' ... albeit our footnotes may differ.

  With regard to maximum speed of stepper motors I was intimating that steppers will have slower limits, because of the number of poles, and hence steps in a revolution. They are aiming at positional accuracy, and furthermore they actively hold that position if you keep the current on. As you say, a brushed motor with feedback control from an encoder will tend to 'hunt' around the desired position, and even then, considerable gearing is probably required. In some applications this may be acceptable, but clearly not all.

Achieving a high speed with a stepper, whilst also keeping the microstepping smoothness and positional resolution is a challenging problem for the controller/driver electronics. Obviously, it is possible to ameliorate the limits by dynamically changing the microstepping fraction, but that may have some undesirable effects, such as increased noise, vibrations, etc.. I predict that 'higher-end' controllers will get more flexible in this respect, and this will probably roll down into the cheaper end in time.

Brushed motors can clearly be simpler to make and drive, plus being better suited to applications requiring speed and torque whilst rotating at at least a reasonable speed. Stepper motors provide a better approach at slower rotational speeds, including offering full torque down to stationary positions.

Whether adding a means of detecting a stepper motor has missed a step is worthwhile obviously depends on the usage and consequences. I was merely suggesting that it might be possible to 'retrofit' an encoder for fairly small costs, IF there was a need. However, I am sure there will be a considerable number of challenges. Anyone developing a stepper based 'gizmo', beit a 3D printer, bot or whatever, that pushes towards the stepper motor speed limits could find such a feedback system useful.

I mentioned BLDCs .. I have never worked with them, but maybe for some applications which are struggling with speed limits of steppers, but also look for fairly high positional accuracy, or the ability to maintain a static position, they could find a niche. Just a thought, though I suspect steppers are quick enough for all present requirements presently under consideration on this forum.

My closing comments about different motor types were just a concern that I had not 'fairly' discussed alternatives to stepper motors, including the system shown in video, and I did not want to give the impression that I was disparaging such approaches, but in that message, rather mainly trying to explain some of the more useful stepper motor characteristics.

Obviously, I agree with Inq, that for his application, they look to be the best deal.

Best wishes and I hope the discussion is useful and interesting to all. Dave

@davee 

I'm sure the three of us understand the following.  I suspect most of the Usual Suspects also probably know this.  I only include this for those that might stumble across this thread because they are considering a robot project's primary motive force and are unfamiliar with each's benefits and limitations. 

The most common choice has usually been brushed DC motors with encoders.  I believe this to be primarily a historical, "we've always done it this way".  I do recall that before the advent of the 3D Printer, stepper motors were horrendously expensive and driving them doubly so.  At the other extreme, toy, DC motors were and are dirt cheap.  That has all changed with the economies of scale 3D printers has provided.  

I prefer using steppers.  It is merely my preference.  With enough diligence, either method is totally possible.  Each has its pros and cons.  They're different and depending which con you consider easier to tackle is probably going to be drive you toward using one method or the other.

Coding Complexity - With DC motors with encoders (DC/E) the software required is up to you to write (I suppose by now there are libraries).  You must write it to detect via the encoder where the motor is, how fast it is going.  Your code has to continually monitor this.  It is dependent on load.  Going up-hill requires different settings (typically PWM) to maintain the same speed.  There are extreme non-linearities.  IOW, just getting a DC/E to start moving requires far more voltage/current than to keep it running.  As they warm up, they'll need different settings to maintain the same speed.  There is variability.  What seems like two of the same motor, might have very different settings to maintain the same speed.  All this must be handled by detection of the encoder and adjusting settings.  The MPU must do all this in real-time.  The video described in the OP is a very non-trivial bot and quite the accomplishment for anyone to undertake.

On the other hand, steppers, you simply tell them to go so many steps or go a certain speed.  They do not have to be monitored and depending on the hardware drivers, some don't even have to take up the MPU's time.  There is no non-linearity.  Speed or distance won't change as they heat up or just starting out.  Two motors will behave the same.  For that matter, two of different sizes, from different companies can be paired together with complete assurance they work in lock-step with each other.  The video described in the OP is almost a trivial bot.  It merely becomes a geometry problem and counting how many steps to move.  

Precision - This usually means how many steps are in one revolution.  I don't use DC/E, so I'll assume the 300 steps/rev @davee mentioned is a common standard.  For most common steppers this number is 200 steps/rev.  This is a mechanical design stipulation.  It is fixed in iron.  However, even the cheapest electronic stepper drivers have the ability to set intermediate steps called micro-stepping.  Different models have different capabilities, but 51,200 steps/rev is readily available.  As @davee mentioned, these techniques for having intermediate steps have some variability (say +/- 5%).  But in a DC/E there is no ability to know where you are between two steps.  For most robots we'll be messing with, either is plenty precise.  However... maybe you are designing a surgical robot.  

The hardest aspect for DC/E is to move one (and only one) step.  Due to all the issues in Code Complexity, this is a significant challenge.  Overshoot is common.  Just note in the video where it has to hunt around for its location.  It was not detecting where it was and needing to adjust it was just trying to get to step 346,261 and not be at '260 or '262.  For a stepper... you simply tell it to go to 346,261 and it will.  

Speed - On the surface, this seems to be a stepper's weakest quality.  It seems anyone touting DC/E as the way to go, always throw speed out.  DC motors effortlessly spin tens or even hundreds of thousands rpms.  Getting a stepper above even one thousand rpms is a challenge.  However, to get any usable torque out of a DC motor, you have to add gears.  I'm sure there are exceptions, but for any hobbyist level expenditures, I've yet to see a bot that can get out of its own way.  Any that profess to do any kind of obstacle avoidance, line following, wall following typically run at speeds no greater than a robo-vac.  Some of these speed issues may be compute time intensity of the desired goal, but I also see that commodity priced DC/E using gears are typically slower than a commodity stepper.  Many seem to be in sub-100 to around 300 rpm.  If those speeds are fine for your situation, then DC/E is a viable option.  Personally, I want my bots to be able to sustain at least a human walking pace while doing some of these simpler tasks and still have the precisions described above.  In my experience, the smallest Nema-17 on a 140mm diameter bot can easily run 4 mph.  Larger Nema-17's, on larger bots can easily do double digit speeds.

Price - I thought this was supposed to be strong-point of DC/E.  At the bottom end, $10 will get you one stepper and its required stepper driver.  It will do the precision and the speeds mentioned above on a usable robot.  I have yet to find any DC/E that can come close to the same abilities at any price.  Although I have to admit, when it starts passing through $30, I give up.  I simply stay committed using steppers and get far superior speed and precision.  

Con to Stepper - The only con I've run into with steppers is when they are asked to exceed their capabilities.  I must admit a DC/E has the capability of telling you by its encoder that it is not spinning or it is not spinning as fast as you expect.  A stepper... stalls and chatters like a pissed-off squirrel.  And without additional encoders, it can't tell your code something is amiss.  In the general case, this is handled by just oversizing the stepper or limiting it to forces it can easily handle.  Millions of 3D printers work flawlessly without losing steps using these techniques.  But, in my current project this has become an issue and feel it is worth noting in the negative column.

@davee

@inq wrote:
"Using the AI, it is reported in the ACAA paper that the Genetic Algorithm can learn even the irregularities of DC motors including the difference in each motor and the starting PWM voltage needed to get any movement. They were able to eliminate any calibration, hard-coding or even PID coding."

A hard coded program is also capable of automatic calibration. One of my first experiments was to get the robot to go in a straight line so I did the obvious and sent the same PWM values to both motors. The robot pulled slightly to the left for a number of possible reasons. So I manually kept fine turning the PWM values to get it closer to moving in a straight line. Then I thought no, the information is in the feedback of the encoders and they can control the PWM signal to keep the motors turning at the same desired (goal) speed. They can also monitor any drift in position and actively correct for it by bringing the robot back on the desired path.

An example might be designing a transistor amplifier. Transistors are not all identical but you can design their support components to bring about identical behaviors using feedback. One example is a resistor in the emitter circuit with a bypass capacitor for the ac signal. Or connecting the base resistor to the collector rather than the main power bus. Feedback in a circuit can also be used to compensate for temperature changes effecting the circuits operation.

A vacuum robot's battery pack includes a temperature sensor to prevent it overheating and starting a fire.

As I think I mentioned earlier the biological world is stabilized by a network of feedback loops all the way down to the internal workings of each cell.

The payoff for using stepper motors that work blind without feedback is in their simplicity in certain applications but as a general rule I think goal directed feedback is the way to go regardless of what kind of motor you use and is the method by which they can recalibrate their parts without needing to evolve a new set of weights.

Hi @robotbuilder,

 In some cases. I agree that 'simple' feedback is the right approach .. e.g. anything with wheels that can slip and wander due to imperfect grip with the 'ground' needs a feedback system to 'tweak' the 'steering' mechanism to keep it on course. Whilst it is good practice to minimise unnecessary 'wandering', trying to achieve a 'perfect' system without feedback in these circumstances is usually planning for disappointment and failure.

As a contrast, the 'positional quantisation' provided by stepper motors are much better than (say) a brushed motor at certain tasks, e.g. moving to a position and holding it. And whilst they are operating within their limits, they can be very accurate, but when mechanically overloaded, may introduce severe unwanted jerking movements that can be catastrophic if (say) they are performing a precision CNC task. In this case, a somewhat different approach is required, which also requires sensing the situation, but may require action to be taken before the error occurs. This involves a degree of prediction, which has some similarities with 'simple' feedback, but also differences.

In a third case, sensing may be used to look for faults, and whilst it could be argued that if a system's response when a failure is detected, consists of stopping the process and calling for maintenace personnel to intervene, is also a form of feedback, that too has a different feeling. In some cases, AI may be helpful in spotting a breakdown in the early stages, when the consequences of the impending failure may be much less traumatic. This is a holy grail that has been proposed in the past, but with certaiin 'easy' exceptions, such as when a cutting tool gets progressively blunter, I think most ''predictive maintenance' regimes have resorted to simple statistics of finding the best compromise between the cost of replacing something early, and the cost of replacing the same item too late, when the costs include subsequent losses due to breakage, etc.

In some cases, using AI for a form of auto-calibration definitely has merits, but I am less convinced that it should be automatically regarded as a medicine for all ills. However, that does not mean it shoulld not be attempted in a wide range of scenarios, provided the experimental results of such trials are objectively evaluated and decisions as to whether the trials were a success or failure made on good qualitative grounds.

An interesting topic and discussion, thank you for introducing it.

Best wishes, Dave

@davee 

The research projects of @inq and @thrandell have been a bit of a distraction for me for my real interest is in building robots that actually do something useful right now! The basic requirements of obstacle avoidance and navigation has been solved,  it is just a matter of implementing it, not trying to evolve it.

Once you can get your robot to move from its current position to some desired position then things like fetching a beer becomes half done. With outdoor robots the best solution seems to be GPS and there are example on the internet on how to do this. It is the method used on self controlled tractors to move along a desired path while performing various tasks.

The humble and well engineered vacuum robots use lidar or a camera. There are other sensors required but I think they are the two most effective methods for the robot to know where it is.

Although encoders may not be a navigational solution they are very useful for other reasons so I hope I will get more reliable performance with my latest encoder based motorized wheels. Vacuum robot geared motors are not fast (no reason to be). Slow and steady wins the race 🙂  Solutions can always be transferred to a larger faster robot base later.

As an aside comment I have never been interested in driving fast as it requires too much concentration which I need to sense the current situation and take action using predictive control before an error occurs. 

Posted by: @robotbuilder

↑

The research projects of @inq and @thrandell have been a bit of a distraction for me for my real interest is in building robots that actually do something useful right now! The basic requirements of obstacle avoidance and navigation has been solved,  it is just a matter of implementing it, not trying to evolve it.

Classic @robotbuilder response.  Largely your posts (at least in my threads) are negative, trying to find fault, stating what it doesn't do, or when all else fails..."doesn't actually do something useful."  Considering, I've never seen you actually do anything, much less, something useful, I can't understand where you get off, presenting yourself as some kind of expert qualified to pass judgement on my attempts at learning about robotics and/or AI.  

You have on numerous occasions professed that you only want to do hard-coded solutions and AI is only for those not competent enough to do it the "right way" (as defined by @robotbuilder).  The world has already passed you by.  AI is here, and has proved it self invaluable for good or bad.  It is quite clear to me that you don't understand scientific method or good engineering practice of starting from simple constructs, comparing to known results of others and progressing toward a goal.  My goal has never been to make something useful.  My goal, is to learn.  I believe this forum is for hobbyist wanting to learn.  It is not a scientific forum for PhD's presenting work or for companies preparing or presenting a product.

The fact you can't spend two minutes to get a free, anonymous Gmail account, upload a video and present it here only tells me you don't have anything to show.  A static picture of a cart on wheels doesn't prove anything.  Unless the useful aspect was it holds up a laptop.

Posted by: @robotbuilder

↑

The research projects of @inq and @thrandell have been a bit of a distraction for me

I for one volunteer and would prefer you not waste any time reading or writing posts in any of my threads.  This alone should free up much of your time to do something useful.

Hi @robotbuilder,

   Robots that actually do something useful clearly should be a general aim, and I applaud your efforts.

I think @Inq has a fairly solid case for choosing stepper motors in his application, but that is just a typical engineering 'best choice for this case and circumstances' decision ... as soon as any of the circumstances change, so might the 'best choice'. This also implies, that is often useful to maintain availability of more than one choice, to avoid the 'best choice' becoming the only choice. Certainly sensors, including encoders, are likely to be required in many applications, for the foreseeable future, and probably beyond.

I think some of the discussions, studies, etc. that Inq and others have contributed to, are also attempts to look to the future. Inq may be some distance from having a bot that brings him a beer, and hopefully never needs a bot to do it, because he can't get to the fridge, but there are a vast number of people, who do need more assistance with everyday tasks, and whilst these tasks are trivial for the majority of people, they can be complex for a bot, because it means encompassing a large number of 'abilities', both computational, and mechanical. So 'small' steps, including looking to see if AI can play a part, I find both interesting and challenging.

In balance, I think other developments, which are further from my own background, but are equally important in the 'bigger picture', include the mechanical arrangements. e.g. 'arms and hands' capability that can retrieve a delicate object from the back of fridge that has been loaded with many disimilar objects in a pseudo-random fashion. I should point out, I live in a country where the largest domestic fridges are often labelled 'American', on account of their size, with the majority being considerable smaller as our homes do not have the space for this size, and the smaller fridges are inevitably more challenging when it comes to placing and retrieving objects. Hence, whilst there are exceptions, for most of the local population, having a separate fridge with a beer can dispenser, plus doing the same for other 'popular' items is not practical, because our homes are not large enough.

Am I expecting anyone on this forum to solve all the challenges? No. But maybe making some small contributions is feasible, and certainly interesting to try.

I also agree speed is not always required or even desirable as a sole aim. Sometimes, when developing something, it is helpful to have an aim like speed, not necessarily because it is essential, but it can provide a focus to optimise. I should say that such aims typically require constraints, to provide a useful result. The vehicle that achieves the fastest speed along an almost infinitely long straight road, might qualify for a place in the record books, but unless it can be driven along a normal road system with junctions, hazards, and other road users, it is useless in everyday life. Most of us like to get things done in a timely fashion. A 1 mile per hour vacuum cleaner might be fine, but even it needs to do its job efficiently without being an annoying buzzing object that is always in the way.

Best wishes, Dave

@inq

I for one volunteer and would prefer you not waste any time reading or writing posts in any of my threads. This alone should free up much of your time to do something useful

A happy distraction @inq a subject that has interested me for a long time.

Sorry I offended you.

Thank you for letting me know how I made you feel, I wasn't conscious that my posts read that way.

I never thought it a waste of time to read your posts. I wasn't saying your research wasn't useful, it was about me not you or Randell. I am not an expert on genetic algorithms or neural nets and will never contribute anything useful to the subject, although I tried, I will leave it to you guys.

I cannot promise not to read your posts as I still find your posts interesting even if I can't make any useful contributions and can't seem to make observations or ask questions without offending.

I will respect your feelings and will avoid any responses to your posts in future.