Interfacing daughter boards and break-out boards for Interfacing

Hello Jetson community.

I am new to using Jetson’s for development but I thought I would ask. If this question has already been answered please direct me to the previous thread and we’ll call it done. But I searched and haven’t found anything particular about this. Maybe because it is just so dang obvious?

Here’s what I am wanting to know==> Since the Jetson has great communications what form of “break-out” boards or interfacing daughter boards are used for motor control and to interface with other peripheral sensors like LIDAR etc?

Is it most popular to use the CAN capabilities of the board and then just send those commands to a “daughter board” that translates the CAN signals into the appropriate analog output signals for the appropriate device? Is it just preferable to use the GPIO pins for various tasks? Are there boards to break out the GPIO header into terminals or other interfacing that makes wiring and development a lot easier?

What is the recommended method of interfacing with other 3rd party equipment? Hoping the answers are straightforward and not convoluted - I really would like to use Commercially available hardware that I can integrate with the controller to do what I need rather than develop a solution from scratch.

Ideas??

Brian

The Jetson has CAN, SPI, I2C, UART, and USB interfaces, all of which can be used.
I’m using UART and USB, and am planning to move some of the usage to CAN for more robustness.
However, you should use whatever controllers you feel are most appropriate to your application.

Start by selecting the actuators/sensors you need, by price/weight/performance/etc.
Then, figure out what interface those actuators and sensors need.
Then, use the appropriate bus to talk to the devices from the Jetson.

For example, you could choose Dynamixel MX-64-T servos, and a USB USB2AX interface to talk to them.
Or you could choose RoboClaw motor controllers, and a UART to talk to them.
Or you could choose Animatics CAN stepper motors/controllers, and talk CAN to them.
Or whatever else – you should start with what you need to actually do, rather than with what the Jetson happens to have interfaces for.

Snarky,

Thank you for your guidance. So essentially I am doing this backwards. Your suggestion is to find the hardware first and then figure out what I will need to interface with that and then go ahead and locate the interfacing components for that set of specific hardware?

Turns out the hardware was already chosen by the other team members so I have to find a way to interface a Telemechanique LXM05ad14N4 “Inverter” motor drive to the Jetson. From what I am seeing - the motors seem to be AC motors and this “Inverter” (That is what they call it) acts to amplify and also control the phase of the AC current to the motors.

So now that I have a specific set of hardware - I suppose I had better find a way to interface with it. Looks like there are just screw-type terminals into the motor “inverter” which I am assuming i will have to supply with a reference voltage to command a certain speed/torque??

Any ideas on how to proceed? Or maybe I should tell them we should spec out new motors! LOL

Thank you Snarky for your help to date.

respectfully,

Brian

Snarky,

I found that this particular motor “controller/amplifier” will accept data in the form of the following==> ModBUS or CANOpen. So with that specific bit of inormation… I think I’m looking at using the CAN system on the TX2 correct?

Brian

There are two stages of electronics before the motor:

  • The controller. This might do something as simple as output a complementary PWM signal at some particular duty cycle, or something much more complex based on various sensor inputs. This is a hard-real-time piece of electronics, although it almost always contains a MCU of some sort.
  • The driver. This turns the output of the controller into high-power currents for the motor.

Old engineers call the power stage “amplifier” because before MOSFETs, you had to use BJTs to control the currents (like in a class A stereo amplifier.) The amplifier generated quite a bit of heat at that time.

These days, with super-fast MOSFETs that are just on or off (PWM style) we call them “drivers” so you can appear all modern and suave by making sure you use that word :-)

The “inverter” is another different thing altogether – it’s traditionally something that takes DC, and turns it into AC, and thus would go before the actual “driver” bit. However, my belief is that the “driver” and “inverter” circuitry are often joined into one single unit, and whether you call it “driver” or “controllable inverter” probably depends on oral tradition within your particular company.

The question then, which is what you’re getting at, is “how do I tell this inverter what to do?”
Analog control signals are something I haven’t seen for a long time myself, except in some older electric wheelchairs. But I’m sure some people use them still. They’re annoying because it’s actually hard to generate precision analog control (you need a DAC) and it’s hard to send precision analog signals long distances (because of interference) and it’s hard to decode on the receiving end (you need an ADC.)

The Schneider controllers also claim to support CANopen, Modbus, and Profibus. You should ask whether they have (or can get) the version that supports CANopen; that will be easier to talk to than something analog.

If you really have to use analog, then you’d need to hook up a DAC of some sort to generate that signal. That DAC needs to be able to drive whatever voltage level they want for input, at whatever current the input requires. Perhaps you can get away with something simple like a microcontroller with built-in 12-bit DACs, and perhaps an opamp that re-buffers the signal if you need more current than the few milliamps that the MCU can output.

Try this: http://amzn.to/2vCWfWx
It’s a programmable microcontroller, and it has a built-in 12-bit DAC. You can download the tools to program it from the PJRC website. Unfortunately the tools install into the terrible Arduino IDE, but the software and hardware itself is solid (I’ve used it in the past successfully.)
Then, you write a small piece of software on the MCU, that simply does “read something from the USB port, and if there’s a command there, set the DAC output voltage to match.” Over, and over, and over again :-)
On the Jetson, you plug in this board using USB, and write software that opens the USB port (as a serial port) and writes commands to the microcontroller to set the output voltage to whatever you need.

But, really, tell your engineers to get with the 2000s and get a CAN capable controller/driver.

Ha, I was writing this while you responded. Yes, CAN is great. You’ll need a simple CAN transciever for the Jetson, and the latest (28.1 / Jetpack 3.1) kernel, OR build and install the CAN drivers for Jetpack 3.0 manually. Then use SocketCAN to talk to it.

Btw: When I googled that controller, I saw that it had an “end of life / not for new designs” notice. If you already have one, and that’s all you need, then great. If you’re planning on making more things, well, just sayin’ it’s not going to be around forever.

Snarky,

You are a wealth of information my friend and yes - you are correct - my vernacular may NOT be up to date at times (especially when I get tired) but I am tracking with you perfectly!!

It turns out that YOU are correct! ==> The telemechanique drives 1.) Are older models that were chosen because due to the power they can produce - but I am thinking they may need to be replaced due to their lack of being able to properly (easily??) interface with them! The one thing they do provide is a LOT of power in a very small NEMA frame! Each one of these little motors can supply 1.4 kW of power - but maybe that is unrealistic in a mobile robot?? I’m not sure I can get a mobile power supply (battery or whatever) to supply 5.6 kW of power while my robot is on the move!!! So a suggestion of changing the motors may in fact have to be strongly considered

2.) You are also correct that these drives that the motors need do in fact “convert” the DC analog signals (+/- 10 VDC) to AC output signals to the motors. This is problematic as you have pointed out since you are absolutely correct I will definitely need both a DAC and an ADC to be able to use the motors with the Jetson! To complicate matters the encoders on these motors are +5VDC - so that necessitates the ADC card interface as well.

Lastly 3.) You are (again) correct - the CANbus on these drives can NOT be used for communication of commanded signals or feedback since these things are so OLD and the CAN system is NOT real-time to be able to keep up with the controller.

So, I am at a very interesting decision point - do I just scrap the motors and start form scratch? Or is there a GOOD DAC/ADC boards that I can communicate with from the Jetson that will allow me to scale the signals for OUTPUT and INPUT to be able to use these motors?

What do you recommend? Are there better motors out there that use RT CAN type comms that would allow the power we’re talking about here? Do you have any DAC or ADC recommendations for the Jetson or do you suggest the microcontroller you pointed out above to do both?

Thanks for the help (sorry for the book!!)

Brian

There are tons of small drivers that can run high power. 1.4 kW isn’t particularly much.
Have a look here for controllers that have a number of input mechanisms, are not particularly big, and can go to many kilwatts of power:

Yes, they control BLDC motors instead of synchronous AC motors, but unless you have a really swell deal on SAC motors, BLDC is just as good IMO.

A number of LiPo cells in parallel can supply 6 kW of power.
This battery pack is intended for hobby use, but would give you a reasonable idea:

“6S” means 4.2V max charge voltage, 3.2V max discharge voltage, 3.7V rated voltage. So, 6x3.7 = 22 Volts nominal.
65C means 65 times that “Ah” rating in instantaneous discharge in A. 5 Ah rating * 65C means 325 A. (Note that the XT90 connector is only rated for 90A long term, so that should be burst.)
So, 325A times 22V equals 7 kW surge rating. Or more like 90A * 22V for 1.8 kW for more sustained (not overheating the connectors and such.) It’s only going to run like that for a few minutes (5 Ah / 110 Wh,) though, so you’d want several such packs in parallel. And, if you want higher voltage, a couple of them in series, too.
You can obviously build your own battery packs out of 25650 cells or similar. Or buy bigger packs pre-made from industrial suppliers. I’ve used All-Battery, in Fremont, if you’re not in California you’re almost certainly better of with some other supplier.

I sadly know very little about motion control analog adapters; all my analog experience is pretty much audio based, which is +/- 1V. I’d look for something from TI or Analog Devices and splat it on a circuit board and talk to it through whatever bus the chip wants (SPI or perhaps I2C most probably.) I bet you can purchase analog adapters to digital busses in ruggedized industrial casing, but I have no idea where you’d find such a thing :-(

The Teensy 3.2 has a DAC that’s probably good enough (very fast, 12 bit resolution) and two ADCs that can read the feedback signal (you’d need a simple re-buffer or resistor divider to adapt to its 3V input.)
You could totally use the Jetson to talk to the Teensy to talk analog to the controller, and read analog back. The Teensy DAC may be 1.2V or so, in which case you’d need a simple op-amp circuit to bring it up to the 5V or 12V or whatever swing is needed for the control. If you just need one right now, breadboard it; else design a simple adapter circuit board and bring out the soldering iron :-)

Anyway, the Rototeq controllers are good hardware. If that’s an option, make sure to check them out!
How does a 500A, 60V rating sound? https://roboteq.com/index.php/component/virtuemart/371/rgbl1860-detail?Itemid=971 is rated up to 18 kW continuous duty.
Or half that power rating (9 kW) for half the cost: https://roboteq.com/index.php/component/virtuemart/390/hbl1696-256-detail?Itemid=971

Snarky,

Good to hear that 1.4kW isn’t all that much! I appreciate the ideas on the Roboteq and we will definitely be exploring what these motors can deliver as opposed to what we currently have with the telemechanique systems.

Good thoughts on the LiPo cells too! Yes, the amount of power on a mobile application will definitely have to deliver if we’re consuming that much power for the application.

Snarky, regarding the encoders and the reference voltages and the ADC/DAC issue… I was thinking about having those particular tasks handled by a Teensy as you recommended or even an Arduino. Sound doable? I figure I could have the Jetson communicate with the slave processor (Teensy or Arduino) via USB 2.0 or other (I2C or SPI) and just have that processor perform all the DAC/ADC tasks. Does this sound doable to you? I figure both those microprocessors are adequate to count encoder pulses etc (Arduino is at 5VDC TTL so it is ready to go) and for the output reference voltage (+/-10VDC) I could just get a simple linear output motor control shield or what have you to generate the scaled signal for the Telemechanique drives.

Regarding the 18kW continuous duty motor power - I think that should do nicely and like you said would probably be a heck of a lot more easier to control than our present situation!

Yes, that’s what I would recommend if you’re just building one system!

I like the Teensy more than the Arduino because it’s faster, and has better resolution (12 usable bits instead of 9 or 10 on the Arduino.) Also the Teensy has more SPI and I2C and UART and even CAN interfaces available than the Arduino, which is useful if you talk to more than one motor/servo/controller.

I’ve built several robots with Teensy, and sometimes large numbers of degrees of freedom. It’s great at “talking to things,” and then if you need more smarts than the microcontroller can give you, use something like a Jetson, or a NUC, or a Raspberry Pi or whatever for the smarts.

Good luck on your project!

Thanks for all the help Snarky. good points about the Teensy rather than the Arduino. I agree, using the Jetson as the overall controller and then parsing out low-level distributive control tasks to "smaller’ processors makes total sense to me. Thank you and I will pursue your advice.

Brian