Servers by jDrones

CANbus for Ardupilot with UAVCAN and UC4H


(OlliW42) #91

yes, I indeed did

but:
the F103T8 I’m using in the nodes only has two UARTs. Thus, when you use the UartBridge firmware you’re offered only two uart channels, as this is also the number offered by e.g. a Gen.Purpose board.

the bluepill offers 3, and doing 3 would be a piece of cake, I can do up to 5 easily for e.g.a F103RC. But I concluded - and I think you said this yourself before - that the bluepill isn’t really what one wants to use extensively on our copters. One could however of course easily design a node pcb with a 103CB…

but:
there is IMHO also a conceptional issue. If the idea is to use that as a sort of uart expander to equip the FC with more uarts, then using CAN and UAVCAN especially would in my opinion be nonsense (even though it’s possible). I could not imagine a UAVCAN node which could need more than two UARTs (I can’t even imagine one which would need two …)… so I actually wonder if what you call “avoidance node” is in fact a node in any proper CAN/UAVCAN sense.


(OlliW42) #92

WS2182B:
the signal for it is on TIM2_CH3 or pin PA2
so you connect the WS’s gnd to gnd, it’s signal-in to PA2, and it’s vcc to … well … this depends now on your powering scheme and number of LEDs. If you connect just one LED it wouldn’t suck much current and you could connect it to the CANbus’ 5V.

it should then work out of the box with ArduPilot, since ArduPilot also used LedlightId = 0. Maybe there is some setting in AP’s Notify parameter section which I’m forgetting now however.


(mike kelly) #93

Couldn’t you use the second UAVCAN bus to double the total available bandwidth? Placing some devices on the second bus to reduce the impact to other devices on the main bus?


(OlliW42) #94

absolutely
it IMHO could actually be a very recommendable setup to have the “critical” components on one bus and the “non-critical” ones on the other
I’m not sure if my implementation(s) in BetaCopter would support that however out of the box, I have never ventured into this (my modded AUAVX and the pixracer just have one CAN bus), but exploiting two CAN ports is definitely on my list


(OlliW42) #95

@ppoirier
Patrick , as regards the QMC magnetometer, I just got mine, and the modded firmware worked for me out of the box … both MagneticSensorType = 0 and 2 just worked … (and the scaling appears to be at least not obviously wrong)
???


(ppoirier) #96

Yep just tested during lunch , it work OK, must have been " a momentary lapse of reason"
Will test the WS2182 later today

Thanks


Copter-3.6.5-rc1 available for beta testing!
(OlliW42) #97

Yep just tested during lunch , it work OK

great. many THX. So it remains to check that range and orientation are correct.

just for the sake of fun I did a uartbridge firmware for you with 3 uarts. I haven’t really tested it much, but maybe it just works.
uc4h-uartbridge-v008-4ppoirier.zip (27.5 KB)


(ppoirier) #98

Lol , I just finished a blog … using 2 uarts … Please read and comment:


(Rick James) #99

@olliw42 what about adding the rm3100 mag support to the node? I use that one and it’s pretty amazing! That would be incredible to have.

Love this! Finally it’s getting some serious traction. You’re a genius and kind for contributing all this!


(ppoirier) #100

@jpkh what happened to my blog ?!?


(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