/**
* Calculate the current RPM of the motor. This is a signed value and the sign
* depends on the direction the motor is rotating in. Note that this value has
* to be divided by half the number of motor poles.
*
* @return
* The RPM value.
*/
float mcpwm_get_rpm(void) {
if (conf->motor_type == MOTOR_TYPE_DC) {
return m_pll_speed / ((2.0 * M_PI) / 60.0);
} else {
return direction ? rpm_now : -rpm_now;
}
}
For FOC:
/**
* Calculate the current RPM of the motor. This is a signed value and the sign
* depends on the direction the motor is rotating in. Note that this value has
* to be divided by half the number of motor poles.
*
* @return
* The RPM value.
*/
float mcpwm_foc_get_rpm(void) {
return motor_now()->m_motor_state.speed_rad_s / ((2.0 * M_PI) / 60.0);
// return motor_now()->m_speed_est_fast / ((2.0 * M_PI) / 60.0);
}
You’re referring to these right?
Keep in mind that not every motor has hall sensors. (If it’s hall sensors that you’re taking about)
mc_interface_get_rpm() uses either mcpwm_foc_get_rpm() or mcpwm_get_rpm(void) depending on the motor type being used (With the former being used for FOC and the latter being used for everything else I believe).
The methods above are the calculations being returned every time you use the mc_interface_get_rpm()
I don’t think I’ve posted on this thread yet. But on the old forum I’d talked about this concept and I finally got around to making a video explaining it properly.
Geared the video towards a more general audience, so a lot of it isn’t anything new here, but still wanted to share.
The biggest problem I see with this version of endless ride is the fact that if you’re not on the board, its a powered land torpedo, meaning a remote is absolutely mandatory.
Interesting that its using motor feedback to detect braking. But if the motor takes over the braking, how can it tell when you’re no longer footbraking? Seems to me as though there’s not really active braking happening and you’re going to either have to rely on the remote or footbraking to stop.
The last small issue is, how can it tell if you’re speeding up because you’re pushing or if you’re just going downhill? If it doesn’t have active braking, and its going to speed up maintain speed when going downhill, it seems like this really is a flatland feature pretty exclusively, which is fine.
They could also have an IMU and be checking for inclination. If it’s accelerating, and the board is pointed downward, then it’s probably because hill. Likewise, maybe if roll is slowing but nose is pointed upward, it needs throttle to tackle hill instead of brake to assist footbraking?
Just my thoughts. In theory this would be really hard probably because of bumps and vibrations, you’d need some heavy filtering which could reduce responsiveness and possibly add an annoying delay.
Best way would still be to have pressure / load sensors detecting when you’re actually on your board, if no consistent weight is detected the board slows down to stop
Agreed, tho it could be doable : it doesn’t need to be on the deck, even a small cell somewhere on the baseplate or the hanger or even on top of the battery rail/enclosure would work to failsafe the board
