[Feature Request] 1D Ranging/Data Streaming
MikeGitb opened this issue · comments
This is probably more a firmware issue, so please tell me if I should post this somewhere else.
I was wondering, why it isn't possible to scan when motor speed is zero? Together with a command to turn the head forward it would be a nice feature, if the lidar could also be used as a range finder.
Also, I don't know if this is related, but I think it would be preferable if the head wouldn't automatically start turning after a powercycle.
preferable if the head wouldn't automatically start turning after a powercycle
We used to maintain the 0Hz setting over a power cycle, such that powering on a device that was previously stationary would not yield any movement. Heavy users could then manually set the scanner to idle after running tests or applications and increase the longevity of the slip-ring.
Unfortunately many people got confused when the device failed to move on startup. They thought the device was broken or malfunctioning because they forgot about the motor speed setting. To reduce confusion, we decided to modify the start up routine, such that the device would always spin on startup. The device still preserves motor speed settings 1-10Hz across power cycles. But if it is powered down with a motor speed setting of 0Hz, then on startup the device will default to 5Hz.
This logic is built into the motor control chip which cannot be flashed via a firmware update. If we wanted to change this behavior in the future, we'd have to perform it as part of a startup routine where the device powers on, and the motor speed is set to 0Hz after the device boots up. This isn't ideal and would likely be better suited to a startup routine in user code/a user application. Although it is possible the SDK could do this on device construction, in most cases I think user programs will be adjusting motor speed to a desired setting almost immediately after device construction. I'm open to input here though.
why it isn't possible to scan when motor speed is zero
The data format for 2D scanning relies on constant motor speed and the sync reading. Without constant motor speed, the sweep cannot produce accurate azimuth values. While it is possible to run the LiDAR sensor while the motor is stationary, the data block format would need to change. Even then, the head would still still be limp at 0Hz (free to rotate from physical perturbation). You'd have to physically point it at where you want to get a ranging.
While the device is clearly not designed or suited to 1D rangings, it is possible to implement a new protocol for 1D ranging. We could add:
- New commands for starting/stopping a constant stream of 1D rangings
- New command for a single 1D ranging, or a short burst of rangings
- New response format for 1D ranging
This would be a neat feature that could be added to existing devices via a firmware update, but it isn't high on the priority list.
As for commands to turn the head forward.... any kind of encoding in the absence of constant motor speed would involve finding the sync encoder tick and then performing a large amount of interpolation and trickery to get a rough estimate of orientation. This would require modifying the code on motor control chip which cannot be flashed from a firmware update. So unfortunately these modifications couldn't be part of the standard update for existing devices, or average users.
@dcyoung: Thanks for the explanation.
Regarding the rotation right after power on: This is imho nothing that can be solved by a user application, as the device is usally powered before the user application is started (at least that is my guess). Especially, as it is powered via the usb port itself, I can think of many scenarios, where the sweep is connected to a powered computer but not used right after startup. It is not really a problem just a behavior I didn't expect - so no sweat.
Regarding the 1D ranging: Why not simply returning e.g. a negative value if the angle is unknown?
And yes, I expected that bit about not being able to stop the motor at 0°, but I though it wouldn't hurt to ask ;)
Just one thing: When you say that the startup rotation frequency can't be changed by a firmware update: Why can't the firmware just send the stop command on startup? Or doesn't the firmware have access to a persistent storage?
Why can't the firmware just send the stop command on startup
I'm assuming you mean carrying out the equivalent behavior as if the firmware received a command to adjust motor speed to 0Hz (MS00\n).
As far as I'm aware, the motor control chip boots independently from the main chip. This is why the motor spins up while the device is still booting (led flashing green). On boot, the motor control chip will consider the current motor speed setting and if it is 0Hz, it will change the setting to 5Hz and begin spinning. When the main chip finally boots up, it can only query the motor chip for the current motor speed setting (which now reports 5Hz).
Sending a message to the motor control chip to adjust back to 0Hz, would have to occur once the main chip boots up. By this time, the motor has already started spinning.
@kent-williams feel free to chime in if I'm misinterpreting any of this behavior
Ok, thanks for the explanation.
I'm going to leave this open but rename it as a feature request for 1D ranging.
If I understand correctly, this project is being shut down so I'm closing this issue.