I have been working on the transfer function from control input (-127 to 127) to position and velocity output. The goal is to design a compensator (a controller like PID) to a specific set of design parameters. I have ran into a few problems that maybe others have the answer to.
It was shown here that the duty cycle output of the MC29 connected to port 2 is roughly linearly related to the control input to a floor/ceiling of -84/84. Is there any reason ports 3-9 would be different? Has anyone measured how the duty cycle output related to the control input on ports 1 and 10?
I know that when you set the motor speed there is a delay until the duty cycle changes. I cannot recall what the average value was but I do recall that there was a large range of around 10-100ms depending on what the master/slave processors on the Cortex were doing at the time. I am looking for a way to reduce the standard deviation of motor delay, even at a cost of a higher average delay. Is there any known method by which this could be accomplished?
Has anyone measured the motor parameters on the 393 or 269? Specifically I am interested in the inductance, resistance, torque constant, and back-emf constant. If anyone has measured these across multiple motors, what kind of deviations have you found?
That’s all I have for now, but I am sure I will run into more sometime.
Thanks James.
I thought the information was somewhere in the box of research posts you have made, I just couldn’t to find it. When I get a chance to consolidate all the answers to my questions I will post them here and link back to their respective original posts for future reference.
For number 3, I was looking here and thought of something. If a task were to set the motor speed at 90ms intervals the delay should be constant. It would be unknown between 2 and 33ms, but because 90 is the LCM of 15 and 18, the time until the SPI and PWM update would be the same each time the motor speed is set.
If the delay is constant, one could run a quick loop to time when the nIfiSPIMsgCounts increments like you mentioned here to find this unknown delay? Once added to the 90ms one would then have a constant, known delay.
Am I understanding this correctly? Even so, is this just a nice idea in theory that really wouldn’t work in practice?
Minimize the standard deviation of the delay from when a task executes a set motor command until the corresponding change in the duty cycle at the output of the MC29.
Know what the average duration of this delay is.
Minimize the standard deviation of the time interval between task executions of the set motor command.
Know what the average interval is.
Minimize the sum of this average interval and the average delay.
Sorry for the brevity, I was at work on my mobile. My end goal is to design a compensator for each subsystem of the robot as opposed to semi-blindly tuning PID controllers.
To do this I need to first develop the transfer function from input (the control value in ROBOTC or whatever platform) to output (such as angular velocity, angular position, arm elevation, etc.) There are plenty of resources detailing the transfer function from voltage input on a DC motor to an output of angular velocity and position.
I am having more trouble with the transfer function from control value input to the voltage output of the MC29s. For this, I need to know what the delay is from when the control value is output until the corresponding change in duty cycle at the MC29. I will also need to figure out what the delay is for the sensor input (IME, Encoder, Pot, etc.) but I figure I’ll take this one step at a time. Once I have a complete, continuous transfer function I will need to discretize it. For this I will need to know how often the interval at which the control value is/can change.
The delay may seem insignificant, but if I am trying to design to a set of system parameters (overshoot, time to settle, steady state error, etc.), it can have a major effect depending on the system. I am trying to make as few assumptions as possible.
Luckily, once the transfer function is done, it is really just a matter of plug and play. It is fairly easy to switch between subsystems (drive, lift, flywheel, etc.)
Synchronizing the motor commands to the slave/master spi communication is possible. The problem is that the spi and RC-PWM to the MC29 are asynchronous, I have no idea if they will come up with the same phase every time.
Do you mean that the phase may change over time because the spi or RC-PWM may deviate from their specified periods or that the phase may be random each time the cortex is started? If its the latter and it can be measured then that may work. It’d required an initial measurement at startup and an equation solver, but with the phase being bounded in a range it would be doable.
I meant that the phase may be different each time the cortex is started. Whether they drift over time really depends on how the timebase for each is generated, ie. if a hardware timer is used. Even then they will be running from different oscilators so may still drift. I will set something up perhaps next week and do a few measurements.