Building a Robot One Motor at a Time

I am looking forward to your journey!  I always wanted to do a robot... about the era of the IBM-PC coming out, so about the same as you.  The price of admission to get a PC to interact with the real world was way too prohibitive for me.  Arduino definitely has allowed us to realize these dreams.

There are tons of schools of thought on the Internet as well as this forum.  Don't take anyone's opinion as gospel.  They may simply have different goals than you.  I tend to be the maverick on forum - I tout using stepper motors for primary driving force.  I've ranted many times before about their PRO's and have listed their CON's.  For me, at least, the PRO's outweigh the CON's handily.  But... as I said, my goals in a robot hinges on many of those strengths.  I haven't made any converts.  

Anyway, I tend to be long-winded, so I'll break this up into different posts.  I'll try to be concise, so ask if you have any questions or need clarification.

Inter-Processor Communications

Monolithic CPU - Most robots (on this forum) can usually get away with one Micro-Controller.  Some that use multiples, chose to go that way, but really didn't need to.  Maybe, they have continuing plans that will need more.  Some do need to.  So far, I've been able to do most of what I want with just one, but am on the crux of adding a more powerful one (say... RasPi or equivalent) as a more AI, decision level type brain and still use MPU as motor/actuator controllers.  It sounds like you want to start out with multiples and get comfortable with the inter-processor orchestration early-on.  

Inter-processor communications - There are several contenders for this (that I can think of).  

• SPI - would probably be the hardest to implement if you plan on lots of different nodes.  You sound like you'd have a node / actuator or motor.  SPI has two communication lines for the bus but they require a third line to identify which one is being "talked" to.  That third line needing a pin on the node is no big deal.  But on the central processor unit, you'd need the two pins for doing the communications to all the nodes PLUS a pin for each of the nodes.  If you have 50 DOF in your bot, you'd need 50+ pins on the central unit.
• I2C - Also uses two comm lines for the bus, but it uses a software address (for each node) and the central processor sends the address down and only the one with that address will respond.  The down side of I2C is that the communications always has to be started by the central unit.  They can reply when prompted, but they can't just send data to the central unit any time they need to.
• Serial - This also uses two lines for communications.  You are probably already familiar with using this uploading Sketches, Serial Output Window, Serial input to the controller.  It can be very fast and it is full-duplex.  Either end can send when they need to.  BUT, it is not a bus.  You need two lines for each node coming from central unit.  
• WiFi - The advantages - It doesn't use any pins.  If you come up with a UDP type protocol, it can talk to all nodes with the same command.  It could also receive commands and send telemetry to you without any extra coding.  It's just on the airwaves.  The disadvantage - It's on the airwaves. 🤨 
• Bluetooth - Ditto to WiFi, just shorter range.

As I've not gone to a multi-processor yet, I haven't really decided myself on this.  I'm leaning toward WiFi mainly for the free telemetry during debugging the robot.  After that, I'm leaning toward the I2C at least for actuators.  They don't really need to talk back to the central computer.  They can easily piggyback a reply when they're sent something.

VBR,

Inq

@fester225 I think you will be best served by studying some 'robot' projects that Bill has done here, also studying how motors are controlled. SPI is one of several buss architectures available on various MCU's and MPU's.

In very general terms, the hobbyist level of Arduino line is generally beginner oriented, slower, less capable than the ESP32 line. However, almost any MCU or MPU can control a robot of some sort and today we have hybrid boards as well as MPU makers now producing MCUs as in the Raspberry Pi PICOW which has spawned a lot of other boards using their own RP2040 chip.

Posted by: @fester225

↑

12VDC, then overlay a high impedance 10Mhz RF signal over the top. I can ground out the RF signal with a capacitor to provide comms.

I'm not sure I understand this, I don't have a lot of hardware background.  It sounds like you want to try multiplexing over the same power lines.  Actually this sounds pretty cool as an experiment.  I'm not sure I understand a major benefit to this.  Will the fluctuations in power needed for the motor at rest versus at full load, affect the communications over the same wires???  Definitely above my hardware paygrade!  You'll need pretty hefty lines for the voltage/current to drive bigger motors, but you'll need three lines for communication for SPI or two for Serial or I2C.  These logic lines can be tiny - 28, 30 AWG...  or zero lines for WiFi or BT.  

As I mentioned, I prefer stepper motors for primary motive power.  As long as you stay within their torque limits, you don't need to do any encoder logic.  You just tell it to go a certain speed or go a certain distance and you can trust that they'll honor that exactly.  Millions of 3D printers do that every day proving that reliability down to the micro-meter level.  You don't have to write one line of code for dealing with Encoders, PID tuning or fluctuating voltage to keep the same speed... OR having to compare two motors and make sure they stay in lock-step.  Steppers will just do the speed you specify. 

For Nema-17 steppers, I'd WAG that the bot really needs to be under about twenty pounds.  If heavier than that, you can gear them as you'd have to do for regular motors with encoders.  Anyway, the biggest difference is cost.  It sounds like you want a modular system where each motor has its own MPU, driver, motor, (possibly encoder).  I would suggest...

MPU - Wemos - About $3US a piece in the US, about a $1US in quantity from China.

Stepper Driver - DRV8825 - About $3US a piece in the US. about $1US in quantity from China.

Nema-17 - Small ones are about $10 each, big ones about $15 (84 oz-in).  Cheaper in China.

Voltage Step-Down converter from your primary voltage down to the 5V needed by the WeMos above.  The higher voltage would be better.  The stepper driver can handle up 35V.  If you have a heavy bot, you'd probably want to go toward 35V.  If less than 5 lb bot, you could use 12V.  More will always be better.  They usually cost < $2US in the US.  A lot cheaper from China.

So a total price of a node could be around $10 to $20 depending on motor size and where you buy them.

This would be all that you need for the node and it could do Serial, I2C, SPI, WiFi or BT... dealer's choice.

VBR,

Inq

@fester225 Just some quick comments

This could be an 8 or 32-bit device, with two output pins (motor power), two logic level inputs (bi-directional encoder), and two ADC pins (current measuring, 8-bits would be acceptable). I'm expecting to use the microcontroller to generate a PWM signal through programming

8 bits are still available, but 32 bits dominates. Will not have much affect one way or the other. Most motor controllers will need at least 3 pins if only one motor, but it is uncommon for only one motor.

Most controller boards will have PWM built in.

Another major expense here is going to be the DC motor interface. This will take the logic level output from the microcontroller and act like an enormous amplifier to supply power to the DC motor. The motor I'm using as an example normally runs at 1 amp, with a 6-amp stall current.

Most of the popular motor drivers are covered by Bill in this Video/blog https://dronebotworkshop.com/dc-motor-drivers/ I looked up the prices on a couple and they run $3 to $5 each. If that is a major expense, the cost of some of the other parts may be a problem.

The following is partly confusing, especially where it mentions more than 1 motor and earlier you said ONLY 1 motor and partly completely indecipherable.

SPI is a choice, but not the best choice.

Many motors do use 12VDC for motive power, but there is no connection between the power pins and the control pins so the very idea of overlaying a signal is pointless.

Many motor control boards are for 2 motors. I am attaching a picture from Bills video/blog linked above showing 1 controller board for 2 motors and the dual H bridge motor controller. NOTE that there are 8 wires to the MCU plus 2 wires to the external motor supply power, possibly 12VDC.

The next part will be communicating with the microcontroller. I've been assuming I would use SPI for this, but I don't really  understand what SPI is. What I'm looking at ideally is providing the motor assembly with, say, 12VDC, then overlay a high impedance 10Mhz RF signal over the top. I can ground out the RF signal with a capacitor to provide comms. This way I can can daisy-chain comms and power to multiple motors while using only 2 wires. I haven't worked out whether or not they'll handle the power yet, but I'm thinking in terms of using BNC connectors.

I really don't understand why BNC connectors have anything to do with this.

@fester225

If I can get the costs low enough, I won't go broke building this thing. Comments? What kind of microcontroller should I be looking at?

With respect may I suggest you would probably get better and more precise feedback if you could be more specific as to the overall end result you are aiming for otherwise it becomes a guessing game as to what that end goal is and thus what detailed suggestions to make as to as to questions like what kind of microcontroller would be suitable. For example as an electronics guy you would know that motor controllers can be very simple or very complex depending on the type of motor control that is needed.

For example I assume you want a microprocessor for each motor so it can receive control data over the power lines. There are chips for that but I don't see what kind of robot design would require such added complexity?

@inq Signing up with this forum is already paying off. Now I know not to plan on using SPI!

My biggest problem with using stepper motors for vehicle movement is the variation in required torque levels during normal motion. Of course I could simply turn the current all the way up all the time, and that would pretty much guarantee correct stepper motion. On the other hand, it would also use more current than necessary. This would a big “no” for a battery operated device. Of course, if I were looking for precision, I’d put up with the extra current use. 
I look forward to more of your views!

Hi @fester225,

You have already received a lot of good advice, so I am only commenting on a few points. As @Inq wisely says, "Don't take anyone's opinion as gospel.", including mine below, but I offer them in good faith, in the hope they will be helpful.

BNC connectors: These are designed for sending/receiving high frequency signals, usually analogue, with minimal distortion, including minimising reflections in a matched impedance environment. Hence, they are often found on the front of an oscilloscope to connect the test probes. They are not designed for conducting high currents. To conduct the high-ish current levels associated with substantial low voltage motors, look for connectors with relatively large contact surface areas. Commercial connectors usually specify the maximum continuous current levels in the data sheets, but for reliability and minimal problems, allow some spare capacity.

Combining Power and Control onto the same pair of wires: In principle, this is a feasible approach, but it will considerably complicate the project. Controlled motors tend to produce a lot of electrical noise over a wide bandwidth, including RF frequencies, which is liable to interfere with the control signals. Of course, such problems may be overcome with sufficient resources, but you might find life easier to keep the power and communications separate. As already mentioned by others, there are ways of using a networks to minimise the amount of wire required for communications.

I2C - can have more than 1 controller on a bus : Apologies to @Inq if I am misinterpreting his statement "The down side of I2C is that the communications always has to be started by the central unit.", but I fear it might be confusing. It is true that a comms transmission must be instigated and managed by a controller, but there can be more than controller on the bus.

For further information, see: https://www.ti.com/lit/an/sbaa565/sbaa565.pdf?ts=1703831771114   which includes the following snip: (click image to enlarge)

Some chips, like an analogue-to-digital converter may be a peripheral that never initiates a message, whilst a microcontroller can initiate messages. However, because the bus uses open collector/drain approach, plus certain 'tricks' in the protocol, it is possible to have more than one controller sharing the bus.

Having said that, perhaps the biggest advantage is that is probably the lowest cost wired network, requiring just two or four extra resistors, which means that it is easy to have several independent I2C networks in the same system.

Of course, I2C is only one option to consider.

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

Best wishes with your project, Dave

I don't want to sway you toward using steppers.  In my use case they make more sense.  For a large bot (> 20 lbs) that doesn't need precision, I do think motors/encodes might be more practical.

Posted by: @fester225

↑

My biggest problem with using stepper motors for vehicle movement is the variation in required torque levels during normal motion.

Very true.  Two things helped me reduce power usage on mine using the DRV8825.  You can disable the stepper driver when it is stopped.  It uses zero power.  The other is simply dial down the current to what is necessary.  On my current bot, I'm set the maximum to 0.4A.  On my usage pattern, I'm getting over about two hours on a charge of 4 x 18650.

There is a slightly more expensive option.  The TMC2209 (~$5).  I have some, but haven't experimented with them yet.  They have settings to control the current limiting AND they have a mode "Cool Step" to only use as much current as is necessary.  They also can tell you when they are about to get overloaded an about to lose a step.  All this without an encoder -

VBR,

Inq

Posted by: @davee

↑

For further information, see: https://www.ti.com/lit/an/sbaa565/sbaa565.pdf?ts=1703831771114  /a>   which includes the following snip: (click image to enlarge)

Enlightening!

@fester225 - Do you have a coined term you want to use for your strategy where each motor has its own MPU?  I'll use the term Motor-Module or M&M's for short.

@davee,

In the most familiar case, of having multiple sensors on a bus, the MPU is the controller, sends the address of one of the sensors which tells it to send its data back.  Then the MPU would "address" the second, third sensors... etc. 

In the case if @fester225 chose to use I2C (which is what I'd also suggest as a wired solution) the "brain" would tell an M&M what speed to run.  If he can trust the MPU to precisely control the motor (stepper that'd be inherent)... then no "response" back to the "brain" is necessary.  Coordinating two M&M's to keep the bot on a strait line... might required some feedback.  This need... I can wrap my head around for many different modules.  But from the paper you referenced...

An I2C controller device starts and stops communication, which removes the potential problem of bus contention.  Communication with a target device is sent through a unique address on the bus. This allows for both multiple controllers and multiple target devices on the I2C bus.

This is news to me.  Actually I need to study this in detail.  I can see great potential for its use, but I got lost in all the EE jargon about drains and can't see how it will work.  I'll paraphrase what I think it says (to me).  That when a controller initiates a message, any other controllers or peripheral will not interfere.  When it frees up (say... the request for sensor data) the peripheral takes over and responds.  After it finishes, the line is free and any controller can send the next message.

So what happens to the controller that "lost" the initialization race.  Does its communication get lost?  Does the I2C guts buffer the message and send it when the line becomes free?  Or does the I2C chip on the controller reply to the MPU that the line is tied up?  IOW, it seems to say there is no way for electrical signal contention, but what about logical, message contention?

VBR,

Inq

Hi @fester225,

RE: My biggest problem with using stepper motors for vehicle movement is the variation in required torque levels during normal motion. Of course I could simply turn the current all the way up all the time, and that would pretty much guarantee correct stepper motion. On the other hand, it would also use more current than necessary.

Others, especially @Inq, have far more experience of steppers than I have, but I'll offer a personal observation.

As @Inq has already mentioned, (virtually?) all of the 'personal' 3D printers have 4 or more steppers operating in an 'open loop' fashion, where the controller instructs each motor to step and 'assumes' the step will happen ... and while things can foul up, the fact that even the low-cost machines can produce good models, shows that the assumption is generally justified. Of course, this means the motors are running with at least, a slightly higher than minimum current, but in principle at least, the current to each motor can be preset to an 'optimal' value, albeit possibly determined on a trial and error basis. 

The common 3D printer motor drivers have a small potentiometer that can preset the current. I think I read that some of the 'better' driver chips can also be commanded to set the current in software, suggesting it might be possible to change the current to meet changing circumstances, but I haven't seen any examples of it in use.

The more 'exotic' 3D printers may have monitors to check that each motor is behaving as instructed, with feedback loops to watch for missed steps, etc. and the ability to take appropriate action. This could also apply to a robot, but some thought is needed to consider the likely 'failure' modes. e.g. if the motor is powering a wheel on robot/vehicle, then motion errors could be due to the motor 'stalling' or it could be the wheel slipping or skidding on the ground. Monitoring the motor spindle motion would 'spot' the first issue, but miss the second. Which is more likely to be a problem will vary with each case. This is the typical situation that means designing a new widget often involves a fair amount of experiment and redesign, including fixing the unexpected.

Of course, the natural precision of a stepper motor, in which the controller specifies its position to say 1.8 degrees with full steps, and tiny fractions of a degree with micro-stepping, makes it an 'easy' target to spot when it misses a step. With most rotary electrical motors, changing the mechanical load may change the rotation speed, so that rotation monitoring and feedback is needed for precision positioning. As with most engineering cases, both approaches have their benefits and problems, so you have choices and decisions to make.

Good luck and I hope you enjoy the challenges, Dave

Posted by: @davee

↑

I think I read that some of the 'better' driver chips can also be commanded to set the current in software, suggesting it might be possible to change the current to meet changing circumstances, but I haven't seen any examples of it in use.

I think you'll find the YT above enlightening on these aspects.  It is not able to tell you if and how many steps you've missed, but it can tell you it is getting near to missing a step.  It does have both of these other features... dynamic adjustment of maximum current as well as letting it do it automatically.  IOW setting it to maximum and it'll reduce the current if it is not needed to hold the current or move to the next step.  That last part start at about 2:08.

VBR,

Inq

P.S.  These TMC2209's are going on Inqster... one of these days.

Hi @inq,

   In comment to your questions about I2C, I confess a certain level of ignorance regarding the fine print of what happens when there are multiple controllers. The bus is so easy to implement, in many cases it is easier to make another bus, so no squabbling is possible.

But, if two or more controllers are required on the same bus (of any type, not just I2C), then there are two levels of contention, Hardware and 'Protocol' to consider:

Hardware:

... basically, if two controllers try to assert a level on a wire, one wants it high, the other low, what happens?

With I2C, the wire is only 'driven' to high by a pull-up resistor. The transistor outputs from the controllers cannot drive it high.

Hence, the output that wants it high, basically ensures its output is 'turned off' and hopes an external resistor will pull it high.

The output that wants it low, turns its output transistor on, causing current to flow from the external pull up resistor to ground (0V), causing the voltage at the bus to fall to near 0V ... (or low).

So essentially, the output that wants a low, always wins!

---------

Protocol:

Those with long memories will remember Ethernet based on a coax cable. The cable could be fairly long, and the bit rate was fairly high (for the time), so that if two outputs tried to send a message at the same time, if they were at opposite ends of the cable, both outputs could have transmitted several bits before the bits from the other output had actually 'met' and both messages started to get scrambled. Obviously, each sender listens for a 'quiet' time, but that would not prevent all collisions. So both outputs would listen to what was on the bus and abort the message sending if it was corrupted. Then both outputs would wait a random amount of time, before retrying. This scheme has benefits, but tends to suffer from overloading from the retries, etc. at levels well below the simple bit rate limit.

By contrast, CAN bus, which hardware-wise is very roughly similar to I2C, starts each message at a bit rate that means that the voltage level across the length of the bus 'settles' before the end of each bit time. This obviously limits the length of the bus and the associated bit rate, but it means that if two transmitters are active at the same time, the condition will be detected on the first bit that is 'high' for one, and 'low' for the other, as the one wanting 'low' always wins!

Furthermore, as the first part of the message is an 'address', the transmitter that sent the 'low' continues with the remainder of the message, whilst the transmitter that wanted a 'high' immediately discontinues sending and waits for the next quiet period to do a retry. Thus, no 'bus time' is lost with retries, although a 'greedy' transmitter with addresses starting with 'low's can dominate the bus.

I confess, I haven't worked through the protocol with I2C, and a quick glance at the sheet I referenced noted that it gets more complicated when there are different data rates involved, so I am not sure if I2C is identical to CAN bus, but my first impression is that it may share some similarities. However, there will also be some major differences, as CAN bus addresses are not (usually) chosen as source/destination, but rather labels describing the data in the packet.

-------

So, apologies for waffling around the question ... I hope some of what I said is helpful, but please treat it all with a large dose of caution. Although, I have considered issues with bus traffic over a long period of time, I am still unravelling many issues that arise.

Best wishes, Dave

Posted by: @davee

↑

Those with long memories will remember Ethernet based on a coax cable.

Gosh!  You're making me feel really old.  I remember something that was daisy chained... and if someone turned off their computer, the whole rest of the daisy chain fell apart.  I also remember Token Ring.  

@davee,

Again, thank you for your deeper, research and theory understanding than my trial and error hacking can provide.  I'll have to add hacking on multiple controllers to my TODO list.  Without trying it, it seems to me it being built-in hardware on some of the smallest/cheapest MPU's, it is unlikely to include buffering and resending of a message (like TCP/IP over Ethernet) would do.  I hope at least that the losing software layer could detect the logical contention.  Then it becomes a question whether the I2C library(s) we use supports this back to our Sketch.  

@fester225,

You see there are lots of varied help available here on the forum.  I rely on the hardware guys for much of my learning.  I sometimes even regurgitate their advice to others.  I really like your modular approach, but you might see from our side discussion, that any of these communication strategies have this problem to overcome... contention (two people talking over each other).  When it happens, neither message gets through and depending on how timing critical it is, a resend may be too late or screw things up even worse. 

If you are considering a differential steering type motive power like tanks and bulldozers or like my Inq bots, I might suggest you combine driving two motors with one MPU.  That way, all feedback and synchronization between the two motors and encoders is handled within the code of the one MPU and not requiring back and forth communications.  Just a thought.

If you are considering a quadruped, or biped bot... well you're way above my current pay-grade.  That's on my 10 year plan. 😆 

VBR,

Inq