Moti, a smart servo

I haven't posted an update in a long time, and people suspect that the project is dead. Actually, it isn't. I got busy at my job for most of 2015. But things died down a bit this year, and so I've been pushing ahead on the project, revising both the circuit and firmware.

What's changed? Most significantly, I switched from using the atmega328 to using samd21 (ARM cortex m0+). This allowed me to resolve a bunch of nagging problems. For one, now you can program the servo directly over USB, rather than having to purchase an FTDI dongle. Secondly, I was running out of flash space and RAM on the 328, and so now there's 8 times more of each, as well as 3 x speed jump, and 32 bit instruction. Thirdly, because of the performance gains Moti can now effectively make use of an RTOS to schedule events, which makes it easier to program because many tasks automatically happen in the background. Fourthly, The magnetic encoder has also been redesigned so that board is integrated into a case. I hope to sell these soon enough as their own thing for anyone looking for 360 degree sensing.

In the following video I go over these topics, plus demonstrate some of the performance characteristics of project. Let me know your thoughts.

Recently, I've been working on basic motions with Moti; things like shooting over distances, stepping, and braking. This started with comparing different types of braking: regenerative, dynamic, locked anti-phase, and even coasting to see which would stop the motor faster. Regenerative and dynamic braking were pretty much the same, and the best performing. When initiated at full speed, it takes about 15º to come to a stop. Locked anti-phase braking didn't perform well, though I'm sure it could be done better. However it generates an audible buzz at the 500Hz PWM frequency I'm using, and I couldn't stand it...so I quickly moved on. And of course coasting was the worst and was used as a control. So for the moment I'm using dynamic and regenerative braking. This website was helpful for understanding the differences between each.

Before jumping into stepping, I wanted to see how an RC servo controls it's motor, and here I'm talking specifically about the output from the H-Bridge, so I spent some time probing it with my scope. I've uploaded a playlist of these explorations. The TL;DR of the matter is that this was highly useful. Not only did I learn how an RC servo steps, but also how it shoots and decelerates when approaching its destination. I was then able to whip up a step function that produces what appears to be both finely grained, and repeatable steps. I dabbled with shooting, but don't have anything conclusive to report about that yet.

There hasn't been much progress on Moti for a couple of months now as I was busy with teaching and another project. Now that those things are wrapping up, I'm looking forward to getting back to it.

A couple of questions for you. If you had to choose, would you prefer:

1) a few breakout pins and a smaller servo,

2) more breakout pins and a larger servo,

3) more breakout pins that are smaller-pitch (eg. 1.27mm or 2mm instead of the commonly used 2.54mm)?

Lastly, congrats to SatNOGS on winning the Hackaday Prize. It's an awesome project, as were all the finalists.

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

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.

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 interrupt as well, with a different priority than the motor handling routine for more efficiency. There are some remaining concerns with this approach with respect to potential conflicts between main loop code and the ISRs (e.g. overlapping analogReads), but I think I can handle this in the background, either in the ISR, or with a custom Moti.analogRead() method. So it looks like I'm moving forward with handling updates in the background with interrupts.

As usual, I'd love to hear any feedback you have.

Here's a rendering of a fully assembled moti:

and here's an exploded view:

The exploded view shows how the product assembles together. You can see how the magnetic spindle has a shaft that fits in the output gear. It's the same size as the potentiometer shaft used used in conventional servos. The spindle spins right above the magnetic encoder IC which is on the bottom side of the pcb.  The spindle maintains it's rotation axis by fitting a nipple (?) into a registration hole in the pcb. The design has changed a little since this model was generated but it's still quite close.

Drawings were done in Solidworks. The same designs are used to generate .stl files that have been used to 3d print the case bottom and the housing for the magnetic spindle.

I've been working on the firmware without actually doing a whole lot of coding. I'm kind of circling from the outside to suss it out without rushing in. My ideal is to improve the quality and so I'm looking into best, or at least better practices. Recently, I've been reading Making Embedded Systems. I recognize the risk of brown-nosing here as it's written by one of the judges, but it's also on my mind right now. See, I have no formal training in engineering, and in order to improve I need to see things in practice. This book contains some really nice design patterns for better organizing firmware, and shows examples of how to implement them. The book I discussed previously, turned out to be a bit too theoretical, which is fine if you have the training but left me wondering "ok, but how?"

Anyways, some of what I've been working on includes the following diagrams. For the record, these kinds of diagrams are not discussed in the book. The first two are use cases. This one represents a sequence of actions, and invoked methods that occur when someone remote controls a Moti-enabled robot:

The second shows a sequence of events that occur when someone is recording a sequence of manual manipulations of a Moti enabled robot, and then plays them back:

These diagrams are not exhaustive. There's more steps involved. However it's enough to suggest that the model for breaking code apart could work. Okay, so having done the use cases I went on to make a UML class diagram. Now, I can imagine that many think it's a waste of time, but for me I wanted to try using one of the tools available to clarify each class and their relationship before writing them. 

One thing I realized making the class diagram was that I could decouple the network hardware from the network protocol. Maybe that in itself made it worthwhile. 

Anyways, it's all still new to me so If you see anything wrong with the diagrams please let me know. It's been a fun exercise and quite the opposite of how I usually dive right in...I kind of feel like George Costanza:

By the way, if you want to use the same tools I did, try draw.io for the class diagrams, and the very cool web sequence diagrams for you guessed it, the sequence diagrams.

I just discovered that Austria Microsystems (AMS), my preferred source for magnetic encoders have recently released the AS5600. It looks very promising compared to the AS5050A I have been using. It costs $1.65 (per 1000) versus $2.98 for the 5050, and has 12 bit resolution versus the 10 bit of the 5050. It also requires fewer external components, and can run at 3 or 5V levels. This means I can eliminate a voltage regulator, a level shifter, and several passives. Switching to the 5600 should reduce the BOM cost by at least a couple of dollars. It even uses I2C or Analog out, instead of SPI + interrupt line, so even fewer IO pins will be consumed. 

At any rate, I will continue developing with the 5050 for now, and later swap to this newer chip. In theory, it shouldn't be too complicated to switch from one to the other, because Moti has a modular design where the encoder is broken out on it's own board.

In fact, the flip side of the Moti encoder board was designed to the AS5161, which turned out is not appropriate for Moti. However, its SOIC-8 package, and the layout of the power pins and analog out pin are the same as the 5600, so I may be able to start working with it right away!

Hmmm, it would be pretty awesome if I can use just an A2D pin to capture position, because then the encoder board could perhaps be swapped for a pot if the user wanted to try Moti circuits in regular servo motors.

Once upon a time, I said this about having written the firmware as one huge file: "While it wasn’t as bad as you’d think, it’s clearly not ideal." This is the understatement of the year. It is as bad as you'd think. Disentangling, and refactoring into different libraries is slow, painful and messy! But at least it's getting done. I'm also looking forward to writing fresh code for the new hardware. 

On a related topic, in my haste to get the boards done, I overlooked an issue. The Micro's UART joins to the RS485 bus for daisy chaining. But this is also the port by which the Micro is programmed (and potentially communicated with while running) by another UART (eg. FTDI), so potentially two TX lines are tied to one RX (the micro's). Now imagine one goes LOW during transmission, the other is still HIGH, and so not only will the transmission fail, but the two competing lines may short out if they are unprotected. The remedy (working so far) is to add a couple of shottky diodes to prevent either of the TX lines from pulling the micro's RX HIGH, which is instead provided by a pull-up resistor. It's working, as I've been able to bootload the firmware onto the Processor board...so hooray for that. However it looks like at least another board revision is in order.

In other good news, I received a Hackaday Prize T-shirt for Moti having done well in one of the open votes rounds. So thanks!