Commit 58d2e446 authored by Jake Read's avatar Jake Read
Browse files

command effort, and see axis at work

parent 8a5477b7
......@@ -122,13 +122,25 @@ void Step_CL::run_torque_loop(void){
#define MAP_7p2_TO_1 (1.0F / 7.2F)
#define TICKS_PER_SEC 50000.0F
volatile float _ra;
volatile float _ra_last;
volatile float _ra_s; // real angle / sec
volatile float _pa;
void ENC_AS5047::on_read_complete(uint16_t result){
if(step_cl->is_calibrating) return;
_ra = lut[result * 2]; // the real angle (position 0-360)
_pa = lut[result * 2 + 1]; // the phase angle (0 - 1 in a sweep of 4 steps)
// want to calculate speeds,
// need to calculate speed but in context of wrap'd angle: is there a quick way?
// then test with scope
// then do JS running some loop, maybe 1khz possible? *awk face* send cmd effort down, retrieve datas
// probably just will want to retrieve speed ... then see about sweeping the field to build your table,
// then next step would be real calib against something known ?
_ra_s = (_ra - _ra_last) / TICKS_PER_SEC;
_ra_last = _ra; // upd8 for next tick
// this is the phase angle we want to apply, 90 degs off & wrap't to 1
if(step_cl->get_torque() < 0){
_pa -= 0.25; // 90* phase swop
......@@ -1037,8 +1037,33 @@ OK, so my loop is now more like:
and runs 2.4us. The whole loop is now nicely just around 10us, so I could choke the whole micro and run 100kHz and probably trip up, or I'll try running ~ 75kHz, or I could be satisfied with 50 and leave overhead for the processor to do ... well ... other stuff, haha. I.E I will probably want this headroom for positioning PID, etc. Maybe I should just get it mounted on an axis and proceed with the next steps instead of fiddling with speed before I know it's necessary or warranted.
- consider writing another LUT for RA -> Phase Angle (PA)
- could do in RAM at startup, might crash ur shit tho
- do commands from the browser to jiggy jog
- put on an axis, see how fast it can swing it
- begin the maths, the control, etc... see if you can optimize that loop, high speed is ur friend
\ No newline at end of file
### What Now
So, this is great the LL hardware / control strategy / calibration works. Now starts the real business.
There are two things I want to do, first is use these in machines: that means reliably positioning, rolling a PID (maybe) or some other kind of control loop around the thing, to recieve a 'goto pos' command and execute it. In this case, I just want an entry point into the controller to be that 'pos' field, and have a loop running to control around that.
The second thing is to build this 'real torque / virtual effort' calibration: I suspect I want a 2D Table here so that f(effort, speed) = torque. To do this, I would want to build an interface that let me command various efforts, and read back resulting speeds... to build accelerations, calculate forces, and write that table doing some LERPing.
The second thing is actually, probably, easier than the first: since it doesn't require me to do any control. Later, when I *am* doing control, it will be interesting to try to re-align the two studies, to see if, indeed, the accelerations that happen are the ones I expected.
Since that seems easy, I'll start there. Going to get another motor solder'd up, throw it on that axis, and then tool around in JS and CPP writing down motor-efforts & reading-back speed values. Then I should be able to plot some things, and see about writing a routine that sweeps thru a handful of speeds & efforts to try to build that 2D LERP table...
Shiiiit this is tite. I wonder if I should move the logs to the project repo...
So I am a bit distracted with just tooling around with this thing, but it feels pretty slick and I'm stoked. Videos above. I need to get into the actual control. The first note, though, is that there is certainly some missing control parameter that is like 'phase advance * velocity' - when velocity ticks up, the commanded current should lead a little longer than 90 degs, but probably no more than 180 degs.
So the first move is to build in to the lower level a velocity measurement. For units, since I have real angles, I should do degs/sec as a unit, and this means I'll have to deal with wrapping angles... hopefully I can find a fast way to do that.
## 2020 10 17
What's a reasonable 'end spiral' for this?
- do phase advance parameter,
- do js interface for tc down, degs/sec up, plot on loop
- see about sweeping parameter space, learning real torque
- measure against real values, from, what?
\ No newline at end of file
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment