It has been a while, the last months I worked on adding motion control to the FPGA.
I ended up starting from scratch. I wanted to move from migen to nmigen and structure the FPGA code better.
A proof of concept is seen in the very rough video below;
Motors are sampled at 1 MHz. The circuit operates at 50 MHz. The system can account for; jerk, acceleration and velocity.
The software consists out of the following elements;
* SPI command interface (receives command and words, copied from Luna)
* Transactionalized FIFO (buffers instruction in sram, copied from luna)
* SPI parser (basically an extension of SPI command interface, with specifics for my
project)
* Dispatcher; picks up commands from the FIFO buffer and dispatches instructions to
actual hardware
* Polynomial integrator: creates pulse train for stepper motors; basically you send the
coefficients for the polynomial and the number of ticks in a segment.
The motor follows the path, coef_0 * t + coef_1 * t^2 + coef_2 * t^3.
The trajectory of a motor is divided in multiple segments where a segment length is typically 10_000 ticks. If is longer, it is repeated. If it is shorter, this is communicated by setting ticks to lower than 10_000. I looked into using bezier curves for motion control. The main advantage is that they are calculated on the circuit straight from actual positions using de Casteljau Algorithm. My FPGA does not have a hardware multiplier, so I didn't implement it.
At the moment, I will focus on adding the possibility for controlling the laser and "finally" do more experiments.
Code is available online, it was quite a lot of work. Especially the boring stuff which "should be easy" took a long time. Thanks go out to Kate Temkin and her work on Luna.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Thanks.. might be an idea for the future.. but it seems a FPGA was not used and no code is shared...
Are you sure? yes | no
Well there is the paper( http://www.roboticsproceedings.org/rss10/p42.pdf ) detailing the algorithms and if I understand it correctly then it's really just calibration and can be applied in software. This thread ( https://discourse.odriverobotics.com/t/anti-cogging-feature/293 ) provides insight on understanding the output of their implementation of the cogging torque mapping algorithm.
Are you sure? yes | no
True they did write a very nice paper... which is probably more insightful than the code... thanks
Are you sure? yes | no
If you are shooting for smooth and accurate movement then you should definitely look into incorporating anti-cogging: https://hackaday.com/2016/02/23/anti-cogging-algorithm-brings-out-the-best-in-your-hobby-brushless-motors/
Are you sure? yes | no