I think there might be an issue with F405 cpu and UAVCAN, i have been testing and trying to make it work. I can see all the correct messages in UAVCAN_gui all working well. Then when i go back to mission planner i get this message
PreArm: UC: Failed to add Node 127! So i thought i would test the setup and try a pixracer which works with no issues and no changes to the node.
Also Sparky 2 has a can port which i connect to
PB13 CAN2_TX CAN2 / PB12 CAN2_RX CAN2 i can't get that to show the correct parameters in MP.
I don't like reporting bugs with ardupilot that don't work as i have been bitten before (myfault), but i do think there is an issue.
What is my best approach if I want to integrate a pixhawk running ardupilot into a CANBUS vehicle system in which all of the ECUs only know the SAE j1939 protocol? Should I just write custom translation code from UAVCAN to j1939 and add it to the ardupilot software that I have running?
google says that SAEj1939 - this is typically used in automotive, so is your vehicle a car or truck or tractor? irrespective of that, without more information about what you are trying to achieve, we can only guess wildly. perhaps you have an aircraft where the ECU of the engine is using SAEj1939... or perhaps you have an aircraft with a propulsive electric DC motor controller that is using that protocol ( like maybe https://www.axiomatic.com/TDAX100050.pdf ), or maybe you are flying a multirotor with a bunch of these sorts of thing..... however it is, the answer will be different depending on what you are doing, and how much u absolutely have to integrate it.
In working on prototype projects in the past, I have put arbitrary CAN devices on the same bus. I am doing an ArduPilot-based project now, and am uncertain how to support a CAN bus with heterogeneous nodes that don't support UAVCAN. It seems to me that there should be a mode of the ArduPilot CAN code that allows different message handlers to register for receive traffic distinguished by source-id or some other field. Does anyone see value in having a configurable mode in AP's CAN code that provides such a mux/demux layer for CAN?
@davidbuzz I work on an R&D team for my company. We have a generic track-driven robot platform (think like the size of a riding lawnmower) that uses hydraulic traction motors. The traction motors are driven by a CAN controller operating with J1939 and specific CAN messages for throttle and steering. That's about as much as I can disclose of the specific application
@sethjones348 - regarding your SAEj1939 hardware, it seems to me that if you have an existing bus, with a 'master' controller of some sort on it that is able to address all the other devices using 1939, ie a complete end-to-end system, like as found in a typical car, then given it/s essentially CAN at the hardware layer, it would be quite possible to add ardupilot hardware to this existing bus (Pixhawk2 or Cube etc has dual CAN hardware, so that's also a bonus), and in theory 'capture' first then write a software extension to be able to read (listen to existing bus devices communicating) and/or maybe write enough of a subset of command/s to send instructions/s to these devices..... however i'd suggest that unless your manufacturer documents the specific bits and bytes of every packet in your bus(rare but happens), it'll be reverse-engineering and a lot of guess-work. However, if you don't have a 'master' and the ardupilot hardware is going to be the 'master', then it will be nearly impossible without documentation from the endpoint/s manufacturer (and still include guess work).
... but that's just my opinion.... its entirely possible that your vehicle only has 1 type of hardware, and it only has 1 or 2 command packets (eg turn left X degrees, or turn right X, or turn at X speed for X ms ), and you could maybe best-case use the same basic command with all three motors (left track motor, right track motor , throttle position 'motor') and just different IDs on the network... who knows.
One way to configure it would be to introduce a new value of CAN_Dx_PROTOCOL to indicate generic CAN. The generic CAN Mux would then have arbitrary clients which would have their config (or be hardcoded) and would register with the CAN Mux at run-time, specifying source-ids of interest. The generic can mux's loop would dispatch frames to clients according those source IDs, and call periodically into the clients' transmit routines. In this model, UAVCAN co-existence is not possible.
Another way to do it would be to have UAVCAN "host" the generic CAN Mux in its loop, which is not what I was thinking of, but now seems like a cool idea. Is this where "multi-frame" packets might be misinterpreted? I'm not familiar with multiframe, all the CAN protocols I've worked with have had single-frame messages. Before trying the UAVCAN-generic-CAN coexistence idea, I would have to dispel my UAVCAN ignorance, I only just started learning about it.
Is there any desire to have a simple CAN output whereby the user chooses a CAN ID to start at and then each of the Servo/ESC signals are output as two bytes. Thus for each 8 byte CAN frame there could be a maximum of 4 Servos/ESCs per message. So with a maximum of 16 servos there would be a maximum of 4 CAN frames. This would allow far easier integration than complicated UAVCAN/ToshibaCAN/KDECAN.
Hi! Ive been doing some testing with uavcan to output to vesc. It is working fine, except that the motor spins as soon as I connect the vesc to the pixhawk and pixhawk not even armed(throttle on zero, but should make no difference). I Ive search through most of the documentation, but cant find what parameter to adjust.
anyone who can tell me which parameter to adjust?
anyone used CANBUS or UAVCAN under SITL? i saw a pr for it from the GSoC 2018 , but it doesn't seem to ahve been merged. ArduPilot/ardupilot#8509 thoughts ?
I seem to be having issues enabling the parameter CAN_P1_DEBUG ( https://ardupilot.org/copter/docs/parameters.html#can-p1-debug-level-of-debug-for-can-devices ) ... as it doesn't seem to exist in any binary I tried. such as copter4.0.4 or copter 'latest' as of 5 minutes ago.... is there something I need to do to unhide this param, or compile my own version..?
mavproxy "param show *CAN*" doesn't show even though the other CAN params are showing
I'm experiencing some issues with SLCAN on CubeOrange. When on the full carrier board, I can successfully discover an mRo F303 node when connected to the CAN 2 port, but not when connected to CAN 1. On the mini carrier board, I can't discover it connected to CAN 2. However, I have successfully set it up with a MS4525D0 airspeed sensor and that works in all cases
Same result with UAVCAN Gui Tool
I'm using the latest ArduPlane beta
question about CAN_P1_DRIVER Vs CAN_P2_DRIVER that the documentation doesn't make clear... in the case where the two physical ports are both on UAVCAN, but on different CAN bus's, should it be CAN_P2_DRIVER=1 or CAN_P2_DRIVER=2 ? https://ardupilot.org/copter/docs/common-canbus-setup-advanced.html#common-canbus-setup-advanced
it seems most people set both of them to '1' and most also want both can ports 'on the same bus', but i'm not 'most'.
I am running arduplane 4.0.5 and trying to use UAVCAN with a vesc 6 plus. when I set the output for channel it just spins up to maximum and isnt responding to the throttle. (It worked on an earlier ardupilot version, but that version didnt seem to have uavcan telemetry support)
was something changed within the UAVCAN protocol which wasnt updated on vesc?
@davidbuzz I apologize for the delayed response but I am appreciative of the time you took to address my situation. My focus will be more on this project for the next couple of months than it has been. Our system is more like the complete end-to-end system you described, with a "master" controller that addresses other devices using j1939. We also do have access to documentation for the specific bits and bytes of every packet in the bus. With this in mind, we will likely attempt to add the pixhawk to the existing bus. Would the "capturing" described and the software logic to read and write commands/instructions be implemented in its own "AP_J1939" library in the codebase? Thanks!
we could add that if there is need for it