Hi guys,
@JorgeMaker has recently published hes work on a great and very useful user interface for the simplefoc:
https://community.simplefoc.com/t/simplefoc-gui-configuration-tool/460/20
With this in mind I would like to discuss the communication interface for the simplefoc library and what should it be in future. Not so much in terms of technology as in terms of architecture.
At the moment the motors are configurable using motor commands, and all the code is hard-coded into the FOCMotor.cpp
class. For one of the next releases the whole communication will be separated from monitoring and moved to the new class completely. Which will be more flexible and make swaping in between communication types simpler.
I know there is many of you interested in CAN at this point, but I am still interested into the serial and taking the full potential out of it.
That being said there are few problems with motor commands:
- Supports only one motor at a time
- Uses the same serial as for monitoring
- Cannot simply be extended or modified
So what I would like to have is something like this. I would like to have a class communicator which will have a list of nodes that it needs to/can communicate with their ids. Those nodes could be motors, scalars or PID and LPF classes and similar. Something like:
BLDCMotor motor = BLDCMotor(...);
communicator.addNode(&motor, 'M1');
Or PID and LPF classes:
PIDController some_pid = PIDController{...};
communicator.addNode(&some_pid , 'P1');
LowPassFilter some_lpf = LowPassFilter{...};
communicator.addNode(&some_pid , 'F1');
Or just a scalar value:
float variable = 10.00;
communicator.addNode(&variable , 'V1');
And that the user is able by sending the command to the mcu, for example ?
, to get the list of nodes addached:
?
Attached nodes:
M1: motor
M2: motor
P1: pid
F1: lpf
V1: scalar
And once you have it the user can send/request something similar to the motor commands for each single one of those nodes, by first specifying the id and then the command and value. Something like
M1#P1.00
PID velocity | P: 1.00
M2:I
PID velocity | I:10
But you could also set and configure one PID and LPF which is not in the motor directly. This would make it easier to make some mechatronics projects such as balancing robots and similar.
Also you could add a down-sampling rate as one of your nodes
something like:
int configurable_cnt;
int downsample_cnt = 100;
void setup(){
.....
communicator.addNode( &downsample_cnt, 'DSC');
.....
}
void loop(){
motor.loopFOC();
if(downsample_cnt++ > configurable_cnt){
motor.move();
}
// communication stuff
communicator.communicate()
}
And then you can configure it using serial:
DSC:
value: 100
DSC:200
value: 200
I am really interested to hear what you guys think. I am actually pretty happy with this concept. A generic communication interface in the shape of nodes. It would add a lot of flexibility to the part of fine-tuning of the library.
Also, I think the awesome interface @JorgeMaker has made could be extended to support these kinds of communication protocols for easier visualization.