I2C Smart Servos (Indiegogo)

[statorworks]

Hello all, just wanted to share my concept of I2C controlled servos.

I'm trying to provide an intermediate product for robotics or animatronics.
This scheme let's you control the force and ramp as well as read the position and power, but without the interface becoming too complex. I think this should help make robots less 'jerky' and it also requires less hardware and software overhead.

I'm trying on Indiegogo, but at this point don't know if Kickstarter could've been better 

https://www.indiegogo.com/projects/kinno-smart-i2c-servos#/

Here are a couple of the videos

[oPossum]

IIC is a really bad choice for an interface. CAN, RS-485 or even S.Bus would be much better.

[alexanderbrevig]

Seems like nice work!

From the first paragraph on I²C from Wikipedia:

...short-distance, intra-board communication

You should really concider a pivoting manouver and select one of the suggested physical layers in the post above mine.

Good luck!

[statorworks]

Thanks for your replies guys. I've tested these to five feet and it's all pretty resilient at 100KHz.
I decided for this as a low cost, low complexity option, but certainly plan on making a RS485 version as well at some point   Thanks for the feedback.

[mikeselectricstuff]

I2C is a terrible choice for a servo, where you'll have motor noise flying around.

[Cyberdragon]

I2C is a terrible choice for a servo, where you'll have motor noise flying around.

It would also make a device susceptable to physical damage from electrical interferance if the motors went out of control.

[m98]

IIC is a really bad choice for an interface. CAN, RS-485 or even S.Bus would be much better.

Ever tried connecting a RS-485 or CAN device to the average dev-boards people are using?
This is perfectly adequate for hobby projects and prototypes, and don't tell me the PWM input of regular hobby servos is particularly resistant to interference.

I would still suggest another interface, daisy-chained SPI would be both a little more resilient and eliminate the need to program the address.

[oPossum]

IIC is a really bad choice for an interface. CAN, RS-485 or even S.Bus would be much better.

Ever tried connecting a RS-485 or CAN device to the average dev-boards people are using?

Yes. No problem at all. Many STM32 and even the ESP32 feature CAN peripherals. I have also written bit-bang CAN code (used for the NV2 unlock).

Even the lowly ATMega328 has features to facilitate proper RS-485 driver control. I have used them.

This is perfectly adequate for hobby projects and prototypes,

It's poor design. It will cause problems.

and don't tell me the PWM input of regular hobby servos is particularly resistant to interference.

It is. Totem-pole vs open collector. There is a difference.

I would still suggest another interface, daisy-chained SPI would be both a little more resilient

Uh, no.

[m98]

Ever tried connecting a RS-485 or CAN device to the average dev-boards people are using?

Yes. No problem at all. Many STM32 and even the ESP32 feature CAN peripherals. I have also written bit-bang CAN code (used for the NV2 unlock).

Even the lowly ATMega328 has features to facilitate proper RS-485 driver control. I have used them.

There is no RS-485 or CAN driver on any regular Arduino, NodeMCU or Blue Pill board.

This is perfectly adequate for hobby projects and prototypes,

It's poor design. It will cause problems.

Literally nobody is going to care about occasional bus upsets that might or might not happen in a toy robot.
And with properly dimensioned pull-ups or a current source, standard-rate I2C runs just fine over a few meters in a regular home/lab environment.

and don't tell me the PWM input of regular hobby servos is particularly resistant to interference.

It is. Totem-pole vs open collector. There is a difference.

There is, but you're still relying on the noise immunity of the unprotected logic input of some unnamed servo controller ASIC.

I would still suggest another interface, daisy-chained SPI would be both a little more resilient

Uh, no.

So you haven't got any qualified arguments?

[mikeselectricstuff]

I wouldn't use SPI due to the risk of clock glitches.I2C has the same potential issue, plus slow risetimes.
For the simplest interface, I'd go for TTL UART, with some simple RC filtering to filter out out-of-band noise spikes.
 

[janoc]

Literally nobody is going to care about occasional bus upsets that might or might not happen in a toy robot.
And with properly dimensioned pull-ups or a current source, standard-rate I2C runs just fine over a few meters in a regular home/lab environment.

You think? When such "bus upset" freezes the robot/gadget because the hw I2C peripheral is now stuck waiting for that clock line to be released? Or worse, when it causes the motor to keep spinning until something breaks because the micro is unable to read some sensors?

Cheap DC motors like those in those servos are terrible when it comes to EMI. I had one of those cheap yellow plastic gear motors in a project and without a boatload of extra noise suppression components (two chokes, several capacitors, ferrite ring ...) there was absolutely NO chance  to run an I2C line to a sensor nearby. And we are talking about maybe 15 cm of wire, not a 50cm+ long antenna you may easily get in a small robot once you actually dress the wires properly.

That I2C runs "just fine over a few meters in a regular home/lab environment" means squat all about running in an environment where you have several brushed motors spewing EMI in one place, along with a wifi or some other radio and a bunch of sensors.

This is a terrible design decision even for toys and will give the user no end of grief. And the OP a lot of customer support/returns/bad reviews.

RS485 would cost literally peanuts to add and would work much better - all you need is a transciever (few cents) and an UART on both sides of the link. Oh and you can actually make a multidrop bus with RS485 too with some care (even though then CAN is probably better).

There is no RS-485 or CAN driver on any regular Arduino, NodeMCU or Blue Pill board.

That's wrong. Blue Pill certainly has CAN (but you can't use it with USB at the same time). Also the more recent Black Pill has CAN peripheral, I believe. You only need a transciever like MCP2551.



Arduino Due (ATSAM3X8E) has 2 CAN peripherals built-in, possibly others. There are also CAN shields available. You can also attach a dedicated CAN controller that talks to the host over SPI if the host doesn't support CAN natively - like MCP2515.

This is literally all you need to make CAN work even on a lowly Uno:

https://www.mikroe.com/can-spi-board

Two chips + a few passives, maybe $5 in parts.

RS-485 does not need any special hardware support, only UART which all of the above have - you just need to add a transciever IC. Those cost peanuts and are typically a simple 8 pin device. Heck, there is even an official Arduino shield with an RS485 transciever.

[oPossum]

So you haven't got any qualified arguments?

I do, but I am going to bow out and let others with more clout continue with the arguments.

[Doctorandus_P]

I also don't like I2C (with it's passive pullups) for such a noisy environment, although the way I2C adressing works would be a quite nice fit.

Regular RC servo's are horrible things. The PWM wastes 90% of the time, which makes resolution inherently low, and there is no way to set the speed of the servo, just position, which makes almost all movements inherently jerky. Dynamixel has some nice servo's with RS485 and HALL sensors for the position, but those are not in my price range. There are some Chinese which make similar servo's for smaller prices, but I have not looked at their prices.

I recently bought two S-bus Servo's Corona SB-3019 and these have an STM8 inside. Unfortunately the S-Bus protocol is also very symplistic (Just positions), no speed, no PID parameters, but with an STM8 inside you've a decent base to put anything in it you'd like.

So if RS-485 or CAN is "too much" (it needs an extra 80ct driver chip) then raw push-pull UART such as S-Bus would be my second choice. S-Bus is only unidirectional though and that's also quite a limitation.

Also:
You write in Indiegogo that you've also got plans for a smaller lower power version, Have you done any "market research" for that? I think I'd be more interested in more powerful versions with a higher current drive, and a version which works with a Hall sensor that can also be used for multiple rotations or continuous speed.

You also write that the 5V option for I2C would be more robust, so apparently you've already had stability problems with I2C @3V3?

You also write that you do not aim for "High precision industrial applications".
Why not? Now you put yourself into a limited toy corner. By just changing the interface to a reliable RS485 you keep the grow path open to something that can be high precision and of (near) industrial quality, depending on the hardware your customers add.
There sure is a market for small lightweight servo's, especially in those flying quadcopters, but the market for bigger higher power servo's such as the "dog-like" walking robots may be growing a lot quicker, and with more money to be made. Having a library for the servo's to integrate them in ROS (Robot Operating System) is probably also a big plus.

I like the Idea of selling small PCB's to upgrade existing servo's, but not I2C. At the moment the Servo's with an STM8 already built in and reprogramming that would be a more interesting option for me.