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.
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.
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?
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
@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)
???
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)
@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.
@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 ): 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 )
): 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:
)