W.A.L.T.E.R. 2.0 and the Teensy 3.1

Status
Not open for further replies.
If it works we can try to get Nathan (Basic Micro/Orion Robotics) to do so.

I thought I would hack up a version that does not use their version of software serial. Had to add new function to their Roboclaw class to do a timeout read. ... Mostly it compiles now, but having an issue at link time:

Code:
c:/program files (x86)/arduino/hardware/tools/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-signalr.o): In function `_kill_r':
signalr.c:(.text+0x14): undefined reference to `_kill'
c:/program files (x86)/arduino/hardware/tools/arm-none-eabi/bin/../lib/gcc/arm-none-eabi/4.7.2/../../../../arm-none-eabi/lib/thumb2\libc.a(lib_a-signalr.o): In function `_getpid_r':
signalr.c:(.text+0x28): undefined reference to `_getpid'
collect2.exe: error: ld returned 1 exit status
Have not tried to track that down yet, maybe already known, but have to run. Will look at it when I get back.
Kurt
 
Any word if the mods I posted on reply #20 actually work? I don't have the real hardware here for testing, but at least that code compiles and I believe it follows the original programmer's intentions.
I just got setup to test these, and am verifying my connections. I am having difficulty with the console and RoboClaw ports for some reason. The SSC-32 is working with the BMSerial port, so I will get the other two sorted out.

If it does work, maybe we can get the Basic Micro folks to merge the changes back to their official version?
Yes, this would be the ideal result.

8-Dale
 
Last edited:
Ok, I updated the VA-ARG the same way and got it to compile. I used one of the Roboclaw examples, and then hooked up the Teensy to my Saleae LA and it looks like Software Serial is generating proper output for the baud rate of 38400. If I get a chance will try to hook up a Rover with Roboclaw to see if it is working. Not sure what Input a wish to use to run the rover. Could try PS2 (play station 2 controller) or XBee... Will see.

Kurt
 
I am having problems getting anything from the RoboClaw 2x5. My code just hangs when I go to read the controller.

I am checking to make sure I have communication on Serial3 now. I'll move the SSC-32 (works on Serial2, RX 9, TX 10, just fine) over to the RoboClaw port (Serial3, RX 7, TX 8), and see what I get. I also am not getting anything out the console port (RX 0, TX 1), which I have an FTDI cable connected to.

8-Dale
 
FYI, I tried hooking up my LA and was not getting anything... So tried simple sketch
Code:
void setup() {
    Serial2.begin(38400);
}

void loop() {
  Serial2.println("This is a test");
  delay(250);
}
Nothing is showing up. When I change 2 to 3, output is coming out properly on the right pin. So appears to be issue with Serial2 object

Kurt
 
FYI, I tried hooking up my LA and was not getting anything... So tried simple sketch
Code:
void setup() {
    Serial2.begin(38400);
}

void loop() {
  Serial2.println("This is a test");
  delay(250);
}
Nothing is showing up. When I change 2 to 3, output is coming out properly on the right pin. So appears to be issue with Serial2 object

Kurt
I have communication on Serial2 (9, 10, 115200, normal SSC-32) and Seria3 (7, 8, 115200, normal RoboClaw), but nothing on Serial (0, 1, Console).

I tested by moving my SSC-32 to each port and reprogramming the Teensy 3.1. All this is set in my header file, so it's very easy to switch ports. Then I just have to switch the physical serial connection.

8-Dale
 
Last edited:
What version of the IDE are you running? I am currently on the RC4 (todays). Not sure if that would make any difference, but...
 
Not sure what happened, but all three ports work for me now... Will check now with SoftwareSerial...
 
I am having problems getting anything from the RoboClaw 2x5. My code just hangs when I go to read the controller.

I am checking to make sure I have communication on Serial3 now. I'll move the SSC-32 (works on Serial2, RX 9, TX 10, just fine) over to the RoboClaw port (Serial3, RX 7, TX 8), and see what I get. I also am not getting anything out the console port (RX 0, TX 1), which I have an FTDI cable connected to.
8-Dale

Just FYI - if you are using the i2c_t3 lib (or a derivative of it), make sure the interrupt flag defines are commented out (see this link). When I uploaded that I forgot to comment those lines so it will generate crap on pins 8/9, which might interfere with other things on those pins.
 
Just FYI - if you are using the i2c_t3 lib (or a derivative of it), make sure the interrupt flag defines are commented out (see this link). When I uploaded that I forgot to comment those lines so it will generate crap on pins 8/9, which might interfere with other things on those pins.
I am using the standard Wire library.

8-Dale
 
Hi Dale,
I think I am having some more luck with my version just using the SoftwareSerial... Got wheels to move some on my Rover, but batteries are pretty dead so need to charge.
Also program probably has some issues.

I included my updated version of the Roboclaw library if you want to give it a try. The nice thing is you can also try using on non hardware serial port pins, like example 2, 3

Kurt
 

Attachments

  • Roboclaw using SoftwareSerial.zip
    4.4 KB · Views: 136
Hi again Dale,

There are still some bugs in my quick and dirty rover program, but I am able to use an Arbotix (Xbee) controller on my board, and have a Roboclaw connected
RoboClaw RClaw(7,8, 1000);

And I am able to get the wheels to go round and round :)
 
Just FYI - if you are using the i2c_t3 lib (or a derivative of it), make sure the interrupt flag defines are commented out (see this link). When I uploaded that I forgot to comment those lines so it will generate crap on pins 8/9, which might interfere with other things on those pins.
I am using the standard Wire library.

8-Dale
 
I'm thinking about going back to my known good environment (Arduino Mega ADK), where everything works, except the RoboClaw (because it is new to me, and I don't yet know how to work it.). I think I need to get it working there and write some code to manipulate it. After I am familiar with how the RoboClaw controller works and acts, I can move everything back over to the Teensy 3.1 and move on from there.

I think that trying to use a device (RoboClaw motor controller) I've never used before on a new platform (Teensy 3.1) is not a good way to test things. This will also allow me to sync up my code for the Teensy 3.1 with my code for the Arduino Mega ADK. Right now, the most current code is that for the Teensy 3.1, but it should pretty much just plug in and go with the Arduino Mega ADK. Wiring sensors and such to the Teensy 3.1 is a bit of a pain using jumper wires.

All I have really done is add a few routines, and rearrange code. Unfortunately, I don't have the hardware to run both platforms in parallel.

8-Dale
 
Hi Dale,

I totally understand. As for how I would deal with some of this is to try to simple test case, to make it so I can talk to the hardware and then build up from there. My first Arduino Rover code for the rover only used some real simple code to control it. The Arduino library did not exist yet, so my whole code to talk to the hardware, to make sure I have it hooked up right and can make it work:
Updated not to use streaming:
Code:
void PACKETS_OneArg(byte bCmd, byte bArg) {
    byte bCRC = (PACKETS_ADDRESS + bCmd + bArg) & 0x7f;    // calculate the checksum 
    PacketSerial.write(PACKETS_ADDRESS);
    PacketSerial.write(bCmd);
    PacketSerial.write(bArg);
    PacketSerial.write(bCRC);
}

inline void PACKETS_DriveForwardM1(byte bVal) {
    PACKETS_OneArg(0, bVal);
}

inline void PACKETS_DriveBackwardsM1(byte bVal) {
    PACKETS_OneArg(1, bVal);
}

inline void PACKETS_DriveForwardM2(byte bVal) {
    PACKETS_OneArg(4, bVal);
}

inline void PACKETS_DriveBackwardsM2(byte bVal) {
    PACKETS_OneArg(5, bVal);
}
With something like this, you can do something as simple as:
#define PacketSerial Serial2
Serial2.begin(38400);

In some simple app, simply do some simple stuff like every half second, tell the servos to move forward at half speed (128). Not sure which version of the Roboclaw 5 you have? I have the ones with dip-switches to configure. So I needed to double check things like Packet Serial, ID, baud rate. I think the new ones have buttons to press to change things. Also helps to have test stuff in cases like this. The Logic Analyzer has helped me out so many times now. Before I had one (and or the old cheap Parallax Oscilloscope device). I would use another CPU with simple program to help out. Example, not sure if you are getting any output on some of these IO pins. Connect those IO pins up to an Arduino. Write a real simple sketch, that reads the state of the IO pin and echoes it on the LED. Then when you run your program you should hopefully see some outputs going to the LED, if not try other IO pins... If that works, have simple sketch that tries to read the serial input that is generated and echo it out to the USB (either as raw data or hex values...) I have gone this route before!
 
I totally understand. As for how I would deal with some of this is to try to simple test case, to make it so I can talk to the hardware and then build up from there. My first Arduino Rover code for the rover only used some real simple code to control it.
This makes perfect sense. I normally always do this when I get a new piece of hardware, a new sensor, etc. I guess I've been so anxious and excited wanting to see W.A.L.T.E.R. 2.0 (after about 7 years of building up parts and such) that I just didn't even think about it.

In some simple app, simply do some simple stuff like every half second, tell the servos to move forward at half speed (128). Not sure which version of the Roboclaw 5 you have? I have the ones with dip-switches to configure. So I needed to double check things like Packet Serial, ID, baud rate. I think the new ones have buttons to press to change things. Also helps to have test stuff in cases like this.
I have the newer one, with the three configuration buttons. It's really easy to setup!

The Logic Analyzer has helped me out so many times now. Before I had one (and or the old cheap Parallax Oscilloscope device). I would use another CPU with simple program to help out. Example, not sure if you are getting any output on some of these IO pins. Connect those IO pins up to an Arduino. Write a real simple sketch, that reads the state of the IO pin and echoes it on the LED. Then when you run your program you should hopefully see some outputs going to the LED, if not try other IO pins...
I'm real good at using LEDs and the Serial Monitor for debugging! :) One of those logic analyzers you just got is on my want list, as well as a good quality DMM (my current broke down). I have plenty of other MPU boards here now, plus I have my Raspberry Pi which I use for testing new circuits, especially I2C, because I can see what is actually connected to the bus.

If that works, have simple sketch that tries to read the serial input that is generated and echo it out to the USB (either as raw data or hex values...) I have gone this route before!
Do you mean capture the input from the RoboClaw and process it after a command is sent?

There are a bunch of example sketches in the RoboClaw examples folder, but there isn't anything that actually *does* anything with it, like a simple rover sketch. I think they need to add something like this. It would not have to be very complex, like you said.

I've synced my Navigation sketch code and header file from the Teensy 3.1 version to the Arduino Mega ADK version now. It was just mainly updating libraries and changing a couple routine names for the RoboClaw.

My wiring for the Teensy 3.1 is a rats nest of jumper wires! It doesn't have nice headers to attach things too. Things keep coming disconnected, no matter how careful I am! I need to just pull everything off it and either completely rewire it, or just move things back to the Arduino Mega ADK for more testing.

8-Dale
 
Is there any final opinion on the port of these 2 libraries, either my edits or the SoftwareSerial based one?
I am not sure yet what the best way to go is.

Personally I prefer with simple solution of using the standard SoftwareSerial class, such that in theory it will work with different platforms. It should then also work with both Hardware or Software.

But the rub is on their own Robots. They have their own Arduino 328 based board. They also use their own version of Playstation 2 controller that uses a serial protocol at 38400 on one IO pin. They do their own version of half duplex, which he added to BMSerial. So for this device probably need their library and you can not have both libraries in your sketch as they both want to define ISR handlers for every possible interrupt... So if we go with BMSerial, probably still won't work for their PS2. I might try this out soon. May have to either update their serial to act like your version of SoftwareSerial and/or add tables for the different CPU speeds.

Actually personally, I would probably prefer to update RoboClaw class some more. Instead of being derived from SoftwareSerial or BMSerial, have it be derived from Stream. Then on either it's constructor or Init/Begin function, pass in a pointer to the actual Stream object (&Serial2 or &MySoftwareSerial or ...). Have everything inherit from default lower class and have low level Read/write functions, which forward to the actual object... This way we don't have to decide... But I am not the owner of this library.

Will try to get Nathan's input on this. As the Roboclaws are one of their biggest sellers, they may be interested in helping out.
Kurt
 
I am not sure yet what the best way to go is.

Personally I prefer with simple solution of using the standard SoftwareSerial class, such that in theory it will work with different platforms. It should then also work with both Hardware or Software.
My preference is the best solution that works on all platforms. If this requires forking the Orion libraries and continuing on from there, that is absolutely OK with me. I want a solution that can be easily expanded to work on other future platforms. I tire of proprietary solutions, even if I do have the source code.

But the rub is on their own Robots. They have their own Arduino 328 based board. They also use their own version of Playstation 2 controller that uses a serial protocol at 38400 on one IO pin. They do their own version of half duplex, which he added to BMSerial. So for this device probably need their library and you can not have both libraries in your sketch as they both want to define ISR handlers for every possible interrupt...
If I want to get an Orion Robotics robot platform, I'll use their hardware and software. Beyond that, I don't have any aversion to forking their code and creating something more cross platform, even if it doesn't work on their robots. Orion has the code that works best here. I have one of Lynxmotion's PS2 wireless controllers here, and I'd like to eventually be able to use that on W.A.L.T.E.R.

So if we go with BMSerial, probably still won't work for their PS2. I might try this out soon. May have to either update their serial to act like your version of SoftwareSerial and/or add tables for the different CPU speeds.
Let's please not worry too much anymore about how things may or may not work on the Orion robots. We need something that works for us, on our chosen platforms. :) Orion has created some great robot platforms, and they have their own hardware and software that works best for those. Ideally, we'd have a solution that encompasses all platforms, including those from Orion - this would be my first preference.

Actually personally, I would probably prefer to update RoboClaw class some more. Instead of being derived from SoftwareSerial or BMSerial, have it be derived from Stream. Then on either it's constructor or Init/Begin function, pass in a pointer to the actual Stream object (&Serial2 or &MySoftwareSerial or ...). Have everything inherit from default lower class and have low level Read/write functions, which forward to the actual object... This way we don't have to decide... But I am not the owner of this library.
I prefer the constructor route for this. We just have to have more than one constructor, which is fine. We might even be able to do what we want to do within the RoboClaw library by overloading functions where necessary for different platforms or using if..#else..#endif blocks, if we must.

Will try to get Nathan's input on this. As the Roboclaws are one of their biggest sellers, they may be interested in helping out.
It would be great if Nathan would be willing to help out on this. It could give him a wider audience for his motor controllers, which would be great for him. We could gain the ability to use his products easier on multiple platforms. That sure looks like a win-win all the way around to me. :)

I bought the RoboClaw 2x5 Motor Controller because it has features (handles motor encoders, etc) way above what I could get by using a Sabertooth 2x5. I was a bit leary with this choice, because I know how Basic Micro/Orion can be when they write software to support their products. I'm very happy to see they have become more open, at least in some areas, and I hope this is a trend that continues.

8-Dale
 
I decided I want to play with the Teensy 3.1 a bit more tonight, before I move everything back over to the Arduino Mega ADK for awhile. I just have to fix all my jumper wire connections - some always come loose, and keep coming loose, everytime I move W.A.L.T.E.R. It's a real pain!

I'll move everything back over to the Mega tomorrow.

8-Dale
 
Dale, I hear what are saying. If I am doing it just for myself, I would simply go with my fork for now and be done with it. But that may not be the best solution if more people wish to use. it.

But as a platform, OS type of guy and one who has many different processor boards, I would like it if works for the most people.

I just had a chat with Nathan, my impression is that he thinks the best solution would be to merge the Teensy SoftwareSerial changes into BMSerial and hopefully not have to touch the RoboClaw code base. Hopefully with the changes for the Bitbang stuff... He was not sure if I could get the performance using the Stream approach. I think I can, so will try. Also I think it could be smaller and faster. It avoids the bottom write function from having to do, am I Serial1 or am I Serial3, else do my own bitbang. Instead you simply do an indirect call.

He did say he would be happy to look over what I/we come up with and we can go from there. The idea for hoping we would not have to fork, is he is adding capabilities to newer versions of the RClaw firmware, which would be added to the library. So if you are forked, you won't get this new stuff unless you merge it in again.

But as for PS2's, their version is sort-of nice as it only takes one IO pin and is smaller as you can see in the picture:
Teensy-and-PS2s.jpg

As I said their version uses serial IO. Output 2 bytes with a bitmask of which fields you want back and it sends them to you. Versus 4 IO pins for standard PS2, doing an SPI protocol.

Got to go
 
Dale, I hear what are saying. If I am doing it just for myself, I would simply go with my fork for now and be done with it. But that may not be the best solution if more people wish to use. it.

But as a platform, OS type of guy and one who has many different processor boards, I would like it if works for the most people.
I agree completely! I would much rather have a solution that works well for as many people and platforms as possible.

I just had a chat with Nathan, my impression is that he thinks the best solution would be to merge the Teensy SoftwareSerial changes into BMSerial and hopefully not have to touch the RoboClaw code base. Hopefully with the changes for the Bitbang stuff... He was not sure if I could get the performance using the Stream approach. I think I can, so will try. Also I think it could be smaller and faster. It avoids the bottom write function from having to do, am I Serial1 or am I Serial3, else do my own bitbang. Instead you simply do an indirect call.

He did say he would be happy to look over what I/we come up with and we can go from there. The idea for hoping we would not have to fork, is he is adding capabilities to newer versions of the RClaw firmware, which would be added to the library. So if you are forked, you won't get this new stuff unless you merge it in again.
Yes, indeed, this is the whole problem with forking code. If all the issues can be dealt with by merging changes into BMSerial, and Nathan can make sure everything is still correct for his platforms, then this is the ideal solution. I'd rather not touch the RoboClaw library if we don't have to, because that's where everything new is going to be, as you've said. :)

OK, time to fix my connections for the Teensy 3.1. :)

8-Dale
 
I give up for tonight. I'm not getting consistant results from my I2C devices, even after I completely rewired the I2C bus connections (6 physical devices). As far as I can tell, all my connections are correct, including power and ground, but I can't really tell for sure. This setup is way to fragile to be reliable.

Tomorrow, I move back to the Arduino Mega ADK.

8-Dale
 
Status
Not open for further replies.
Back
Top