is gimbal support currently in the works for CAN?
... and is there a document that tells me how to do it..?
... so answering my own question...
connect pc to pixhawk over usb and set these params...
CAN_D1_PROTOCOL：1
CAN_D2_PROTOCOL：1
CAN_P1_DRIVER：1
CAN_P2_DRIVER：1
CAN_SLCAN_TIMOUT：0
CAN_SLCAN_CPORT：1
and then when ready to switch pixhawk into SLCAN mode, try to set this final param.... (which MP reports as failed because mavlink stream over usb is no longer available)
CAN_SLCAN_SERNUM：0
( i pressed 'disconnect' in MP at this point)
At this point, I was able to get 'uavcan_gui_tool' to communicate with it till next reboot as a SLCAN device, and menu 'Tools->Bus Monitor' got me what i was looking for... a canbus monitoring window...
connect pc to pixhawk over usb and set these params...
CAN_D1_PROTOCOL：1
CAN_D2_PROTOCOL：1
CAN_P1_DRIVER：1
CAN_P2_DRIVER：1
CAN_SLCAN_TIMOUT：0
CAN_SLCAN_CPORT：1
and then when ready to switch pixhawk into SLCAN mode, try to set this final param.... (which MP reports as failed because mavlink stream over usb is no longer available)
CAN_SLCAN_SERNUM：0
( i pressed 'disconnect' in MP at this point)
At this point, I was able to get 'uavcan_gui_tool' to communicate with it till next reboot as a SLCAN device, and menu 'Tools->Bus Monitor' got me what i was looking for... a canbus monitoring window...
i guess i can now wire up my can thing to the pixhawk.
first release of stable AP_Periph firmware, 1.0.0
@tridge Will you consider adding uavcan imu in the future?
@tridge I was playing last night with a sparky2 and a stm32Bluepill/can breakout.., I got the two to talk using olli UC4H but can’t seem to get it working on arduCan. After looking at the schematics for mro canNode I see that the only difference in cpu is memory, but not getting any errors using stmCubeProgrammer. Going to try with a pix racer tonight.. any hints that might help?
Hey everyone, hoping someone here might have some insight. I have been working with an stm32f103 blue pill board for development with ap_periph. I have it working pretty well and the new can node firmware is very impressive, but I find that my can node is constantly slipping into maintenance mode randomly, which stops all can comms on the bus. does anyone know by what mechanism maintenance mode is initilized. The only solution seems to be to reset or power cycle the can node and then it goes back into an operational state. It seems random when it goes into maintenance mode.
it basically makes it unusable for flight testing which is a bit annoying...id love to know a little more about maintenance mode(ie what its used for and why I randomly slip into this mode every few minutes). I am trying to implement some custom sensor drivers in the ap_periph firmware and this is a bit of a roadblock for me.
also @ukmook the blue pill works fine. It has 128K ram. Not advertised by stm32, but it is there. U just need to modify the st-flash utility a bit to allow you to load 128k firmwares onto the blue pill. I can provide instructions if youd like.
@JamesMegariotis mine don’t reset to maintenance though
yea I can't figure it out. I couldnt figure out why it constantly stopped communicating, but using uavcan gui, i saw that it keeps going into maintenance mode. Maybe it is an effect of my hacky method for loading 128k firmwares lol. Tested on 2 different blue pill boards with same result. Although i did turn on the debug serial port and associated debug options in the hw_def file. Maybe that is the cause.
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.