NVIDIA's press release states that "Jetson TX1 is the first embedded computer designed to process deep neural networks -- computer software that can learn to recognize objects or interpret information." The 3.4x2inch module includes a Tegra X1 ARM Cortex-A57 processor with 256-core NVIDIA Maxwell graphics, 4GB of LPDDR4 memory, 16GB of eMMC storage, 802.11ac WiFi and Bluetooth, and Gigabit Ethernet support.
AnandTech Article: http://www.anandtech.com/show/9779/nvidia-announces-jetson-tx1-tegra-x1-module-development-kit
The Jetson TX1 Development Kit will be available for preorder starting Nov. 12 for $599 in the United States. The kit includes the Jetson TX1 module, a carrier board (pictured below), and a 5MP camera. The stand-alone module will be available in early 2016 (for $299 in bulk).
The Jetson TK1 (not TX1) was released in 2014 to encourage the development of products based on the Tegra K1 processor. However, according to AnandTech, developers were using the Jetson TK1 outright as a production board, choosing to focus on peripheral and software development instead of system hardware development. With the new TX1, all of the I/O connectivity is provided on a carrier board, enabling rapid development on the credit-card sized TX1 module. After development is finished, the TX1 module can be directly deployed in products, such as drones.
NVIDIA used a drone application to promote the Jetson TX1
Comments
LOL ....
Jurgens, here we go again...everything but the kitchen sink!!
Guys, the TX1 is a ''frankensteiner-number-cruncher-monster'' , forget about integrating second generation microcontrolers gizmos, leave it to a dedicated companion autopilot (line a PixRacer), and get the TX1 to work on real major leagues stuff, like SLAM, Deep Learning ,Multi-Camera Stitching and navigation.... :-)
Jurgen wouldnt it be better to have ardupilot run on the tx1 and use a stm32 for PX4IO as navio2/raspilot/erlebrain2 does? it would allow pwm at different frequencies etc and allow the tx1 to take care of the grunt processing.
@Jurgen
On the J120 product page there is a title "J120 super-mini-computer with Jetson TX1" but on the Indiegogo campaign all the options are without the TX1 module.
Will you offer the J120 together with the TX1 module in future (and approx when)? Or will I have to look for the TX1 module elsewhere (any tips?).
Thanks, the bundle would be very cool!
Hi Randy,
I am happy to send you and Tridge one. There are 2 possible setups however:
1. the traditional one would use the TX1 together with the J100 carrier and a 38184 motherboard. On the motherboard a STM32F4 based flight controller board may be plugged. The Ardupilot would run on the STM32F4. This and the TX1 could communicate via dual CAN (connected up via the motherboard).
2. the new setup would be to run the Ardupilot right on the TX1. For this application there is the J120. It is designed to operate standalone. An MPU9250 (IMU) is integrated and connected right to the SPI0 bus of the TX1. Other sensors and peripherals would be connected up via CAN. For ESCs either the ESC32 or an standard ESC with CAN to PWM or I2C converter could be used. Alternatively I could strip out the STM32F103 portion of the flight controller and turn this into a CAN to multiple PWM out module. Last an SPI/I2C to PWM converter could be used.
What do you think about running Ardupilot on a non realtime OS on the TX1? I would think that the flight controller performance could be compromised. Also the stability of the system. I got told that the TX1 integrates an extra low speed ARM processor (in addition to the four A57 cores). This could run another separate Linux which could potentially behave much more predictable, if it runs just the flight controller task. Are you aware of this extra core?
Regards, Jurgen
Well, a TX1 based flight controller would really be something. Send one to Tridge and I and I think we would get Ardupilot going on it pretty quickly. We already have our TX1 boards BTW.
Hi Alex,
do not worry. You can definitely use standard PWM type ESCs with the Jetson TX1. You are not forced to use CAN ESCs. It is just that I would recommend them. But let's have a look at the alternatives. As the TX1 does not have any PWM outputs I would propose to use the TX1 in combination with a standard flight controller like the Pixhawk.
1. you use standard PWM ESCs and have them controlled by the Pixhawk. The TX1 could communicate with the Pixhawk via a UART connection. With my J100 or J120 is is easy, as I have integrated the voltage level converters. So a direct cable connection would work. For software please have a look at: https://github.com/diydrones/companion/tree/master/Nvidia_JTK1/Ubuntu
2. to improve the connection between the TX1 and Pixhawk, you could use the CAN bus. With the J100 and J120 both would support it hardware wise. I have integrated an SPI to CAN controller (Microchip MCP2515). This chip has native Linux drivers, but application layer software would need to be developed.
3. it would be nice to have a data return channel from the ESCs to the flight controller. Some ESCs provide an I2C interface. Some have tried to connect the ESCs via I2C to get the rpm reading back into the flight controller. However I would not recommend to run the I2C bus over long cable connections. This is going to create data integrity issues. One alternative would be to use a CAN to I2C converter (like my 38160) and place this right next to the ESC, to reduce the cable length of the I2C bus as much as possible.
4. another alternative would be to connect PWM ESCs to the TX1 with the use of a CAN to PWM converter. One of the Autoquad developers already implemented this code in the 38160. So next it needs to be implemented in the TX1. This is planned.
Regards, Jurgen
HI tonyvr,
I recently renamed the "Jetson Pi" to the J110. After I have send off the J110 to PCB board making I have discovered some minor issues in the design of the J110. I have decided to quickly do the J120 to correct these issues and to make 2 changes/additions:
As I stated above, I do not think that using I2C for external devices is a good idea. I have heard too many people complained that they have seen many I2C data errors when they did that. I would encourage to use CAN instead. I have designed a little module (38160) which bridges from CAN to I2C. This module could then be placed next to the I2C device, to keep the length of the I2C bus as short as possible.
Regards, Jurgen
Hi Alex,
we have now added the MPU-9250 to our carrier boards - the J100 and the J120. The MS5611 I would put onto the CAN bus. We have architected a concept of using the TX1 as the flight controller in a CAN centric architecture.
To create a very robust system, I would propose to not use the SPI and I2C busses to connect to external devices. These busses have been designed for routing on a printed circuit board. They are not meant to be routed across wired connections. This is what CAN is for. CAN allows for error free communication in very harsh environments like in an UAV where pulsed high current is distributed. This is why I would propose to just use CAN to interface to sensors and peripherals. The only CAN ESC shipping today is the ESC32 by Autoquad. The Autoquad team is looking at porting the driver to the TX1 so that the TX1 can control multiple ESC32s.
Another advantage of using CAN for the ESCs is that there is a data return channel from the ESCs to the TX1. So the TX1 receives accurate rpm reading of all motors. This makes flight stabilization more stable and more responsive.
Is there any gpio ports available on the tx1? would be nice to be able to run arducopter on the board directly. Seeing as how you already have headers for spi ports it would be easy to connect a mpu9250 breakout board and a ms5611 as well. the big heat sink is the only issue. would be great to have an aluminum case that would act as part of the chassis of a quadcopter to hold/cool this thing.