As many of you can probably tell, I have been having a lot of fun with the Teensy 3.1 boards. pjrc.com/teensy/index.html
Now that I have two different Carrier board designs, I am trying out different ways to test them out.
So I am now in the process of converting my Arduino based DIY remote to use my Teensy breakout board that has the same form factor as most of the Lynxmotion/Basic Micro boards.
As I mentioned in a different thread, I now have this part wired up:
I have and will be using a few different XBees in some of the robots. Currently I am experimenting with my Arduino shield like Teensy breakout board, with two Arduino Shields, which arrived a couple of days ago.
The 2nd shield is an AdaFruit 1.8" TFT display (robotshop.com/en/color-lcd-t … o-802.html). So far looks like a nice little display. I don’t know if it is typical or not, but mine has at least row (or column) in the display that appears to be dead (dark line)… But other than that having fun.
Decided I needed a test app for this, so I decided to write a simple app that talks the DIY XBee protocol stuff and displays the current values on the display.
I have both of these limping along now. There is some issue with the Transmitter that wants a reboot to work. Think I know what is going on…
But then my next step is to simplify my DIY protocol. I will still continue to have the XBees work in packet mode, but I will have a lot less handshaking going on. Currently the Robot asks for data, which I then send back the most current stuff. Instead I will work this more like the Arbotix Commander and simply send out a data packet so many times per second (30? 50?), May have a default frequency that can update. Don’t need to have the initial handshake as the Robot can grab the source of the message directly from the message. Much of the rest of the stuff probably does not need to change.
Will be interesting to see if this will make things easier or not.
Not sure how many people (if any ) will be interested, but tracked this issue down (again). 2nd time this has hit me.
On some XBees on some processors, I have found that when they first power up, they come up in a strange mode. I get an OK message on the Receive line at 9600 baud. If I reboot, it works fine. I had this issue with some of the other boards in the Arduino DIY XBee remote. Never understood why, but that is why I added a reboot button on the front panel…
I think it has to do with some signal (pulse) on TX of some size and probably with some timing at power up, which puts the XBee into a recovery mode. I have used the mode in the past (actually once yesterday), to take an XBee that is either bricked or baud unknown, and be able to reprogram it using X-CTU.
So the Hack/Fix was to at startup, do an XBeeSerial.begin(9600) (In this case I have #define XBeeSerial Serial2). Then output a “ATCN” which says leave command mode, then reopen the XBeeSerial at the desired baud rate. Now in my case I am using 115200.
FYI - The XBee baud rate is not the rate the XBees themselves communicate at, it is simply the communication rate between the XBee and the Host. So you can have multiple XBees communicating with each other where each of the hosts are talking at different rates. The only issue, is if you try to output too quickly at a high rate, it is possible that you could overrun the other side (Probably need large packets)…
I did some more playing with some of this yesterday. I now have a version of the Phoenix Input driver using this updated protocol and I set up a configuration for the SQ3 with the Teensy 3.1 board and XBee, so also still using my ServoEx code base to run the servos.
I was having problems, of the communications, that the robot would stop receiving inputs. I determined that I was filling the 64 byte input buffer on the Teensy for Serial1, and some of the inputs were being tossed as expected, but some of the time the code would recover other times not… I knew that packets were being tossed for invalid checksums, which I recover from, but the issue I ran into was depending on what characters were lost, I could end up with what appears to be a very large packet length, which I did not verify and might try to read a thousand bytes into a 33 byte array… I put some validation in there as well and now the code is recovering fine from this. It is now working both with my simple program that displays packets on the 1.8" tft shield on my Teensy breakout with headers setup as well as on the SQ3.
I still need to do some testing/fixing of the code base, to make sure things are all working. But I am able to set the remote to send something like 30 frames per second, may be able to go higher. May put configuration screen in or could have robot itself send message saying give me N frame per second…
Still have a question for myself on what is the best way to handle the potential of lots of input frames. Could each time I need input, read through as many packets as I can and make it into some form of composite (maybe only need to deal with buttons).
Or instead of having the code bases like Phoenix which gets input, computes the next step which the code says maybe should take .2 seconds to do that step, and so we wait for the .2 seconds to get the next input. In the mean time maybe (6 input messages were received). We could instead maybe have the code break the Step that was to take .2 seconds into 5 sub-steps which should take .04 seconds… Not sure if that makes sense. Note: I think Nathans code base does something like this. He did it as he also thought it would make more accurate motions…
Also another question: so far I am only making these changes for the Arduino (probably soon Linux) code bases. The question I have is should I also try to fold the protocol changes into the BAP code base as well. Currently none of my hex/quad robots are running on Baps.
I’m interested.
As you probably know, I’m using my DIY remote on 7 of my robots with ARC32 or BAP28 and one with ArbotiX. I’m not sure if I I’ll get time to make an additional DIY remote with Teensy or just modify my current DIY remote. But I’m a bit afraid of not having an operative remote at all during the testing and building, so I’ll probably go for one more DIY remote based on Teensy.
I’m also thinking of replacing the BAP boards on my robots with Teensy. At the moment I’m not sure if I need an updated BAP code for the new protocol.
When it comes to frequency, I think 30Hz should be good enough. But having it variable would be useful in the future. I’m not sure at the moment.
I’ll let you know when I’m starting on my other DIY remote. Not sure what display to use though. I do have a serial 20x4 LCD display, a bit big though. Also not decided what gimbals to go for, custom or the 3DOF with two buttons.
I will take a look at updating the BAP remote as well as BAP code for robot. I may create a github project for the DIY stuff as to keep different stuff up there.
But right now need to go out and do some work on Chicken coop
Hi Phil - As you can probably tell from this thread, I am having fun with the Teensy. Lots of IO pins including analog pins, Usarts, and the like.
Kåre - I had a feeling you would say that. Yesterday I went through taking a pass at converting the BAP code for the Remote to the differences in the protocol. I am doing it with the extra two knobs (sort-of like yours - but mine are just simple knobs…). Now starting to test/debug. Run into an issue that most of my NIMH battery packs are showing their age and not holding much of a charge, so in the process of charging some up…
Yep hard to choose - My current 2nd one has one of these in it: sparkfun.com/products/11676
Nice little display. I was earlier also experimenting with one of their touch screens, I think (sparkfun.com/products/11677)
right now on my Teensy Test for shields I am using one of these: adafruit.com/product/802 (purchased at robotshop) nice little display, minor issue with one pixel line dead:
I thought I would experiment with one of the 2.8" touch screens adafruit.com/product/1651 which arrived Friday. Unfortunately it was DOA, but their support person on the forum Saturday, gave a few suggestions, and today shipped a replacement… So hopefully that one will work. Adafruit has some nice libraries that work for their products. One thing I want to experiment with is maybe the ability to use some different fonts. They have one font(5x8?), which you can blow up, but multiples of pixels, so next is 10x16…They did this to be used on small memory systems, but with Teensy or Megas you have more to work with.
As for joysticks, my 2nd one is using the “4way” joysticks that Lynxmotion used to sell, which have Knob/button on top.
Yep Lots of options.
I am still sort-of tempted to make a simple one like Trossens Arbotix controller, with Teensy, more controls, small display, accelerometer … But I am not sure yet. That is with many newer projects will probably go with Linux boxes. With many of these there is the capabilities to simply use other commercial controllers (PS3/4, XBox, Wii, Joysticks…). so many options.
FYI - started to push a few things up to github: github.com/KurtE/DIY-Remote_Control
BAP version of the Remote appears to work with enough to talk to my Teensy DIY test display, plus to my SQ3 with Teensy… Soon will push more stuff up there as well. Need to setup something with a BAP to test with…
Thanks Kurt! Looking forward to test it. I believe the main changes you are doing is in the xx_control_diy-xbee.bas file in the phoenix code? Good thing we have tools like WinMerge since I’ve done a lot of changes on that file for MorpHex.
Yep luckily most of the changes will be isolated in the function: ReceiveXBeePacket. There are several packets that are simply going to go away (Ready, Not Ready, Transfer Changed, Nothing Changed, transfer new… Also simple detection for knowing when we are receiving data and when we are not… The other changes might be for cleanup, if getting rid of some then unneeded variables.
Not sure yet if I should put the updated versions up in this new project or simply push them up to my other github projects (Arduino Phoenix in parts, Phoenix_for_baps), as not sure if anyone is using but us anyway.
Ok, sounds good Kurt. I think it would be useful (at least for me) if you could mark with a small tag in a comment the parts in the code that has been changed due to the new protocol. Just a wish…
Hi KĂĄre, as per the PM earlier today, it may be awhile before I will be able to physically update one of LM robots to have a BAP/Arc32, will try to soon, but no promise.
I do have a version of the code (My old Arc32 based Phoenix, with the code updated. I have not done any testing on it yet, could upload if would like. Could potentially update my github project: github.com/KurtE/Phoenix_For_BAPS
As no one probably uses this (But me). This had my drop of the 2.1 Phoenix code base as Lynxmotion never updated there projects to the 2.1 code base.
If I simply do an update, if you use github for windows, you can look at what actually changes in the delta. Shows replaced/deleted lines in Red and new lines in green. Likewise if you look at the github at the project, you can click on the commits tab and then again see exactly which lines change… What the heck I just pushed the current change up to github
I could update the code with showing comments, but about 90% of the changes is deleting code. That is the changes are:
No longer receiving Attach/Detach - so commented out messages, delete code that processed this. No longer having multiple types of messages for receiving packets. No longer asking for packets, no longer having to field messages that says something changed… So all of these constants and code and flag variables deleted. So again all of these changes are contained in the definitions at the top of the file, Maybe a few variables deleted in the InitXBee code.
I did some changes to the function APIRecvPacket - to do some hopefully better recovery when it detects bad data.
The majority of the changes are encapsulated in the function RecvXBeePacket.
I think the only thing I changed in the main function ControlInput, was in the error condition, where fValidPacket is not valid. The main change was to remove looking at the flag of the packet being forced, as I am no longer sending out messages to ask for data…
Currently my Arduino-> Teensy one is using one of the 4dSys OLED 128g1… I was also experimenting earlier on with one of the larger touch screen , I think it may be: (sparkfun.com/products/11677)
As for AdaFruit ones, I have two of them, both Arduino shields:
The 1.8" display with micro-sd and joystick: adafruit.com/product/802
This works with Pauls of PJRC’s updates to libraries.
As for which one to use? Good question. Obviously the 4dsys version would be a drop in replacement for mine(I think), except you have more space to work with. Issue with my larger 4Dsys and my own library, is I had to adapt as the coordinates for positions on screen changed from one byte to two… Still have that version bouncing around, but have not tried on Teensy.
Adafruit library is nice, except their text output is pretty limited. They have one font 5x7, which the only option you have is to scale the font up in integer multiples. You can see some of this in their GFX tutorial: learn.adafruit.com/adafruit-gfx … primitives. But this would not be hard to change. They simply have one PROGMEM table with 5 bytes per character, and the code simply loads these 5 bytes and sets the pixels to right color… Would not be hard to add additional character output functionality…
It has been awhile since I looked at the 4D font stuff, but I think they had a few different sizes…
) will be interested, but tracked this issue down (again). 2nd time this has hit me.
