Xmos Control and Robotics Development Board

[Folknology]

I'm quite familiar with motor control applications.

Excellent its good to have someone on the team who has prior experience particularly with BLDC and FOC as I'm just a newbie with these ;-)

The Silabs chips come in 25MIPs and 48MIPS. If that isn't fast enough for you to read a 200k sample/sec ADC you are doing something wrong as it only takes 1 instruction to move the ADC register into memory and 1 more to copy it into the SPI bus register.

Sure for single motors that's more than adequate, but when dealing with the number of motors I am going to support on this board it becomes a bit more tricky.

I've found there are only 2 USB controllers with decent drivers: FTDI (d2xx) and Silabs (usbxpress).

I am familiar with the FTDI stuff as its very common, but does the Silabs support Linux and Mac as I need both in addition to Windows of course.

Brushless DC motors require 3 H-bridges (1 per coil) so control is not cheap. Hall effect sensors are usually needed for variable torque as you can't deduce the EMF.

As I mentioned before :

The main design is centred around 12 current sensed half bridges and so could theoretically cope with 12 DC motors , 3 bipolar stepper motors, 4 BDLC motors or combinations there of.

Also BEMF can be detected using cross over detection and averaging to reduce noise effects, infact sensoless BLDC control is now quite common, as are low cost sensorless motors. But obviously having sensors helps a lot ;-)

If you want any kind of resolution you /need/ an optical encoder (preferably with 8000 or more lines per rev).

Obviously with that kind of encoder the job is a lot easier but I am wondering if the combination of hall effect feedback and BEMF detection along with current sensing can get at least some of the way for the obvious cost benefits.

There is also the issue that the XMOS really isn't that fast when compared to a hardware solution. 60k rpm motors are pretty standard and with 8000 line encoders (x4 for quadrature) you need be processing data between 8mhz to 32mhz which you will have a hard time doing without hardware decoders.

Again when considering multiple motors I think the situation changes, I think that the Xmos solution may well shine in such difficult scenarios vs dedicated hardware based solutions. In fact half of the point of this whole project is that the solution is just software!

As regards the Stellaris kits, I agree they are very handy with good software support/libraries etc. .I purchased an LM3S3748-B dev board including screen and USB before TI bought luminary, but haven't used it for a while.

On the display and SDRAM front I have a enhanced design version of this project with up to 8MB of SDRAM and an L2, but that's a fairly specialised design. My goal here with this project is to significantly reduce the cost and make it more flexible, approachable and a general control dev board.

I am interested in non-traditional motor solutions with an XMOS design. Brushless DC motors and optical encoders are pretty expensive when compared to stepper motors even if control is easy. I'd be interested if anyone knew of cheap sources of optical encoders. Lowest price I can find is around $20-25. Nema23 Steppers with 166oz torque can easily be bought for $5 in higher volumes.

Commercial servo motors (brushed dc + encoder) run over $100.

Yes cost is the enemy here, which is why I am trying to reduce requirements like the complex encoders etc..

regards
Al

[kster59]

The only company I know of that has working off the shelf drivers for any other than Windows is FTDI -> another reason to buy a Windows machine.

You could of course program some generic USB device like HID but then your speed is limited.

I don't think there is a standard bulk transfer with universal drivers which means you need to write them all.

All the code is in the Stellaris BLDC reference design. Silabs also has a BLDC design based on sensorless back emf.

Back emf works fine for constant torque (fan). The stellaris reference documentation is excellent and explains why you need more feedback if you have variable torque like in most useful applications where you start/stop a motor constantly for motion control.

Maybe you can get it working but I doubt it is trivial.

Most demos/experiments can be done on an XC-1A with a motherboard attached on all pins which is a good low cost design.

The PCB layout is pretty trivial considering I can pay some expert in India $5/hr to do it. I would concentrate more on the code and demonstrate working principles.

On a less ambitious example, it would be good to get a good brushed DC PWM + encoder PID loop library. Ideally it should just be void Motor(port, target_speed, target_position) and low resource.

I have my own code but only recently did I figure out how to generate optimal PWM timing using buffered ports on an XMOS device. I rewrote the encoder interface also to provide fast timing which is a big step over the encoder example on the XMOS projects. Haven't had time to tune the motors yet but will do so soon.

Automatic software tuning would be nice.

____

On a side note, do you actually have a SDRAM prototype working with the XMOS or just a layout idea? At what speed? That SDRAM driver needs serious overhaul if you ever looked at the code.

I'm working with someone else to produce an L2 with sdram. Careful analysis shows that you take almost all the pins on one core which I guess isn't terrible but the driver code to access the SDRAM also needs to be written.

[Folknology]

The only company I know of that has working off the shelf drivers for any other than Windows is FTDI -> another reason to buy a Windows machine.

You could of course program some generic USB device like HID but then your speed is limited.

I don't think there is a standard bulk transfer with universal drivers which means you need to write them all.

Yup FTDI was my first port of call, however my needs here are modest and I am exploring a completely different idea, as the data transfer in this case is not a priority, it's comparatively low bandwidth which gives me options.

Stop with the "Windows machine thing" already, its wearing thin, I already have two dual boot PC's here with Windows on as well as Macs, I do not need any more goddam PCs ;-)

Code: Select all

All the code is in the Stellaris BLDC reference design. Silabs also has a BLDC design based on sensorless back emf.

Back emf works fine for constant torque (fan). The stellaris reference documentation is excellent and explains why you need more feedback if you have variable torque like in most useful applications where you start/stop a motor constantly for motion control. 

I will take a look at the stellaris examples as I have with the others, they are great for picking up all sorts of tips..

I have an XC-2 and an XK1 which I am using to runs tests and prototypes on, but L1 is my target here rather than G4, so most of it is XK1 based at the moment. I can get some of the way there but not all of the way, unfortunately the pinouts on the XK1 are limited.

The PCB layout is pretty trivial considering I can pay some expert in India $5/hr to do it. I would concentrate more on the code and demonstrate working principles.

For a motor control daughter board you are correct. it can also be expensive component wise so cutting to the chase ASAP is sensible.

On a less ambitious example, it would be good to get a good brushed DC PWM + encoder PID loop library. Ideally it should just be void Motor(port, target_speed, target_position) and low resource.

Agreed, and get it into the community in opensource modules..

I have my own code but only recently did I figure out how to generate optimal PWM timing using buffered ports on an XMOS device. I rewrote the encoder interface also to provide fast timing which is a big step over the encoder example on the XMOS projects. Haven't had time to tune the motors yet but will do so soon.

Automatic software tuning would be nice.

It would be excellent to have and a great contribution to the codebase

On a side note, do you actually have a SDRAM prototype working with the XMOS or just a layout idea? At what speed? That SDRAM driver needs serious overhaul if you ever looked at the code.

I'm working with someone else to produce an L2 with sdram. Careful analysis shows that you take almost all the pins on one core which I guess isn't terrible but the driver code to access the SDRAM also needs to be written.

Yes the SDRAM code sucks as I have pointed out elsewhere in other threads. It also sucks that we have to add SDRAM in this manner. One can add SDRAM in this manner and clean up the code but its always going to suck becuase of the way we have to do it I'm afraid.

I would be unlikely to do it this way and am likely to follow a different path depending on the application, sometimes the suck route is the only option :-( I am still considering my options here and until I have benchmarked some basic stuff I am unlikely to enumerate as its a long shot right now, lots of unfamiliar territory for me.

My first priority is this basic control board, if that pans out I will look at the second issue and a more advanced version., i.e. not run before I walk. In the meantime it might be worth you checking out some of the XOSIG threads (and posts that led to its formation with regard to some of the memory issues/ideas and discussions.

regards
Al

[RogerH]

Hi Al,

I just found this thread and will be following it with much interest.

I have done some simple DC servo motor and stepper controls using Atmel Atmega's and NXP LPC1768. I see the XMOS chips as ideal for this owing to the Multi core and threads which should enable sophisticated realtime control of mulitple motors.

I have created a project proposal on this site for a stepper motor control. The aim there being to build a controller capable of controlling 3 or more steppers and include velocity ramping and position control.


Regards, Roger...

[whterbt]

At Synapticon we're developing a modular platform (hardware & software) for distributed control and data acquisition applications based on XMOS devices. See Somanet range of products on http://www.synapticon.com

The first coreboard is a dual L2 device, called Somanet Core C22: http://www.synapticon.com/?p=326 - A single L2 version, communication boards with X-Link tranceiver, XBee and EtherCAT controller as well as interface boards with USB, ADC and BLDC motor driver will follow soon.

First set of products will be available for you to buy in late Fall 2011. Stay tuned.

[phalt]

Hey whterbt, that looks very interesting.

Please do keep us informed on any work you're doing!

[MaxFlashrom]

You can cover most of your requirements with an onboard MCU like the Silabs 8051F342

I planned a project where I used it with the XMOS.

8x ADC (only 10bit)
USB with real drivers (easy USB)
fast SPI for comm uses only 1 pin off the XMOS device

The silabs chip requires no external parts except a few caps. Internal oscillator.

I put the silabs chip in slave mode and interrupt on an SPI receive.

Commands from the XMOS can request the ADC and USB data.

I'd rather gouge my eyes out than program yet another 8051-based design. I could rant for hours about the deficiencies of its architecture. It was a poor design 30 years ago when it first cursed this planet and it's still a poor design. I've used the best tools for it (Keil's C compiler) which does its very best to make an atrocious architecture usable. The misery of trying to implement re-entrant subroutines and proper resource locking, with a stack that just doesn't work! data, idata, xdata, pdata, SFR/internal RAM memory that changes depending on what addressing mode you use to access it ! Code banking overlays, and fiddling about with port P2 are so last millenium. Then there are the I/O pins which can't make up their mind whether they're inputs or outputs. Not content with being pure open drain/or push-pull they drive hard but only for 2 clocks on outputting a 1 making them useless for almost evrything. It's a HATEFUL load of trash- the weed that just won't die. Give me a modern ARM ARM9/Cortex M3/cortexM0 design any day of the week! They're cheap as chips[pun intented] from the likes of NXP and STM. Texas instruments has MSP430 or Piccolo if you prefer. Hell, I even love PICs if it's a simple assembler job. There is NO excuse to perpetuate the misery.

I feel slightly better now. :)
Max.

[MaxFlashrom]

Just in case you missed it despite XMOS' best advertising efforts, there is, of course for inspiration:

http://www.xmos.com/motorcontrolplatform

Max.

[jbaker]

P.S. The main design is centred around 12 current sensed half bridges and so could theoretically cope with 12 DC motors , 3 bipolar stepper motors, 4 BDLC motors or combinations there of.

Please keep the feedback coming, what else am I missing here, ideas?, Thoughts?

I've been toying with a similar idea. Are you going by the BLDC RDK schematics? I find it odd that they omit R2 and R4 from the typical application circuit in the FAN7382 data sheet. I don't have a lot of experience with this type of driver, so I'm not entirely sure what that does.

[Folknology]

I just noticed this thread got updated and clearly folk are still interested and also working on ideas around Motor control.

Although I still have a plan to make a generic board that supports BLDC, DC and Steppers I haven't yet be able to come up with a satisfactory design. All of my designs so far required a large amount of discrete parts at the power end ramping up BOM and cost. I will continue to research this hybrid design as it would prove very useful for a whole number of uses. In the meantime I decided to design another board aimed particularly at discrete multiple servo control as well as steppers. One of the reasons for switching track temporarily is for particular applications that I am working with at this time. However the design should lend it's self to generic usage for servo,DC and steppers in the 1-3amp range. Luckily I just managed to acquire some samples of a new driver chip which I have been waiting for for some time this will enable me to leverage the power of XS1 in these application markets much more effectively.

By the way I feel less bad about not working on the BLDC side at the moment as Xmos created their own BLDC motor kit in the interim since I started this thread, albeit a little overkill for my own needs!

regards
Al