I know I have been talking about a low cost motor board since forever but I have been waiting for some rather unique pieces of the jigsaw to come together. With that I have just added the Multi Axis Motion Controller (MAMC) project onto Xcore, I have been working on this for some time. Initially I dreamt of a design for controlling 3D printers,laser cutters and Cartesian robots but also robotic arm controls and hybrid delta motion control. These hybrid control features have caused most of the delay which I believe I have finally solved with the new low cost, low BOM, generic hybrid driver section. Although I have included a lot of hardware features on the DACM to cover applications development for those above, this robotics development board can be used in many more robotic applications including small robot builds. So my question is what are the features you would like to see for this tiny robotics platform development board?

The MAMC has female headers allowing add-on shields/capes for added functionality so there is scope to design all sorts of add-ons to customise the MAMC for more specific robotic applications, Thus I am looking for your ideas and feedback for any robotic or motor control applications and features, let it rip...

regards
Al

I really like the modular approach.
So the software will be able to deal with any kind of position/speed oriented motor driver?

Just a thought:
I know that the ways how you can drive motors are numerous (steppers, brushless, DC, servo, …). It would be really nice to see how this is handled in software?

I think there are two ways a motor can be interface:

• speed (positive/negative)
• discrete positioning (steppers & so)

how do you handle this in software?

Or do you restrict it to motors with discrete positioning?

Thats correct, its the crux of the design.



I have limited this board design to DC motor and stepper motors, although it would be possible to do BLDC it certainly isn't optimised for it. Normally such a design is based around discrete driver sections but these complicate BOM and load cost particularly for manufacturing and I wanted a simple low cost solution.

You can however see examples of DC and Stepper software control on Xcore's github repo sw_basic_motor_examples, but this runs on Xmos' sophisticated discrete motor control board design. The software for MAMC won't be to dissimilar to this really, perhaps a little simpler.

In terms of positioning you can use open loop and/or closed loop, for the closed loop it most likely will involve PWM position feedback but SPI/I2C or even Quadarature can be used. You can also measure velocity using an ADC some diodes and resistors measuring back emf for example. I originally toyed with having that on board but in the end have left it as an optional shield add on whilst keeping flexibility and low cost. This is even more so given the use of the 48 pin L1 to push cost down as low as possible. The L2 versions would be able to have even more bells and whistles, but I wanted the lowest common denominator to develop with and make it affordable for everyone.

regards
Al

If you look at the MAMC design it is somewhat different to both Xmos' discrete motor control approach and a full blown stepper/DC driver chip. It sits in between by controlling the chopper rather than being the chopper for instance, this provides flexible control with much less overhead in software. That reduced overhead can be used to do more useful work around higher level control and requires less Xmos hardware for the same performance at least with DC and stepper motors (BLDC has different payoffs).

regards
Al

Ha,

first I thought you got me wrong, but your second post shows me (or at least I can presume) you got me right:

I think a basic decision is to get the motor control right. So that the actual motor drivers are something after the control.

The control manages position (if applicable) spped and commands regarding this. In multiple dimensions which adds up to the complexity.

The motor driver knows if the motor supports stuff like positioning or giving the motor a certain speed.

By this modular approach you can have two axis with stepper drivers and one axis with brushless servos or so. And by that you can add multiple drivers for discrete motor control or using some motor dirver.

I confess that I am massivly influenced by the LED tile app - but it got that kind of separation. On the one hand you got the LED buffer (which translates to motor control) and the LED driver, which translates to the motor driver.

In the end you got something like this (sorry for the dump ASCII art):


What do you think?

Sure I think this kind of separation is possible but there are also complications.

For a RepRap for example


But the dynamics of steppers and DC motors are rather different and that will effect planning and acceleration for example, so it may not be completely transparent as an abstraction.

regards
Al

Yes, there will be many differences in the 'application level' regarding different motor types. And I think making them completely transparent (or opaque - whatever you prefer) is not easy/impossible in the first step. Perhaps after some years of experience ;)

I think from a low level motor driving point of view there may be only two differences: If the mototr supports positioning (like steppers) or not (like DC motors without any kind of encoder). But I am a bit unsure if that really exists (you can assume DC motors position according to runtime and speed, but this will be very unprecise) or if it is the only difference in the motor driving.

All differences in the discrete driving, driving current, driving scheme, acceleration charateristics and so on are presumably managed inside the motor driver.

You still have open loop and closed loop systems. For example RepRap position control is currently open loop relying on microsteps for accuracy. That is also why you get repeatability problems and calibration issues with RepRaps, this stems from inaccuracies in the system like backlash. Adding closed loop control can account for and compensate for issues like backlash even with stepper motor drive systems. So one could say that the open/closed loop control sits above the motor drivers as an option rather than within the drivers its self, it really depends how you partition the application and what the priorities of the system might be.

regards
Al