Servers by jDrones

CANbus for Ardupilot with UAVCAN and UC4H


(mike kelly) #101

It is really odd because I commented on your blog and it is not in my list of topics I have replied to either.


(ppoirier) #102

Yes, Randy made a correction and seems that when I approved , it has been trashed… they are working on it.


(James Pattison) #103

It’s back (at least for me) - someone else might check though.


(mike kelly) #104

Link works for me now too.


(ppoirier) #105

@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 ?


(OlliW42) #106

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


(Rick James) #107

@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.


(OlliW42) #108

this would be so
but if you think about it that’s how CAN is desgined


(OlliW42) #109

@ppoirier
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 :wink: ): 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 :slight_smile: )


(ppoirier) #110

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