UCANS32K146

cancel
Showing results for 
Search instead for 
Did you mean: 

UCANS32K146

2,000 Views
iaingalloway
NXP Employee
NXP Employee

Please ask questions about UCANS32K146 here.

[aka RDDRONE-UCANS32K146 CANNODE UAVCAN UAVCANNODE UCANS32K]

0 Kudos
12 Replies

1,428 Views
maxe
Contributor II

@iaingalloway @nxf56445 

Just in case you are not aware of this: I tried purchasing the UCANS32K146 over here in Germany and it was nearly impossible. None of the NXP distributors had the product available. I eventually managed to get hold of a kit, but only due to the amazing support of Eva L. (NXP tech support EMEA). It almost felt like NXP generally doesn't want to sell this product.

0 Kudos

1,410 Views
iaingalloway
NXP Employee
NXP Employee

Hello @maxe 
Thank you for your feedback. If you would allow me to explain the unusual situation we find ourselves in , it should be clearer why you currently experienced this issue.

NXP is very serious about and carefully complies with all global trade requirements. All items shipped need to include export control codes that represent the security classification of a product. The previous US administration surprised everyone with a new ruling. Now new circuit boards containing more than one "uncontrolled" security products need to submit for a new classification for the *board* itself. Previously you could use the chip security classification for the board classifications. This is even though the components on board already have classifications and are "uncontrolled" clear to ship worldwide.


As a result of this, there are long delays in getting this new classification code as many other companies find themselves in the same situation. We submitted our paperwork for this board (and similar boards) many months ago, and continue to follow-up to determine when the classification will be issued.
Meanwhile what this means is that boards cannot ship out of the USA without violating the rules. Boards made and warehoused outside the US are unencumbered.

There are several consequences to this new requirement that remain in effect until we get the new classification number back:
- very long delays in getting new classifications for boards

- boards needed to be fabricated and assembled outside the US in order to ship globally

- boards needed to be warehoused outside the US in order to ship globally

- distributors run the risk of accidentally holding/moving stock to a US warehouse that cannot be moved to their other locations globally.

As a result, distributors have not stocked this board yet, and each order needs to be managed manually in an ad-hoc manner. So a distributor will show no stock, but we would fulfill the order and ship to them as the request came in. I appreciate this is less than ideal.

We remain committed to the UCAN board and other new Mobile Robotics boards that may fall under these trade rules. This issue goes away when the new export code for the board is issued by the US government.

I hope this explains the current situation as to why you don't see stock at distribution for the UCAN board. Orders can still be taken by distribution and fulfilled. We will expedite any shipping on our end for these orders. 

 

1,391 Views
maxe
Contributor II

Thanks a lot for this extensive answer. I didn't know any of that.

1,710 Views
nxf56445
NXP Employee
NXP Employee

Hi Maxe,

It seems that gitbook link has been moved to this new url https://nxp.gitbook.io/ucans32k146/px4-autopilot/building-and-flashing-px4 

Furthermore the target name has been renamed from `make nxp_rddrone-uavcan146`, to `make nxp_ucans32k146_default`

We're still developing in the pr-uavcan-v1_bms_minimal branch so for testing please use that branch, we're working together with PX4 to get this into upstream as soon as possible.

1,643 Views
maxe
Contributor II

@nxf56445Just a quick ping, in case you forgot about this

0 Kudos

1,701 Views
maxe
Contributor II

Thank you very much for your answer, @nxf56445 ! This definitely helps.

And yes, I saw that you are actively working on the integration, I saw the PR in PX4's github repo. Hopefully this is gonna be resolved quite soon.

I have another question related to this. As I mentioned I want to control my servos/actuators with the board. Do you provide an example on how to that, too, or is it just the GPS that you provide? If you don't provide an example: What would I have to do to get it running with a servo? Would I "only" have to change the "canard_main.c" file in the uavcannode_gps_demo directory or what else would I have to do? Would you consider it somewhat easy to get this running (I got quite a bit of experience with C++, but not really any experience in the embedded domain....)?

EDIT: I just realized you actually are the guy that was explaining the whole thing in the video. So thanks for the talk! In this case I have another question to you. In the video you mentioning something about DS-015 not yet supporting GPS messages. I can't really find good information on the current state of DS-015, so can you tell me if they now do support GPS messages and even more importantly (for me) do they also support the messages that I would need to control a servo?

0 Kudos

1,628 Views
nxf56445
NXP Employee
NXP Employee

Hi Maxe,

You can control PWM on the UCANS32K146 through the NuttX PWM interface or the PX4 PWM interface.

An example for the PX4 interface is

pwm arm
pwm test -a -p 2000

Regarding the UAVCAN implementation in PX4, it's currently work-in-progress. Currently we're focusing on GPS as you pointed out by the uavcannode_gps_demo application. This application will be converted C++ as well, should be easily extendable to other peripherals such as Servo/ESC and more.

Regarding the protocol spec, there's none currently. Thus for development we use the internal PX4 uORB message structure for example for GPS we use the sensor_gps message (https://github.com/PX4/PX4-Autopilot/blob/master/msg/sensor_gps.msg)

1,614 Views
maxe
Contributor II

I'm not sure if I understand you correctly. So I will try to express my question more precisely:

I want my servos to receive the MAIN flight control signals. I don't want to connect the servos directly by PWM to the FMU, because that would result in a lot of cables (as I have 6 Servos). What I want to do is to connect my servos to the PWM interface of UCANS32K146. Then I want to connect the CAN ports of my Pixhawk FMU to the CAN interface of UCANS32K146. Then I want to change the example code of uavcannode_gps_demo to output the MAIN flight controls as PWM signals to my servo. Does this work?

0 Kudos

1,609 Views
nxf56445
NXP Employee
NXP Employee

Yes, so the UCANS32K146 also runs PX4 software, more specifically the cannode variant not the flight control variant but it shares the same code base, this allows for re-use of code and easier integration into the PX4 platform, so that might be the confusing part.

But yes, you can control a servo from the UCANS32K146 by connecting them to the the "P12 RCM PWM out" port.

To output the MAIN flight controls as PWM signal to your servo, you've to modify both the uavcan_v1 application running on the FMU to expose the MAIN flight control channels over CAN, and modify the uavcannode_gps_demo to parse the data and control the PWM port.

Regarding UAVCAN itself, PX4 is giving a call today about the PX4 UAVCAN v0/v1 roadmap, you might want to join that. https://discuss.px4.io/t/hardware-call-uavcan-jan-26-2021/20575

0 Kudos

1,604 Views
maxe
Contributor II

Thanks a lot for your help and patience. In this case I'm definitely going to order the Dev Kit. Not least because of this great support.

And also thanks a lot for the hint on this call, I was completely unaware of this event even though I knew that UAVCAN v1 is a topic that is currently being discussed. I am curious for this talk and I am going to join it.

0 Kudos

1,408 Views
iaingalloway
NXP Employee
NXP Employee

I'd like to state this for the sake of clarity:

*AT THE MOMENT*
- UAVCANv1 is new and the device protocols are new to PX4

- PWM controls over UAVCANv1 to the UCAN board has not been implemented yet in a "turn key" manner

- The UCAN board itself does support PWM output, and since it also runs PX4 internally the NuttX/PX4 shell command "pwm test -c12 -p1500" can be easily used to demonstrate this.

- More software work is necessary to have an FMU send messages to a remote UCAN board to extend PWM outputs over CAN. It is one of the use cases being planned by the PX4 community overall.

- I will add that you don't *have* to use UAVCAN, and if you have the programming resources could leverage the code provided to quickly create a custom protocol or simple CAN messages. (3rd parties have implemented ARINC standards for example.)

-Check the date of this post. If you are reading this post in the future, this issue may be resolved in PX4 by now.

 

1,724 Views
maxe
Contributor II

I already posted this question to the board. But now I saw, that there's a post here for this purpose, so I decided to post it here, too.

I'm considering to buy a couple of UCANS32K146 to use them as UAVCAN Nodes with PX4. However, before buying them I would like to make sure that everything works as expected and is easy to set up.

I saw this video of Peter van der Perk using the UCANS32K146 with PX4 as a UAVCAN Node for a GPS. The only problem is that the video seems to be completely outdated. I tried following the instructions given in the video and it didn't work at all. I checked out the pr-uavcan-v1_bms_minimal branch and tried building the firmware using `make nxp_rddrone-uavcan146`, but make reports that the build target does not exist. In the video there is also a link to gitbook that - apparently - is supposed to provide details on how to build the software, but the link is broken: https://nxp.gitbook.io/ucans32k146/px-and-uavcan/building-the-px4-firmware. Is there any updated version of that video or gitbook available? Or is there any other ressource that properly explains how to use UCANS32K146 together with PX4?

0 Kudos