I’ve just got my first lidar scanner (and A2M12), and overall it seems great, but I’d love to be able to get higher sampling rates from it, I’m trying to detect people, but can only put it at about 15cm high, so I get ankles, which works fine for close to the sensor, but further away the points get quite sparse which makes it trickier. Looking through the documents it looks like you need to send some bytes to do it, but also there is the todo: implement ExpressScan receiver note, is there a schedule for that being done, presumably its trickier than the notes make it seem?
i’m afraid i remember indeed that implementing ExpressScan was not a simple thing. we can certainly offer that if needed, but there is otherwise no plan currently.
I’m going to leave some notes here for anyone else using these Lidars. I’ve just tested
(Slamtec RPLIDAR A2 A3 S1 S2 S3 Lidar Front-end Ports Screen Interaction Ethernet Module Ethernet Extend Stable Adapter Plate - AliExpress)
As an ethernet adapter for an A12, it works in slamtecs robostudio, so next thing to try is @antokhio udp version of the library. And I do wonder whether using that might mean the extended nodes are available by sending the correct UDP commands.
Touchdesigner users were having disconnections after a while with usb, but also ethernet means longer distances between your sensor and your pc…
see also Observable UDP Socket - #9 by joreg
Lastly to get the ethernet adapter working use this [Setup Software]USR-M0 V2.2.3.286.exe-PUSR IOT to configure IP etc. default login/pass to the web config is admin
More notes as I try them…
The problem with express scan, that underlying lib does not have anything to work with it. I think I managed to make it work, but the quality of data was far of useable due to incorrect parsing or miss of some configuration params… This PR is still on my list, and I hope to get back to it when I have at list few empty days…
Seem like the adapter doesn’t like @antokhio 's UDP version, but it works with touchdesigner via TCP Slamtec RPLidar support | Derivative
So for my current project I might have to use TD at least for the tracking, as it also supports higher precision, or try and patch my own TCP version…
@catweasel this sounds like a classic situation for what we can offer priority support. if interested, please get in touch via devvvvs@vvvv.org and we can give you a quote.
I would, but the budget for the project doesn’t allow for that unfortunately.
So it turns out the thing I couldn’t get to work was getting the motor spinning, but all/most other commands work fine, it also turns out that you can run the motor via PWM, or simple feed it 5v as 100% pwm, sending express scan returns data… Next step work out how to parse the data, which as antokhio has mentioned maybe weird.
It comes from the TCP node as mutable array segments, how do I wrangle that into a mutable array, also, it would be really useful to see (and input) hex codes as we get from mousing over an iobox, is there anyway to do that?
Extended mode has a 2 byte header then a fixed length, so I guess tokeniser will give me a start, how do I then get all 132 bytes of a packet?
In fact, it looks like I need to split out bytes to bits…
eek
Dirty hacky patch attached!
TCP.vl (63.3 KB)
more dirty hacking and some random points, but I’m guessing, not enough, and not right :D
And interestingly, using my manual motor control, Antokhio’s udp version works, but again with similar data to my TCP version, this is just just the standard scan command. I may be better spending time learning TD I think
From working with S3, the pseudo pipeline is something like this:
You send command
Lidar responses with command response packet
Lidar responses with data packet
So the key here there that on you receiver you need to handle the state of lidar, e.g. some commands would have direct response some commands would not have response, in some cases after certain packet you start to recive data, in simeple scan data has one format, in express scan there is at list two different formats, also before doing express scan you need to send config manually.
To handle different receivers it’s better to use observables where.
To make it work better with c# the proper way is to cast byte arrays to structs, you can kinda check how the underlying lib does that RPLidar4Net/src/Api at master · aberteau/RPLidar4Net · GitHub
I suggest u check the S3 patch from that pr
TouchLIDAR.zip (16.4 KB)
I’m going to drop this here as a temporary solution, Touchdesigner getting data from 2 lidars, and sending via spout to a receiver patch in vvvv, I tried to just do it with udp, but I’m guess hardly anyone uses udp in touch. I find it a very odd software, I’ve no idea how it has become so popular, except that it is US based, although I’m sure it has its own strengths, I just haven’t found them, although I have seen some lovely work made in it.


