Making the firmware from scratch with python

Hi all,

I have a makerbot thing-o-matic and I am replacing the arduino with an Odroid-X2. I am writing all the control software in python. I have it moving but I was wondering about the best way to ensure the head is moving in a smooth line as the X and Y motor drivers are on different GPIO pins. Right now I calculate the movement and speed of the motors and create a pulse pattern with delays for each motor. Then I create 2 threads, one for X and one for Y, lock the 2 threads together and run them. From the naked eye it seems to work but I am not sure if that is the best way to do it. Does anyone have any suggestions or heard of a similar project that has published code?

Thanks,
DD

Good luck with that, but I would think trying to put together a real-time application like 3d printer firmware with an interpreted language such as python would be highly problematic. Using c compiled to native machine language exhibits speed/latency issues from time to time. I would think they'd be much more prevalent with python.

Judging by Google, it seems that Python is a popular language and many people are trying motor control with it. How successful that is I don't know. I suspect many people get to the point of "sort of/mostly works" then give up, realising that it really needs needs a kernel mode device driver to get good real-time accuracy and reliability.

I do wonder what the perceived benefits of Python are that warrant discarding something that already works well and re-inventing the wheel. I can see that using a tool more appropriate for a job might result in a better solution, but I can't see why you would choose a less appropriate tool, unless perhaps it is a case of "because it's there".

I think a lot of these python control projects are driven by the availability of cheap platforms like Raspberry Pi, and those owners are now looking for problems to solve, rather than having a problem and looking for the best tool to solve it.

I thought about this as well, after reading the specs of the upcoming Arduinos (Tre, Gallileo, Yun maybe as well).

They all offer a decently fast linux host as well as a AVR. I too expect python to be to slow/unpredictable for the low level real time stuff, but splitting the firmware into two parts, each dedicated to onw of the CPU's, could just hit the sweet spot for both.

The AVR would execute all the real time stuff, like motor drivers, PID controllers etc.
The linux host would run the high level part, like gcode parsing, path planning etc.

The API/ should be along the lines of
- a time interval and the amount of steps for each motor in this interval
- reference value and parameter for PID controller
- GPIO
- lcd and keyboard driver

Taking gcode parsing and path planing out of the AVR, would free up a lot of resources and maybe allow higher pulse rates and faster moves with less jitter, while the high level stuff might be a lot easier to implement on a CPU with decent performance and plenty of memory.

But more importantly the firmware would be easier to maintain, modify and adapt to experimental designs (eg. wally) with less domain specific knowledge compared to today.

Hopefully it could increase user engagement, and that's what this hobby is all about

let me know your thoughts

--
Roland

I think you're right, being able to write in Python opens up some new opportunities, and with a number of new boards out with combined ARM/AVR or similar, it would be worth reviewing the architecture.

One disadvantage of going to a lower level API is that is likely to need higher bandwidth. In your example, "a time interval and the amount of steps for each motor in this interval", you would want to also specify acceleration/deceleration rate. After that is encoded, it will probably take more bytes than the Gcode.

Additionally, if path planning is done on the host side, the AVR needs to have a very predictable response time. In the case of lots of small segments, the transfer rate must always exceed the execution rate, otherwise in the worst case the AVR could run out of work while moving at max speed and be forced to decelerate, causing the host to lose sync.

So the risk is that the host to AVR comms becomes a bottleneck. From what I have seen the interface to the AVR is still a serial interface, which in computing terms is pretty slow.

The host/slave architecture could work, but if I was starting from a blank sheet, I would choose a faster interface like SPI, and a faster slave, e.g. 100MHz Cortex M3. I can see that the AVR was chosen for legacy support reasons, but it's a pretty bad choice for performance. I have a feeling that it would take a lot of effort to make it work with an AVR.

The TI Sitara used on the Beaglebone and Tre has programmable peripheral processors, which allow a more tightly coupled operation with the host CPU, bypassing the AVR entirely. The AVR could still be used for less time critical tasks.

So I think it is a question of finding the right balance, but until someone starts playing with some code we won't know what performance can be achieved.

bobc Wrote:
-------------------------------------------------------
> So the risk is that the host to AVR comms becomes
> a bottleneck. From what I have seen the interface
> to the AVR is still a serial interface, which in
> computing terms is pretty slow.

Some back of an envelop calculation. Let's assume a serial speed fo 115200 baud, that's about 92kBit/s of data.
One segment would be 5 bytes (4 x stepps + interval length), that's about 2300 segments/s, or about 50% headroom if designed for 1000 segments/s.
I think it's safe to ignore acceleration during one segment in the low level part at 1000 segments/s.

If 50% of the AVRs memory (2.5 kBytes) is dedicated to buffering, the buffer would hold 250 segments, or about 1/4 s at the proposed rate.

Edited 1 time(s). Last edit at 10/29/2013 05:29AM by rmie.

rmie Wrote:
-------------------------------------------------------
> bobc Wrote:
> --------------------------------------------------
> -----
> > So the risk is that the host to AVR comms
> becomes
> > a bottleneck. From what I have seen the
> interface
> > to the AVR is still a serial interface, which
> in
> > computing terms is pretty slow.
>
> Some back of an envelop calculation. Let's assume
> a serial speed fo 115200 baud, that's about
> 92kBit/s of data.
> One segment would be 5 bytes (4 x stepps +
> interval length), that's about 2300 segments/s, or
> about 50% headroom if designed for 1000
> segments/s.
> I think it's safe to ignore acceleration during
> one segment in the low level part at 1000
> segments/s.
>
> If 50% of the AVRs memory (2.5 kBytes) is
> dedicated to buffering, the buffer would hold 250
> segments, or about 1/4 s at the proposed rate.

Ok, if you think that will work, go for it!