Re: PhantomX using a Teensy 3.1

Yep I don't have any displays that big yet. I do have the 3.2" touch screen, which I was earlier going to integrate into a remote. Miss the days when I could get Jim to fabricate the top plate for me... Have the ones from Seeedstudio arrived yet?

Hope your son has a great Birthday.

Will start playing more soon. We hung the paintings for my wifes Art show yesterday and the reception for it is Friday and we have company for the weekend. So likewise not sure how much time I will have this week.

Re: PhantomX using a Teensy 3.1

Not sure if I should continue to discuss this here or on it's own thread...

But I have been playing around more with the DIY remote using the Teensy as well as the Teensy with Shield as test platform for the DIY remote...

It took me awhile again to get some of the Transmitter stuff to work properly, it would work when I did a reprogram of the Teensy, which rebooted the processor, but not on an initial power up... Turns out 2nd time recently hit with issue where XBee at powerup will boot up in Command mode at 9600 baud. Note: XBee itself is now configured for 115200. I think this has to do with some powerup signal levels on XBee (maybe pulse on TX at some point), that initializes the XBee in a mode so you can recover it. I noticed this on another board with different XBee a week or so ago, where at power up I receive a message from the XBee of OK<cr> at 9600 baud, as you can see in the output from LA

Note: in this output when the signals first change is showing when power is applied to the computer and XBee. The point on which I try to do an initial Serial2.begin() is about 4 seconds later... I am pretty sure I was seeing this before on my Arduino based Remote, that often would not work when I powered up, but would if I rebooted the processor. This is why I added a button to reset the processor. What I have now found that works pretty well in these cases. Is at program start up time, I do a Serial.begin(9600) and output ATCN<CR>, which exits the xbee out of command mode and then I do the final Serial1.begin(115200).

Once I got that up and running, I have done the first pass to simplify my communications protocol. I no longer output things like Attach/Detach, I no longer have the robot ask for data, but simply the remote sends out a message every N milliseconds. The robot can get who sent it to them, by looking at the source address of the RX packet. The transmitter knows if someone is receiving the actual packets by looking at the status byte of the TX Status message the XBee sends back to the processor. I can know reasonably well when the transmitter is no longer working. I simply set a timeout, and if I don't receive any packet in lets say .25 seconds, maybe time to turn robot off...

So far it appears to be working a lot nicer. I think with all of the handshaking I was probably getting less than 10 packets sent per second, which in many cases was just fine as with the hexapod, we probably do each move for over a tenth of a second. With the new one, my quick and dirty test where I think I should be receiving 40 packets per second, but my quick counter is showing in the nature of 34-35 per second.

I have also done some simple tests to make sure the robots is still able to talk back to the remote. I have found a few cases that I have not implemented a few features in this remotes code base yet. Will add it in.

Next up, will modify my DIY Input control class for the Phoenix/PhantomX code base and see how well it works.

One of the issues I have with myself, is what to do, when there may be multiple packets with data that has been sent while I am processing the previous set. Do like the Arbotix code base that once you get a valid packet you toss the rest away? Read all of them in and use the last one? Mostly it may not matter, but wonder about buttons. Suppose you are processing a packet that takes maybe .25 seconds (next part of a step), so maybe 8 packets sent. During that time, a user quickly presses a button and releases it. If you only process the first one or the last one you could lose that fact. Could instead look at the buttons in each message and do a logical OR of any buttons that go down during this timeframe. Maybe that would work better... On several of these processors, could do background task to read in the pending messages. Likewise could break the steps in a gait into multiple smaller steps.

Also assuming this all works out well for me. Wonder if I should take the time to back-port these changes into the BAP versions of this. Might be good for my main controller. But I currently no longer have any hexapods with a Basic Atom Pro attached...

Re: PhantomX using a Teensy 3.1

Thanks Kåre,
The art show is going well. Her stuff will be up all month (at least the pieces that have not sold She put up several new ones yesterday, to replace the ones that have already sold.

Yes, the Seedstudio boards do look nice. As you noticed the boards by OSHPark, are done by combining several orders into one panel that all get's fabricated together. On one of my orders it mentioned, that there were 87 different orders combined for a total of 501 boards, in the panel they sent out for fabrication. When I get them back I use nippers to clean it up a little.

Yep - I probably should also have some form of ventilation. So far I don't do enough boards to worry too much about.

I am playing with the code Input DIY code now, to see what works. As I mentioned I ran into some issues with compiling all of my code base for the Arbotix. Serial.flush() has not been updated. Serial.readBytes() has major flaw, INPUT_PULLUP is not defined... Would like to upgrade the Arbotix project hardware/core to be compatible with Arduino 1.0.5 r2. I may do a quick and dirty update of my fork of their code to the 1.0.5 core, with the necessary changes. Not sure yet if anything other than not creating Serial1 object?

As I mentioned trying to decide how to handle the buttons. I have code currently that tries to read all of the pending packets in and maybe making a composite value. That is we have a 16 bit value, (one bit for each button on the keypad. My current code is trying something like:

Code:

if (ReceiveXBeePacket(&g_diyp)) {
uint16_t wCompositButtons = g_diyp.s.wButtons;
// With new protocol, we may have received several packets from remote during the last interation
// How should we handle this. For most of the fields, maybe the last one is as good a thing as any
// but buttons, we may want some form of composit, so we won't miss some button events.
while (g_diystate.fNewPacket) {
wCompositButtons = (uint16_t)(wCompositButtons & (uint16_t)~g_diypPrev.s.wButtons) | (uint16_t)g_diyp.s.wButtons;
if (!ReceiveXBeePacket(&g_diyp))
break;
}

The idea is that if the button goes down on any of the messages that happen during the time from our last call here, the composite value will have that button as pressed. But if a button was pressed before I came in here it will only show as pressed if it is still pressed on the last packet retrieved. (as to allow for the button to be released). I am running into some issues with it so I may try the KISS method (just use value from the last packet). This is simple, but you may miss quick presses of buttons.

Re: PhantomX using a Teensy 3.1

Detecting quick presses has to be done on the controller side. In the best of worlds, in an interrupt handler.
What I typically do is keep a byte of pressed-buttons information.
When a button is pressed, I set a corresponding bit in that byte.
When time comes to send a packet, I send that byte and clear it to 0 (using some atomic read-and-clear operation to avoid a race.)
This means that, if the button was down at any time during the window since the last send, it will be shown as down in the packet.
Also, this naturally de-bounces the button, because the sent value is a union of a time interval; mutliple down/up/down transitions in the send window interval don't matter.

Re: PhantomX using a Teensy 3.1

Thanks, yep

I agree with you. But for example lets take how the Arbotix commander and code bases that use it's library work. The commander sends out a message with it's current state something like 20 or 30 times per second. On the receiver side, lets say we are doing the PhantomX Hexapod that is doing some form of walking that lets say takes 200ms from the time it starts until it decides to look for new input. So durring that time maybe 5 packets have arrived.

What the Commander code base does is to read until it gets a valid packet and then clears the rest of the input. So it throws away the remaining 4 packets. So if a real quick press happens, the events could be in the packets that were tossed away... For the most part this may not mater, but trying to decide if I want to try something different here.

Re: PhantomX using a Teensy 3.1

What the Commander code base does is to read until it gets a valid packet and then clears the rest of the input.

Ah. That's sub-optimal :-) If my bot was doing something for 200 milliseconds, that would be spread across many iterations of the main loop. I think my currently max main loop length is 2.5 milliseconds... Personally, I think making the receiving controller go away for 200 milliseconds is not a good idea, and something I strive to avoid. If it comes up, then the "read more and keep extra state" approach makes some sense.

Re: PhantomX using a Teensy 3.1

Hi Kurt,

Yesterday I finally got time for some soldering. It's been a while since I did some SMD soldering (>10 years ago, lol). The zener diodes was really small to hold in place, so i ended up making a simple tool for holding the SMD parts in place while soldering:

This simple tool made me much more comfortable having both hands free. Soldering the TSM conn headers on the bottom of the Teensy3.1 was relative easy by first solder the single row connectors and then use a prototype board over the connectors to hold the TSM connectors in place.
Teensy3.1 with connectors:

Complete board ready for testing!:

The simple ventilation system worked fine. Another workshop picture:

I've not done much testing. Just a power-up to see the power LED and the default LED blinking program.
Now, I've to figure what jumpers to place where..?
Btw, did you made a simple code for testing all pins and the speaker? I think its about time to update the Arduino IDE..

Thanks for sharing your work Kurt! Looking forward to play with my new board.

Re: PhantomX using a Teensy 3.1

Like your setup. I will actually be soldering up another one soon as well. I purchased two more of the Teensys from OshPark. Will probably do another with the Arduino shield and another with XBee.

As for jumpers, first I must slightly apologize that I did not make clear on this version that a couple of the parts and a jumper were not needed. (One resistor, diode and jumper) It brings the RX pin of the USART going to the AX buss. This was put in in case I want to experiment with some other serial servos that are full duplex. So the jumper to RX1 is not needed (D0).

Also the Reset was a hack, that I should have mentioned more clearly as well. Actually not sure of a good way to do this. If you look at the bottom of the Teensy:

On the image, to the right of the surface mount pad to pin adapter, you see a little solder point with an R marked next to it. This is the reset signal. How do you bring that out? I kludged and solder on a small wire, which I then thread through my reset jumper (as I mount the chip)... I end up with a bend of wire under the chip, which is not clean, but not sure of any better way to do this...

Also not sure if you cut the trace that connected VIN from VUSB on your board or not. If you do, then the chip will not be powered at all from USB. It will only be powered when you connect external power. That is why on mine that I did that, I did that ugly green wire that I could jumper from VUSB to VIN if I desired to do any testing with just USB power...

Now for test programs. Yes I do have a few different things I have tried out on this. I will be honest and say that I have not updated this test to fully test out every pin, but enough to test things as I go. This is a modified version of one of the programs I used to test the Botboarduino as well as my Mega Shields. Also there are things in here that were simply there for me to try out things... There are tests for making sure I can talk to XBee. I think this version also had code to try the automatic configuring of XBees. Also Test to talk to PS2... Some of the stuff I have not really done much with is testing servos and I2C...

Also testing of Analogs. I have done some but not all pins. I do have one of these boards in my (was) Arduino DIY remote, with 9 analog inputs which is working. WARNING: There is one group of Analog pins (10, 11, 14) which are Analog only and can only have 3.3v. The other Analog pins are digital as well and have built in handling for 5v. Although I believe the Analog values are up to 3.3v. Which is why on those pin groups I run 3.3v(or VIN) and not 5v. Also with Analog inputs with Arduino environment there are interesting issues with how to communicate with higher pin analog pin numbers. Like A18. Passing in 18 won't work as Arduino thinks you are trying to talk to pin 18 (which turns out to be analog A4). You pass in instead 29 and/or A18 which is probably defined as 29...