It is really odd because I commented on your blog and it is not in my list of topics I have replied to either.
Yes, Randy made a correction and seems that when I approved , it has been trashed… they are working on it.
It’s back (at least for me) - someone else might check though.
Link works for me now too.
@olliw42 about the serial tunneling, as I wrote in my blog, I had issues with the Benewake sending hex code but all OK when using the ascii mode i.e. clear text values terminated with cr/lf.
As I am planning to use the Cheerson Optical Flw, this sensors sends hex code only, I suspect I will experience the same issue. Is this something we could try to fix ?
yes, we can try that
it however certainly has nothing to do with ascii or binary, the code is agnostic to this, and in fact for the gps it switches to ubx and is then binary, so you have seen it already yourself
I rather suspect the timing of how the data is packed into CAN frames. You can have a look at the BetaCopter code, the counterpart works essentially identically
one probably has to carefully look at how the data is streamed, my first guess is that in binary mode it expects a faster response to its packets, or that the library has a stricter timeouting, or that the tf stream is “interrupted” at an unfortunate point which the tf doesn’t like, or such
that’s the general disadvantage of the approach, it is probably not possible to devise on scheme which is kind of “guaranteed” to work for all
when you look at the stream with UAVCAN GUI one probably can see quickly where things go wrong
you, thus, should definitely try the other device. it has nothing to do with ascii vs binary
@olliw42 how does this work for adding a new sensor, for example, the sdp33 airspeed sensor? Do you (personally) have to manually add the driver to the firmware and then compile the hex?
If so, too bad there isn’t a way to use something with external storage and sideload the needed driver in the correct format.
this would be so
but if you think about it that’s how CAN is desgined
I took a look at the tfmini protocol, to see why there might have been issues. I’m going to refer to the standard data format in the following (i.e. what I believe is what you called hex or binary). It is actually really a very short data frame, so this shouldn’t give any problems. However, there might be an issue with a 100 Hz update rate (a rate significantly faster than what I’ve anticipated then I did the tunnel ): The code uses a timeout of 10 ms to decide if some incoming data should be send out, so it could collide in unfortunate ways with the 100 Hz update rate. Two possible solutions:
I don’t yet fully understand the TFMini settings, but it seems to me it’s possible to achieve a data rate lower than 100 Hz. If so, I think this would be a quick first test, to see if the instabilities go away with lower rate.
Second, one could change the code to use e.g. a timeout of 8 ms, or 5 ms, or to actually make it a parameter (this timeout acts as a kind of delay to data streams which have such short data telegrams). If that should be still relevant to you, I’m happy to do the code changes.
What remains a bit unclear to me is why this would happen for the standard but not the clear text Pixhawk format, but such tests probably would show.
(btw, I’ve ordered me a TFmini, I realized that a down-facing distance sensor would be a cool addition to my copter )
Yes , I will test with slower data output period , as is defined in Benewake guide : https://www.robotstore.it/rsdocs/documents/sensore_distanza_TFmini-Lidar_manuale.pdf