I just checked and compared the standard Arduino Mega with the Mega ADK. The pin mappings are the same on them. I2C is in the same place on both boards. 
8-Dale
OK, I am back playing with W.A.L.T.E.R. 2.0 again!
I was temporarily mezmerized by eight individual RGB NeoPixel LEDs I got from Adafruit.
I now have a nice little demo sketch (not quite finished yet), and a breadboard with these NeoPixels wired up. These things are BRIGHT! I have the start of a library that will be based in the Adafruit_NeoPixel library, but will be much higher level. My routines can work on an entire strip of NeoPixels, or a range if the last to optional parameters (startPixel and endPixel) are included, and one of them is not zero. I have complete range checking included in all my routines, since these are going into a library others might eventually use.
I will find a way to use some of these on W.A.L.T.E.R. 2.0! I have some ideas for various status indications. Adafruit has sticks of 8 available, rings (12, 16, and 24 NeoPixels), and strings (30, 60, and 144 NeoPixels), an 8x8 matrix, and an Arduino shield with 40 NeoPixels available. I have a string of 60, but I think I may have somehow managed to kill it. 
I havenāt been able to get it to work yet.
OK, OK, back to W.A.L.T.E.R. 2.0ā¦
I build up my second DS1307 Real Time Clock breakout board, and installed it on the display and sensor breadboard. I put several layers of Scotch tape over the USB connector on my Arduino Mega ADK board to prevent any shorting against the Sensor Shield, put the Sensor Shield back on it, and fired up my Navigation sketch. It still tells me the RTC is not running, after I set the time on it and tested the RTC with another sketch. The funny thing is the RTC test sketch also tells me the RTC is not running and then happily continues to run the way itās supposed to and sets the time correctly. All this is to say there appears to be a BUG in the version of the RTClib Adafruit makes available and insists you use instead of the stock one. I have to get the datasheet for the DS1307 and see which bit should be tested to see if the RTC is running, and check that against what the RTClib::isrunning() routine is doing. If this is a library bug, I will fix it and move on.
This wouldnāt be the first time I have had to fix bug(s) in Adafruit code so I could continue working on my application. Iāve had to fix bugs in their Arduino and Python libraries, and Adafruit has NO consistant coding style at all.
I am also in the process of porting Adafruitās Arduino library for the L3GD20 gyro to Python, so I can have full functionality of my 10DOF IMU with the Raspberry Pi and other platforms using Python. Iāve already found one constant naming problem in their Arduino library - not consistant with the rest of the constant names. I shall fix this naming issue and move along, as always.
Update: I fixed the problem with the RTClib for the DS1307 RTC. They had āreturn !(ss>>7);ā and it needed to be āreturn (!(ss>>7));ā in the DS1307_RTC::isrunning() routine. All fixed and things are working the way they should now.
8-Dale
Iāve added the Teensy 3.1 as an official development platform for W.A.L.T.E.R. 2.0!
So far, both displays (7 Segment and matrix 8x8) and the BMP180 temperature/pressure sensor (part of my IMU) are working. I use a lot of breakout boards from Adafruit, so my code depends on a lot of their libraries. Some stuff just works so far, which is good, and I am hoping most of their stuff is like that.
I donāt know if I am going to be able to use the Orion RoboClaw library, because it uses the BMSerial library, which I believe uses SoftwareSerial. I am looking at the RoboClaw library now, to see what work might be required to use it. I might be able to get it to use a Teensy 3.1 hardware uart.
If I understand the Teensy 3.1 serial ports (uarts) correctly, HardwareSerial is Serial (RX1/TX1), HardwareSerial2 is Serial2 (RX2/TX2), and HardwareSerial3 is Serial3 (RX3/TX3). It seems pretty obvious, but this does not seem to be working. I have the SSC-32 connected to Serial2 now, and the RoboClaw will be on Serial3. Using āSerial2.println(ā#0 P1500");" doesnāt seem to be working. I will figure it out.
Iāve also tried:
#include <HardwareSerial.h>
HardwareSerial console = HardwareSerial();
HardwareSerial2 ssc32 = HardwareSerial2();
console.println("Test");
ssc32.println("#0 P1500");Without success.
If I can get everything I need on W.A.L.T.E.R. 2.0 working with the Teensy 3.1, it could have a major impact on how I do the processing I need to do. This also depends on whether I can get a decent carrier board for the Teensy 3.1 also, because I donāt want to have W.A.L.T.E.R. 2.0 be all jumper wired together.
8-Dale
Try something like:
Serial3.begin(38400);
Serial3.println(ā¦)
Sorry on iPad
Think I have robowclaw library hacked up for other serial sitting around someplace.
Iāve spent some time verifying, in a known environment (Arduino Mega ADK) that everything is working properly on the display and sensor breadboard.
There is an apparent issue with the RTClib for the DS1307 rtc that fails the running check regardless of the state of the rtc. I thought I had fixed this, but there seems to still be a problem. For now, Iāve commented out the code that checks whether the rtc is running or not.
Everything else seems to be working as it should.
I have a version of the Navigation3_Displays sketch that builds clean for the Teensy 3.1 now. Iāve commented out everything to do with the BMSerial and RoboClaw libraries for this version until I can decide how to handle this.
This is v0.2.3 ALPHA, for both the Arduino Mega ADK and Teensy 3.1. Testing will commence with the Teensy 3.1 as soon as I have both batteries charged up.
8-Dale
Looks like you are making progress!
I thought I still had a version of the Arduino library for Roboclaw that I converted to work with a hardware serial port. Did not find it, but should not be hard to reproduce. I do still have my Roboclaw library code up in my Raspberry Pi project. I just checked how much of the Roboclaw library I changed for this. For minimal. I derived it from a different class in this case: WrapperSerial. WrapperSerial is a simple class that converts the Linux file system into a serial class (actually probably a stream class). The only real difference after that was to change the begin.
What I would probably do if I were you, would be to derive the class from Stream, probably have itās constructor take a pointer to a Stream object and then have it simply forward the writes and reads to the underlying objectā¦
I have finally connected my display and sensor breadboard to the Teensy 3.1!!
First, the good news:
The BMP180 Temperature/Pressure (part of the 10DOF IMU breakout board) sensor is working fine.
The TCS34725 RGB color and TMP006 heat sensors are working fine.
The Parallax PING and Sharp IR range sensors are working great.
I have communication with the SSC-32 Servo controller on HardwareSerial2().
I am using my versions of the Adafruit_10DOF_Unified (Hybotics_10DOF_Unified) and Adafruit_BMP085_Unified (Hybotics_BMP180_Unified) libraries, and they are working.
Now, the bad news:
The L3GD20 Gyro (part of the 10DOF IMU breakout board) does not seem to work, apparently it is not detected - commented all Gyro related code out. I will look at the Adafruit_L3GD20 library and see if I can find any issues.
I am getting readings from the LMS303DLHC (part of the 10DOF IMU breakout board) Accelerometer and LMS303DLHC Magnetometer (Compass), but am not sure they are correct. More testing andvalidation is needed.
I have also created a version of Paulās software serial library (Hybotics_SoftSerial), but it does not build clean. A table needs to be created for 48 MHz and 96 Mhz speeds, in this format:
static const DELAY_TABLE PROGMEM table] = {
// baud rxcenter rxintra rxstop tx
{ 115200, 3, 21, 21, 18, },
{ 57600, 20, 43, 43, 41, },
{ 38400, 37, 73, 73, 70, },
{ 31250, 45, 89, 89, 88, },
{ 28800, 46, 98, 98, 95, },
{ 19200, 71, 148, 148, 145, },
{ 14400, 96, 197, 197, 194, },
{ 9600, 146, 297, 297, 294, },
{ 4800, 296, 595, 595, 592, },
{ 2400, 592, 1189, 1189, 1186, },
{ 1200, 1187, 2379, 2379, 2376, },
{ 600, 2379, 4759, 4759, 4755, },
{ 300, 4759, 9523, 9523, 9520, },
};
There are also other issues I donāt know how to correct, because Iāve never done any serial port programming. If this can be fixed, I might be able to use this serial library to make the RoboClaw library work. I have the RoboClaw 2x5 Motor Controller set to be on HardwareSerial3(). Iāll need to use a Software Serial port for the XBee and any other serial devices.
Overall, I am pretty happy with these first results of running the code for W.A.L.T.E.R. 2.0 on the Teensy 3.1! This is all basically out of the box! 
I just transferred the connections for everything from the Arduino Mega ADK directly over to the Teensy 3.1. Of course, I had to adjust settings in the header file to accomodate the hardware differences on the Teensy 3.1, but that was easy.
8-Dale
Here is a picture showing my connections to the Teensy3.1. I have a hardware console on HardwareSerial() using a 3.3v cable from Adafruit. I need to wire up a reset switch for the Teensy3.1.
8-Dale
I havenāt updated this thread for awhile, sorry.
Iāve been having some issues with my RoboClaw 2x5 motor controller. So far, I donāt know what is wrong, but Iām not getting anything at all back from it. I double checked my RoboClaw configuration, and it is correct (Packet Serial, address 0x80, at 38400). I was getting an error indication when I had it on Serial2 (where the SSC-32 is now, and working great).
Things are interesting tonight. I canāt get anything back from the RoboClaw 2x5 at all. I switched the SSC-32 to Serial2 (17, 16), the RoboClaw to Serial1 (19, 18), and the XBee will be on Serial3 (15, 14). The RoboClaw was on Serial2, where I was getting the error indication. Iām not getting any error condition from it now, but am also not getting anything back from it (even from the RoboClaw examples).
Have I somehow blown my RoboClaw 2x5? I really hope not, because I will have to wait until next month to get another one.
8-Dale
I have no background with Serial commands on it but have you try directly to a serial monitor ?
Hopefully it is not blown! But also as it is a newer one, you might contact Nathan or support and Basic Micro/Orion Robotics and see about in RMA.
On a slightly different (but related) subject. I have continued to muck with the Roboclaw library, that is not depending on BMSerial. It is a sub-class of Stream, and you pass in a pointer to a stream object at object creation. It all builds now, but trying to decide on how much of the code to update. That is Nathan has code to do reads with timeouts. Turns out the new Stream class also has timeouts (his uses micros, theirs uses millis). Also their main read with timeout (1 byte) is private, but they export readBytes and readBytesUntil which use the timeout. So may update his helper functions to use theseā¦ Nice to have it decoupled and probably smaller and faster. One complication is that his code generates a CRC while reading and I would have to do it afterā¦
Let me know if you wish to try this out.
RoboClawStream RClaw(&Serial3);Donāt have an RClaw begin any more as this depends on object used. Instead you need to init the actual object.
Serial3.begin(38400); // Not part of RClaw when simple stream sub-class
Yes, I hope it is not blown too! Itās not acting like a blown controller though. I can still configure it and it comes up with a green light when it comes on. That doesnāt sound like a bad controller to me. Nathan still hasnāt authorized my account for the Orion Robotics forums. I registered there days ago!
The proper way to fix all this is probably to āfixā the BMSerial library. Mucking around with the RoboClaw library code means somebody is going to have to hand merge in changes when Nathan does an update to the library. If we have to do that, itās too easy to introduce more bugs.
Then again, it would be nice to not have to deal with the BMSerial library anymore. I am a bit torn on this subject, but can see where having a brand new RoboClaw library would be really nice, where we can make whatever changes we want. We just have to decide if we want to fork and not worry about any new updates from Nathan or not. What I would do if we fork, is to just use any new code from Nathan as an example of what we might do, but not as what we must do.
Sure, Iāll give it a try and see if my RoboClaw likes it.
In the end, all I want is something that works for multiple platforms. It has to work on the Teensy 3.x of course, which is what started all this. Aside from not being able to easily use the I/Os on the bottom of the Teensy 3.1, I am really loving that little board, and the fact itās made not more than 12 miles or so from where I live. I just need a proper carrier board for it and Iāll be all set!
8-Dale
I am still working on the Stream based version and trying to get it to handle most of the stuff as possible.
But have included a WIP version here. On Teensy, I think there is an issue with using the variable parameter stuff.
There is a test program here that tries to do most of the different ways the code does reads as to test me using the Streams implementation. Also good way to see if you are actually talking to Roboclaw.
The part the is #if 0 in the test program if turned on hangs on Teensy. I believe it has to do with variable argument passing, which Paul made a change to make compile, but maybe needs something else.
Kurt
P.S. - If you are still having problems talking to RCLAW, if you have encoders connected, try unconnecting them. Also be careful when you connect them. One false move, Like plugging the cable in the wrong way, can kill the encoder. I know been there, done that (killed both and had to order new ones back then)
Teensy_RClawStream_Test-140215a.zip (738 Bytes)
Found that issue, The library was passing a pointer to a uint16_t value into a function that assumed it was a uint32_t. For some reason did not fault on ATMega, but on Teensyā¦
Will do a little more cleanup, but so far these tests are working. Also good way to verify you have bidirectional communications working to RClaw. Note: RClaws at times have issues of getting into error state, if it starts off in middle of communications. So with test setup, I will turn power on to RClaw as it is compiling and downloading. Also 5 second delay at start of test program for you to get the terminal window open to start seeing responses.
RoboClawStream.zip (5.7 KB)
Well, that would be a problem with the ATMega compiler then, if itās an error that should have spewed out and didnāt.
Ahhh, this sounds good! I took W.A.L.T.E.R. off the shelf this morning, and merged the new code from my SES Robot sketch into W.A.L.T.E.R.'s Navigation sketch.
Here is what I get when I compile the Navigation sketch with the new code (Arduino Mega ADK):
Sketch uses 40,238 bytes (15%) of program storage space. Maximum is 258,048 bytes.
Global variables use 4,340 bytes (52%) of dynamic memory, leaving 3,852 bytes for local variables. Maximum is 8,192 bytes.
This is after I merged all the area scanning code into the Navigation sketch.
I should be good to go for at least awhile now. I donāt anticipate needing anymore large chunks of dynamic memory. My dynamic memory needs will increase slightly each time I add a new sensor data variable to the AreaScanReading struct, but that shouldnāt impact things too much. Iām already storing up to 36 area readings, which is enough storage to take readings every 5 degrees of a 180 degree arc.
Iāll have a chance to work with the RoboClaw 2x5 again, to see if it is really working or has gone bad. Iāll unplug the encoders before working with it again.
8-Dale
Iāve been working on the areaScan() routine that scans a defined arc, using a defined increment in degrees. I belive areaScan() is working fine, but I am having problems with the moveServoDeg() routine that I am working on now.
It was very cool seeing the areaScan() routine work for the first time, as it scanned and took sensor readings at each position! Now, I just have to get the moveServoDeg() routine to put the pan servo at the right position to start scanning from.
8-Dale
Iāve been working more on the areaScan() code today. I noticed that the pan servo doesnāt seem to want to move into the 500ms to 1500ms range of its travel. Itās correctly mechanically aligned, because I can move it manually when no power is applied. It apparently just doesnāt want to go into that range under control of the processor and SSC-32.
Iāve checked my code, and it is sending the right commands to the SSC-32.
Since I donāt have another HS-475 servo to replace it with, Iāll have to steal one from the SES Rover until I can get more servos. Thatās alright, since I have to replace the processor on the SES Rover too.
Iāll do some more testing, but it sure looks like this pan servo is bad.
8-Dale
Actually this is a case the compiler can not detect. That is, the code is using variable number of parameters to the function, which the code then grabs the next one and casts it to what it thinks was passed in and then uses it and stuffs out a value, which is about the equivalent to:
void MyFunc (void *ptr) {
*((uint32_t *)ptr) = 0;
}
...
void MyCaller(void) {
uint16_t myVal;
MyFunc((void*)&myVal);So the function is stuffing 32 bits into a 16 bit variable. So depending on what is memory at the next spot will be cleared. Some times this is fine, other times this is notā¦
In the midst of doing some major rearranging of my living room, such as adding a lot more table space, my laptop seems to have gotten some errors on the hard drive. I have everything back up and running now, but I did lose a bit of data that I must have forgotten to push to Git. So, I am back at v0.2.6 ALPHA of the code for W.A.L.T.E.R. 2.0, and am working my way back up to v0.2.7 ALPHA now.
I have a new robot build area now! Itās a new desk a friend gave me. Now, I just have to get power and network to that area, and also get some computing resourses there so I can work on and program my robots.
8-Dale
I am rearranging the processors on my robots, since I ran out of dynamic memory on the BotBoarduino thatās on the SES Rover now. Iām going to move the Arduino Mega ADK board to the SES Rover, and the Teensy 3.1 thatās already mounted on W.A.L.T.E.R. will become his processor, at least for the locomotion and basic sensor subsystem.
I have all the parts on order to do this, including some Perma-Proto boards. Iām really excited about these! They will allow me to transfer my breadboard circuits directly into permanent circuits after they are working. My first circuit I will transfer will be my display and sensor circuit thatās on W.A.L.T.E.R.
I should have all the parts to do this by the end of this week.
8-Dale