Instead of using Rpi we are using intel based SBC, the idea to is to drop the Rpi and interface the Magni motor controller board directly to the SBC. Since UART is the only communication interface b/w the Rpi and motor controller we use FTDI USB-UART and interfaced with the motor controller. On SBC we ran the motor node which used to run on the Rpi. Ideally this should work out-of-the-box but, the motor node is reporting “Firmware not reporting its version”, I don’t see a valid reason of this to happen. I will be looking closely about this issue tomorrow. Just to confirm, do we require any additional settings for the serial port to communicate with the motor controller ?
A couple of points.
-
We do have an FTDI port on the robot and this can be used however we usually recommend connecting your computer to the ethernet of the raspberry pi - as it saves this kind of headache.
-
What headaches are you talking about? Well the most likely problem is that you’ve not set the baud rate correctly and as such there is no communication happening between you and the motor controller. You also have minor headaches relating to building the code on the new computer, interfacing sonars, getting a new camera, etc.
You can work through all these of course - but in general you only wind up saving yourself a $35 computer and it usually isn’t worth it.
We are not using our main application on Rpi and moreover there are issues with a system where Rpi is connected over ethernet to other system. Our goal is to avoid using Rpi and move the control logic to SBC, where the control is centralized. We are not using camera and SONARs are an option. Since the motor controller code used on Rpi is a ROS node, compiling for other boards should be trival. The baud rate settings were taken care in the motor node code and the configuration yaml file is updated accordingly to the serial port used. I can able to communicate with the motor controller board with one of your python test script. The ROS node still fails with firmware version issues.
Regarding the onboard FTDI chip on motor controller, please share some more info on the same.
When you boot the ROS node - it should give the firmware version as an information message on startup of the node. For this to happen the motor node is told to get going, and then it sends it firmware version number. If it doesn’t that implies that communication to the motor controller is problematic. Which python test script are you talking about and what communication did you achieve? Did you achieve full loopback? e.g did you confirm communication both to and from the motor controller. sometimes the motor controller can accept commands, from the main computer but not send them successfully.
As you’ve probably already figured out the serial port on the board is designed so you can plug your FTDI device in it directly to make for a cleaner setup.
When you boot the ROS node - it should give the firmware version as an information message on startup of the node. For this to happen the motor node is told to get going, and then it sends it firmware version number. If it doesn’t that implies that communication to the motor controller is problematic.
Agreed.
Which python test script are you talking about and what communication did you achieve?
ubiquity_motor/scripts/test_motor_board.py
Did you achieve full loopback? e.g did you confirm communication both to and from the motor controller.
No, the communication is to motor controller.
sometimes the motor controller can accept commands, from the main computer but not send them successfully.
Interesting, what would be the reason for this behavior? This sounds like exact behavior I observe on my setup. I can see the message which is requesting the firmware version by the motor_node on start(tested by looping the UART), but there are no firmware related messages replied from the motor controller, It sends other info related to the current sense etc.
As you’ve probably already figured out the serial port on the board is designed so you can plug your FTDI device in it directly to make for a cleaner setup.
Strangely the FTDI USB-UART doesn’t work nicely, I have CP210X USB-UART handy, just plugged it in and the motor_node worked nicely with out any issues. Could be some serial driver or buffer issues, yet to look closely.
Typically you fail to get full loop back (e.g. the motor controller receives commands from the computer, but the computer doesn’t receive commands from the motor controller) in 2 scenarios:
- You haven’t done the voltage levels on your UART correctly - e.g. you are using 3.3V when you should be using 5V
- The baud rate is not correctly set up.
For various reasons the motor controller is often very tolerant of screw ups in the UART set up and it will accept data even though the setup is a little or even a lot off. However there’s not much that we about the third party systems that are hooked in to it. So for example the UART on the computer sends out something at an incorrect voltage the motor controller accepts it and then tries to send a return message at the correct voltage. However the UART on the computer is expecting an incorrect voltage because that’s the way it was setup so when a correct voltage level is sent it can’t deal with it.
Remember you actually need to set these things up on your USB-serial device in addition to all the other areas on the stack. Another very common cause for failure is that your USB-serial device is not actually from the purported manufacturer (the chinese knock offs are everywhere - and use micro-controllers pretending to be legitimate chips ) and the drivers don’t actually work correctly or only work in a limited range of scenarios.
If you look at the master control board pinout here:
You can see that we designed P508 to fit a FTDI device like this:
If you absolutely must connect directly to the motor controller, we strongly recommend using an original FTDI device from a reputable supplier and FTDI’s excellent drivers. We have learned this lesson from hard experience in connecting a USB-Serial devices that “we had lying around” - and we hope that our customers can avoid our mistakes.
Although again I stress we absolutely don’t recommend doing it that way - again because you wind up spending hours dealing with the very issues we are discussing on this thread.
For various reasons the motor controller is often very tolerant of screw ups in the UART set up and it will accept data even though the setup is a little or even a lot off. However there’s not much that we about the third party systems that are hooked in to it. So for example the UART on the computer sends out something at an incorrect voltage the motor controller accepts it and then tries to send a return message at the correct voltage. However the UART on the computer is expecting an incorrect voltage because that’s the way it was setup so when a correct voltage level is sent it can’t deal with it.
The only system the motor controller supports is the Raspberry Pi ? What I’m trying to change in the default system is the compute unit which is communicating with the motor controller board. The communication interface is a standard UART. I believe the motor controller should work out-of-the-box with any compute unit given the UART connections and configurations are met. This is what I’m trying to achieve. Regarding the baud rate I don’t see any issues in my configuration. Coming to the voltage levels, I’m pretty sure I’m interfacing it correctly. All the signals I interface were TTL 3v3 logic levels. I’m using the Rpi header to interface the external FTDI USB-UART converter. Regarding the P508 header available on-bard, the signals are 5V and it doesn’t matter which port of UART I use to communicate with the motor controller, I mean via the Rpi header or via the P508(FTDI in 5V mode).
Let me add some thoughts for serial control of the motor controller board. There are a few cases.
-
If you DO NOT have a Raspberry Pi connected to P701 then you may use a 3.3V set of serial lines from your own 3.3V uart such as a CP210X style serial port plugged into your laptop or whatever. To do this you will also have to supply 3.3V to pin 1 of the tall P701 jack in place of the Raspberry Pi. In this case the transmit of your device goes to pin 2 of P507 which normally goes to pin 4 of the RasPi. You then need to plug in your receive input to your uart to pin 1 of P507 which normally goes to pin 5 of the RasPi. You do need to connect ground lead from your uart and I suggest you could plug that into pin 1 of P508 (the FDDI jack) since P507 has no ground pin.
-
To directly use ONLY P508 FDDI jack properly with the Raspberry Pi plugged in OR NOT you will have to remove surface mount resistors R510 and R509. This will allow the FDDI jack to have exclusive connection to our onboard motor controller board processor 5 Volt level serial lines. The serial port at this point of the FDDI jack is a 5 volt set of signals and they are clearly labeled near the jack but are labeled relative to the functions of our processor. So to clarify fully, the Rx pin on the FDDI jack pin 5 goes to the transmit of your 5V uart. FDDI jack pin 4 is our transmit that goes to your FDDI receive interface.
When the motor controller is running there is a constant stream of status data always appearing at the receive input to your uart OR you may have lines crossed. 1st level debug is just look for constant 38.4kbaud data streaming out of our transmit line into your receive line. The data will be present on pin 1 of the two pin P507 at 3.3V and will be on pin 4 of the FDDI jack on it’s TX pin as 5V serial.
It is this constant flow of data from our motor controller that can lead to much confusion in trying to query the motor controller board for things like the firmware version. It is best for your software to be listening and then just after a status packet comes in THEN send your query and await reply. Whenever you send your query and listen for a reply you should receive packets, only look at them if checksum is ok, and then only look for the answer in the reply packet that has the correct message type in it or else it is some status reply. It is ‘tricky’ but I do it all the time.
I should mention that my own test script I use to bring up boards is a python script that I plug in the serial usb from an external RasPi to jack P507 and then I set the serial port in the script to /dev/ttyUSB0. Read the start of the script and notice it is very basic but works well.
I suspect this will help you greatly but is far from any sort of real control logic you would need to run the motor controler well. Treat this simply as an example to pull little pieces from to gain insight. This script is not guaranteed in any way and is a gesture of good faith to help persons such as your team get started.
Guys, I think we are over complicating this support question.
@bhuvanchandradv some clarifying questions:
You are connecting to P508 with 5V signaling, and the Raspberry Pi pins with 3.3V signaling right?
How did you hook up the CP201X to make it work? Did you confirm that you were connecting the same way (wiring and voltage) with the FTDI adapter?
Did you make sure to change the serial port configuration for the robot?
Rohan
You are connecting to P508 with 5V signaling, and the Raspberry Pi pins with 3.3V signaling right?
Yes.
How did you hook up the CP201X to make it work? Did you confirm that you were connecting the same way (wiring and voltage) with the FTDI adapter?
The connections were similar for both CP210X and FTDI I used.
Did you make sure to change the serial port configuration for the robot?
Yes, I changed the serial port configuration.
I used this script to test my connections and communication to the motor controller were proper and it worked fine. I was able to control the motor speeds. But when I use run the motor_node the motor controller is not responding to the firmware version request.
Hello @mjstn2011 @rohbotics @davecrawley
Seems like I found the issue. After doing continuity tests on the board for the RX and TX lines and using probe_robot test code. There are logic level translators on board U1 and U2. For the TX pin on the Rpi side it need a reference voltage of 3v3, which need to be fed externally, since I only use RX, TX and GND pins(assumed that the 3v3 is fed on board) to interface the motor controller. On hooking to scope the voltage level on the TX line is pretty bad (found it to be ~1v2). After feeding external 3v3 ref, everything works fine with both FTDI and CP210x.
NOTE: Tested this on v5.0 boards, since the CP210x also doesn’t work nicely on the TX line(Rpi) aka RX line(Motor Controller).
One thing still I’m confused with is:
On v4.9 board the CP210x with RX, TX and GND lines worked perfectly without any issues and it doesn’t work on v5.0 board unless 3v3 is fed externally.
I am sorry I did not tell you about having to supply 3.3V in that mode to power the translators. I do this all the time even today. I power my 3.3V using the 3.3V line on my CP210x board by the way but forgot to tell you about that.
Don’t you mean it used to work on a rev 4.7 board but now on rev 4.9 it needs the +3.3V? That would make more sense to me as rev 4.7 used different level shifters. The Rev 5.0 board is just coming off of our production run only a day ago. The actual board revision is etched on the top layer of copper near the edge of the board.
Its v4.9 board, which used to work. We got the new v5.0 boards yesterday at our office.
Ok. I know David sent a few rev 5.0 boards and I had just gotten one myself. I know of one customer who got a couple rev 5.0 boards but did not connect the dots to realize you were with that customer. Can you tell me if both of the large resistors in the far lower right corner of the board say ‘R005’ or only one of them says ‘R005’ please. I do not want to disturb David tonight, Christmas, as he deserves a break for working very very hard in the production house in China to get some of the fresh production run boards and some units ready for customers who have urgent needs. He really deserves this time with his family.
To be honest guys - at the start of this thread we gave a couple of recommended approaches to address your needs. We were fairly clear that if you didn’t follow the recommended approach you’d encounter problems. This perspective is based on a fair degree of experience with these systems - and indeed experience in what others have found easy to do. We make these recommendations with good reasons and with a perspective of balancing cost and engineering time. We aren’t saying that other approaches can not work - we are saying that these are not things we generally support - and are not worth it. It seems that you didn’t heed our advice and have encountered problems exactly as we said you would - and have burned up an enormous number of engineering cycles both for your team and mine - please take a step back look at the situation and go back to what we recommend.
@davecrawley Raspberry Pi is under-powered for our project and system with multiple compute units(Rpi and intel SBC) had more issues and we don’t see any value of sticking with Rpi to save cost or the engineering time in our requirement. So what we approached is not so complex and we still save cost and time. We could have agreed with all your recommendations if Rpi is fit for our project, which unfortunately is not. Thanks! for your valuable time and I’m sorry if you feel we wasted your team’s time. IMHO the magni robot is not the end product to use as-is, which would need system level changes in projects which are complex, I would like to work with a system which is easy to customizable and/or scalable.
We encourage people to use additional computers if they feel that they need the additional compute. Indeed we provide power infrastructure for NUC, Tegra and many many other secondary compute boards. The beauty of ROS is that topics are designed to be shared between multiple computers. This is how it is intended to be used and how we suggest others use it.
Please do email me personally at dc@ubiquityrobotics.com with the issues that you are facing through lack of customizability as we will be sure to incorporate that thinking in future robots. Our next generation design indeed will have multiple sizes and payload capacities and increasing the extensibility of the platform is something we always strive for.