Close

Does this project spark your interest?

Become a member to follow this project and don't miss any updates

Moti, a smart servo

Moti is a smart servo that simplifies the design of intricate robots.

13.6k 37 268 207

This project was created on 03/01/2014 and last updated 12 days ago.

Description
Moti is a smart servo motor that makes it easier to build robots. Picture building a humanoid with lots of moving parts. You'd need a motor and a few sensors in each joint. You need additional circuitry to control everything, and you'd have a mess of cabling connecting it all together.

Moti makes it easier to build such systems by providing requisite features within the motor. There's a programmable microcontroller, breakout pins for attaching sensors, daisychain networking, and a continous rotation servo, with 360º position sensing inside each Moti. It eliminates the need for external circuitry.

We also want Moti to play well with the web and mobile devices, so there's a RESTful API for developing apps. And we've built the first one that gives you immediate control of your Moti-enabled robot.

There's more to do. Check out http://moti.ph
Details

Video overview of Moti:

The video is quite long as it is, so I'll discuss the server and app layer in a future video.

What the system diagram illustrates is that you can use our prebuilt web app to recognize, monitor, remote control & program your robot. Alternatively, you can build your own app (or use someone else's) that is customized for your application. Thirdly, you can program the motis directly to create an autonomous system.

Components
  • 1 × ATmega328p Main Microcontroller
  • 1 × 16MHZ Crystal
  • 1 × MCP1703 250mA 5V Voltage Regulator
  • 1 × AON4420L N-Channel Mosfet for Reverse Polarity Protection
  • 1 × ISL81487IBZ RS-485 Driver
  • 2 × 1x6 0.1" smd female header for breakout pins, including GPIO, A2D, I2C,
  • 1 × 2x4 0.1" smd male header to attach 2x RS-485 cables
  • 1 × 2x12 0.05" smd female header connects processor board to driver board, plus ISP header
  • 1 × VNH5180A Interface and IO ICs / Peripheral Drivers and Actuators
  • 1 × 10k thermistor

See all components

Project logs
  • Moti v0.3 Bring-Up

    12 days ago • 0 comments

    I spent much of the day getting the driver-level facilities working at their most basic. I've heard this described as bring-up, though it's the first time I've used the term, so I could be misusing it. Anyways, it was a great day, as a number of features were tested, and all worked. Thank god for using monolithic ICs instead of custom designed circuitry. It works just as specified in the documentation. Here's a playlist of a bunch of videos showing what was done.

    http://www.youtube.com/playlist?list=PLGputUCrELcBbJ8MHORK8IlhqORT-YfaO

  • Super Brief Documentation

    18 days ago • 0 comments

    Moti Firmware API Documentation The Super Brief Version

    Here's synopses of the API methods provided for using Moti in the Arduino environment. Once I actually finish coding the methods I'll post more complete documentation...but this gives you the idea.

    begin(SerialPort)
    - initializes a moti with stored settings, and uses the provided Serial port for communicating over network.

    reset()
    - reset to default settings.

    update()
    - force motor update critical processes including checking for network messages, reading encoder, and changing motion as necessary.

    close()
    - shut down the motor.

    rotate(int speed)
    - Keep on going at the given speed

    rotateTo(int speed, int angle)
    - Goto a specific angle at the given speed

    rotateFor(int speed, int degrees)
    - Turn for the given number degrees relative to the current position.

    stop()
    - Stop moving and hold position.

    freeSpin()
    - Cut power to motor. Will rotate under external load.

    speedWrite(int speed)
    - Set the speed...affects any motion in progress.

    loadWrite(int load)
    - Set the stall torque of the motor.

    angleLimitsWrite(int cwLimit, int ccwLimit)
    - Set the angle limits. Limits motion between the specified limits.

    angleRead()
    - reads the encoder, and returns angle as int.

    speedRead()
    - calculates and returns the rotations per minute as int.

    currentRead()
    - reads the current sensor, and returns current measurement as int.

    temperatureRead()
    - reads the temperature sensor, and returns temperature as int.

    voltageRead()
    - reads the voltage sensor, and returns voltage as int.

    analogRead(int pin)
    - reads ADC value of the specified A2D pin, and returns the raw value as int.

    digitalRead(int pin)
    - reads the binary state of specified pin, and returns the state as int.

    analogWrite(int pin, int value)
    - writes a PWM value to a PWM pin.

    digitalWrite(int pin, int value)
    - writes a binary value to a pin.

    registersRead(int register, byte data[], int length)
    - reads a block of moti registers into the provided array.

    registersRead(int register, int data)
    - reads two consecutive 8-bit registers, and returns them as a single int.

    registersRead(byte register)
    - reads and returns a single register as a byte

    registersWrite(int register, byte data[], int length)
    - writes a byte array to a block of moti registers.

    registersWrite(int register, int data)
    - writes each half of an int to two consecutive moti registers.

    registersWrite(int register, byte data)
    - writes a byte to a moti register.

    nameRead()
    - reads and returns an 8 char array used to store a user-designated label for the moti.

    nameWrite(char name[])
    - writes 8 chars of the given array to a block of moti registers. Meant to store a user-designated label for the moti.

    enumerate()
    - query all available motis on the network. They will each reply with their unique ID.

    ping(int id)
    - check for the specified motor on the network.

    messageAvailable()
    - checks the network port for new message and returns the length of the message as an int, or 0 if no message.

    messageRead(byte data[])
    - checks the network port for new message and saves it to provided array.

    messageParse(byte data[], int length)
    - decipher the message, and return a struct containing the ID of the Moti, the command, the parameters, the length of the message, and other parameters if available.

    messageWrite(struct message)
    - packetize and send a message over the network containing the IDs of both sender and receiver, the command, the parameters, the length of the message, and other parameters if available.

    ---

    N.B. int here means uint16_t, and byte means uint8_t.

    N.B. Methods can be overloaded by providing an ID (int) as the last parameter, or a name (char[8]), in which case this Moti will trigger the operation to occur on the designated Moti in the network if available. The only exceptions are begin(), enumerate() and ping(). Overloaded methods are not shown here for brevity.

  • update on update( )

    19 days ago • 0 comments

    I've been mulling over how to make Moti's programming interface flexible, like Arduino, while regularly running a number of required processes, including reading the position from the encoder, checking for network messages, and affecting the motor as necessary.

    Option 1: Update Moti in the main loop.
    Up until now, I've been using an update() method that executes all the required processes. This is called from the main loop at regular intervals (look at the Arduino screenshot here). It works fine if you are using the default firmware, as you probably are if controlling from another device (eg. mobile app, computer), but if you want to modify the firmware, say to create an autonomous robot then the scheme's shortcomings start to show. In particular, it forces the user to deal with scheduling the updates, which is a hassle. The problem is that if the motor is rotating to a position and it is too long between updates (and thereby reading encoder steps), we risk rotating right past the destination, a potentially catastrophic failure.

    How frequent does Moti need to update? It depends! The period between updates can be no longer than the time it takes to move one encoder step. Our current hardware peaks at about 80rpm, which means it takes ~1333 ms per 360º. Since the encoder ADC is 10-bit, that's 1333/1024 = ~1.3 ms per step. That's often! There's not much room for other processes to happen in the main loop when we have to update so frequently…certainly no millisecond delays. Keep in mind that this is a worst case scenario. You'd have to be using specific methods (rotateTo() or rotateFor()) at the fastest speed to require updating so often, which suggests that the frequency could be reduced when the motor is further from it's destination, and/or is moving at a slower speed.

    Returning to the problem at hand, in this scenario, the user is forced to work out these timing issues and ensure that update() is called as often as necessary. But do they want to do that? I'm betting No. Imagine trying to write a program while making sure that a process executes every few milliseconds, every other line might be update()! There may be scenarios where a user needs to manually update, but as a default I think it would be better to bury it in the background.


    Option 2: Update Moti in the background.
    You may have already figured out that we can use interrupts to schedule updates. A timer interrupt is set to go off in time to execute the update() before the deadline. This is great, because if the update() runs in the background, a user can program the main loop normally.

    But this approach has it's own issues. As a rule ISRs are supposed to be kept as short as possible, but how long is too long? Moti's update() currently takes approximately 0.5ms. Is that too long for a single ISR? I think so, as it may interfere with time sensitive operations in the main loop. A common strategy to avoid long interrupts is to set flags in the ISR and then deal with them back in the main loop. However, this puts us in the same predicament as scenario 1, where the user is forced to deal with update() in a timely manner.

    Better, would be to reduce update() to a minimum so that it can be handled in the ISR. Right away, I think we can cut the routine in half through basic optimization. Also, a major chunk of that time is consumed by reading the encoder. Instead of waiting, we can monitor the conversion with another interrupt. Now we have:

    1) run main loop operations until timer interrupts
    2) timer ISR: start ADC encoder reading with interrupt
    3) run main loop operations until ADC interrupts
    4) ADC ISR: check for new messages from network, change motor state if necessary

    By peeling off the analog conversion from other processes, I think we can shave another 0.125 ms off the ISR, leaving us with an ISR of 0.125ms. I think that's worth a try, and I'll follow up in the future after giving it a go. I may also partition the network checks off into their own timer-based...

    Read more »

View all 11 project logs

Discussions

VPugliese323 wrote a month ago null point

I have one question not addressed by your project logs. Are you planning on addressing security concerns; as a networked device, do you have any plans to make your device more secure that I gather it presently is? To be specific, after reading your project logs, it seems as if anyone could (in theory) SSH over to the server controlling the motors and control them. For an industrial robotics project, that would be extremely dangerous. I realize that you cannot have perfect security with this (or any connected) technology, however I did not see any mention of how the connections are secured. I may have missed something because I was reading quickly, if so then my apologies. This is an interesting project, I like it.

Are you sure? [yes] / [no]

nsted wrote a month ago null point

Thanks for the question. The short answer is that we haven't built any security features at this stage, but aim to as the project develops. We'll need help in that area. Do you have any suggestions?

Are you sure? [yes] / [no]

VPugliese323 wrote a month ago null point

For these kinds of things, I must admit I default to two good books on the matter that I have. http://www.amazon.com/Counter-Hack-Reloaded-Step-Step/dp/0131481045 and http://www.amazon.com/Secure-Coding-Edition-Software-Engineering/dp/0321822137

Are you sure? [yes] / [no]

PointyOintment wrote 3 months ago null point

You might find this interesting: https://www.youtube.com/watch?v=_g79mOSvSsE

Be sure to check out the link in the description.

Are you sure? [yes] / [no]

nsted wrote 3 months ago null point

Very very Cool, but the links redirect, or 404.

Are you sure? [yes] / [no]

Jasmine wrote 3 months ago null point

Hello nsted, now is the time to add a few more details to your project to give it the best chance of going through to the next round of The Hackaday Prize.

By August 20th you must have the following:
- A video. It should be less than 2 minutes long describing your project. Put it on YouTube (or Youku), and add a link to it on your project page. This is done by editing your project (edit link is at the top of your project page) and adding it as an "External Link"
- At least 4 Project Logs
- A system design document
- Links to code repositories, and remember to mention any licenses or permissions needed for your project. For example, if you are using software libraries you need to document that information.

You should also try to highlight how your project is 'Connected' and 'Open' in the details and video.

There are a couple of tutorial video's with more info here: http://hackaday.com/2014/07/26/4-minutes-to-entry/

Good luck!

Are you sure? [yes] / [no]

flaco wrote 4 months ago null point

Here's something really interesting ! :D

Are you sure? [yes] / [no]

Robot wrote 4 months ago null point

Wow. Such a worthy product; I'm sad to see that the kickstarter failed.

Are you sure? [yes] / [no]

crener wrote 4 months ago null point

Hmm, i wonder if i could put one of these in place get all the settings/timings that i need (e.g. for a hex) and then replace with a normal servo?

It should work as long as i don't use any sensors that are attached to it. I just "learn" a pattern with the smart servo and then swap it with a normal one one i have its positional informaltion captured.

Anybody think this could work?

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

That's an awesome idea that hasn't come up before. It should work as long as moti exceeds your max requirements in speed and torque.

Are you sure? [yes] / [no]

Tiago wrote 4 months ago null point

I really like this project, might buy a bunch if they are not too expensive. Already got a bunch of ideas in mind for them. When you say full rotation position tracking do you mean it has a range of 360 degrees, or continuous rotation with an encoder? If it is an encoder, then am I correct in assuming that they do not know their position on startup, only relative positions?

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

Thank you. A new development is that Moti has a 10-bit magnetic encoder with a 360º range, so the absolute position is always known. There are no mechanical obstructions limiting rotations, so it can continue rotating as long as needed, and every 360º/0º rollover is logged in a register, which you can clear when you like.

This can be used in several ways. For example, you could have it turn precisely 1001º. Or you could remote control it to go some distance, and then read back how many degrees/rotations were required to get there. You could even manually turn the motor, record the positions, and then replay the patterns.

Are you sure? [yes] / [no]

Tiago wrote 4 months ago null point

That's really cool, would be so helpful for a project I am working on at the moment :) How much will they cost, aproximately, and when will they be available?

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

It's still going to be a while before Moti is released. We'll probably start beta-testing the new design this fall, and hopefully have a release (at least of the boards) later this year. As for price, I'd like to keep it below $55 for a preassembled servo (and cheaper of course for just the assembled boards). I know that sounds expensive but the driver, encoder, Arduino and motor end up costing a fair bit. Actually, I'd love to hear reactions to that price?

Are you sure? [yes] / [no]

Tiago wrote 4 months ago null point

Sounds pretty cheap, actually. A 1.5 turn servo with position control will be much costier.

Are you sure? [yes] / [no]

mandoline wrote 4 months ago null point

Nice idea. Can these be RF controlled, because that would indeed be handy.
Also for robotics use a regular servo could be used as the backplate and its existing controller chip grafted onto the new board with the magnetic rotation sensor to add longevity.

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

We've got bluetooth and xbee already, but for other RF one could design a new shield.

Are you sure? [yes] / [no]

regiscruzbr wrote 4 months ago null point

Kick ass project...
I have an application for it on my home automation.

Are you sure? [yes] / [no]

pajolegault wrote 4 months ago null point

This is a great example of a project that makes the stuff to make the stuff.
Some development variations I could see working with this. Add a hall effect sensor and accessible positional PID so that the motor can monitor and report on its loading, be tuned, and work with a wider range of voltages.

A pickle adaptor for use as a remote and for training the embedded micro.

Slaving for systematic control. You control one servo and it can control at least three other servos. For example you could have the fast servo, have it control the ratchet directional- position locker toggle servo, and the slow geared ratchet drive high torque servo, and a weighted spring, hammer drive loading servo. Or simply use a push me pull you control between two servos so that when one servo winds in, it tells another servo to wind out.

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

Thanks for the feedback. Are you thinking hall effect for position, or current sensing, or something else? We've switched to a magnetic encoder for position, and current sensing is provided by the h-bridge. PID settings are open as you suggest. I hope to add more detail soon, and update the pics.

I have no idea what a pickle adapter is?! But it sounds like something awesome.

We're also switching from i2c to rs485 because of the extra distance it affords, with up to 128 nodes (at least in theory). You can customize the addressing, and program the nodes to achieve the desired network topology.

Are you sure? [yes] / [no]

pajolegault wrote 4 months ago null point

A pickle is just controls on a cable, so a wired remote. You can plug in a joystick for example. It might be jargon specific to some industries. I should have just said a wired remote.

Bluetooth would also work and no socket needed.

Are you sure? [yes] / [no]

pajolegault wrote 4 months ago null point

I was thinking of the Hall effect sensor for the motor current.

Current sensing is provided by the H-bridge or current limiting?

Are you sure? [yes] / [no]

nsted wrote 4 months ago null point

We're trying out the VNH5180a with built-in current sensing http://www.st.com/web/catalog/sense_power/FM1965/SC1039/PF250358
Will post how it works out.

Are you sure? [yes] / [no]

samern wrote 4 months ago null point

I have some many projects for this thing, the mind boggles. I wish I knew, I would've contributed to the Kickstarter.

Are you sure? [yes] / [no]

technolomaniac wrote 6 months ago null point

Awesome concept! Very cool to see and super interesting!

Are you sure? [yes] / [no]

dave.m.mcdonough wrote 6 months ago null point

Is this just a servo piggyback board or the complete package? Because I'm curious about the servo torque specs, or if I want to use a bigger motor..

Are you sure? [yes] / [no]

nsted wrote 6 months ago null point

The plan is to offer both a preassembled servo, as well as make the boards available so you can put them inside the servo motor of your choice (though they may not fit inside every case).

I don't have final specs on the on the torque of the preassembled servo, but conservatively it will be at least 11 kg*cm with metal gears. And one thing I'm looking forward to is the ability to use it with gearboxes to up the torque without having to hack the servo. (eg. https://www.sparkfun.com/products/12606).

Are you sure? [yes] / [no]

zack wrote 6 months ago null point

This is great, the added accessibility is really cool! My personal need is something with the specs of a Dynamixel AX-12, but with continuous rotation sensing. It'd be nice to see more than just Robotis serving the "smart servo" market.

Are you sure? [yes] / [no]

mbasecnc wrote 7 months ago null point

Very very nice, I saw your Kickstarter campaign, to bad you didn't make it.
The world needs a good open source servo board!
As in open source, where is the source?
Keep it cheap and you will be succesfull!

Are you sure? [yes] / [no]

nsted wrote 6 months ago null point

Thanks...the Kickstarter campaign was a disappointment, but we learned a lot from it. We haven't released the source yet, but we will once the first version of the servo is finalized and made available for sale.

Are you sure? [yes] / [no]

Eric Evenchick wrote 8 months ago null point

Hey, just wondering about latency on these. It looks like you're using the HC-05 modules, or something similar. I've had some issues with latency over Bluetooth in the past, so I'm just curious what your thoughts are on it.

Are you sure? [yes] / [no]

nsted wrote 8 months ago null point

Yes, the motor on the left shows a Bluetooth shield with HC-05. There's a bit of latency, which is on the list of todos. See for yourself: http://youtu.be/kR_jN62QUPI

The middle motor shows the pins that shields plug into. So you can connect your preferred serial module and set your own baud. For example, right now I'm using an FTDI cable while developing...I'll upload a pic.

Are you sure? [yes] / [no]

assadollahi wrote 8 months ago null point

isn't that a bit similar to the dynamixel servos (position aware, daisy-chainable)? except for the web-interface?

Are you sure? [yes] / [no]

nsted wrote 8 months ago null point

It’s more like an arduino and dynamixel combined. You can program moti directly, or add sensors, and so you don’t need an external microcontroller. Also, the 330º angle sensing limits of most dynamixels really bothered me…so we gave moti full-turn position tracking.

Are you sure? [yes] / [no]

tamberg wrote 8 months ago null point

+1

Are you sure? [yes] / [no]

brian kame wrote 8 months ago null point

Great job! I love the concept.

Are you sure? [yes] / [no]

Similar projects