PhantomX using a Teensy 3.1

[KurtEck]

It has been awhile since I did very much with the robots, I have been dealing with some other stuff, which hopefully is in the process of being resolved. Before this other stuff came up, I was tinkering along a few different fronts, which included:

PhantomX:
updating the PhantomX hexadpod to some updated parts as well as the Arbotix-m board. This was up and running.

DIY Remote control:
Playing around with my DIY Remote controls. Currently have two of them. The original one is still using an Basic Atom Pro. My other one that I have been experimenting with was originally Arduino based (a few different boards, including my own Atmega shield for the Seeeduino mega, later with my own board using Atmega644p and now it is running using a Teensy 3.1.

What I was working on, was to update my XBee communication protocol as to simplify it, which also allows it to speed up. Before the protocol was setup such that the robot asks the controller for a packet when it wants it, but this causes a time delay. Now doing it similar to Arbotix Commander, where I simply send it out N times per second (Still in XBee packet mode).

I have versions of this code working on the Teensy DIY remote as well as the Phoenix code base, which I tested some using the Lynxmotion SQ3 quad. I verified that I could get a much higher number of packets through per second.

As I know that Kåre still has several of his robots using some form of BAP (Bap28 or Arc32) and also is one of the few of us with these remotes, I thought I should also update the BAP versions of the code. I think I have a working version of it for my BAP remote. I also had an updated version of the Phoenix code base which I have not started to test yet, as I had converted all of my hexapods over to other processors. So I was in the process of converting the Phoenix to run with an Arc32 connected to SSC-32. Hopefully I will get this done soon.

Short Term plans:
I am going to slightly update the PhantomX Hexapod, to mount a Teensy 3.1 on the top, and then reroute some of the AX-12 servo connections, to use a second hub, for the two legs that currently plug into the Arbotix-M, plus make it easy to plug one AX-12 cable either into the Arbotix-M or into the Teensy as a quick and easy way to choose which board I will be working with...

During this, I will make a teensy version (or versions) of the Phantom_Phoenix_DIY_XBEE, for both Arbotix-M as well as for Teensy. What I have not figured out yet is if I will start off with using my github project Phantom_Phoenix and/or Phantom_Phoenix_Serial, or create a new project or start off in the full Arduino Phoenix in Parts project.

The main difference currently working with Arduino 1.0.5 for the Teensy and Arbotix is that I am using different code bases for driving the AX servos (Arbotix uses it's own serial code base, Teensy uses standard HardwareSerial code base). What I may do is start off with my Phantom_Phoenix_Serial github project and use Arduino 1.0.5 (plus Teensyduino) and for Arbotix, use Arduino 1.5.6r2 with my 1.5.6 Arbotix setup. If so, I will probably create a new branch in my Arbotix fork with my version, which is real simple as it no longer has any code...

Sorry for my rambling here

Thoughts?
Kurt

[Zenta]

This is not rambling Kurt, more like an excellent plan.

Great to see an update on this post. Sounds like a good idea to be able to switch between the two boards on your PhantomX.

As I know that Kåre still has several of his robots using some form of BAP (Bap28 or Arc32) and also is one of the few of us with these remotes, I thought I should also update the BAP versions of the code. I think I have a working version of it for my BAP remote. I also had an updated version of the Phoenix code base which I have not started to test yet, as I had converted all of my hexapods over to other processors. So I was in the process of converting the Phoenix to run with an Arc32 connected to SSC-32. Hopefully I will get this done soon.

THANKS!! Highly appreciated!

Lately I've been looking at the GetSinCos and GetArcCos functions for increasing the fixed point resolution. Making a new sine table with 0.1 deg resolution (instead of 0.5 deg) was the easy part. The table alone (901 values) require 1802 bytes of program memory (tested on ARC32). I'm not done with the ArcCos though. I also want to do some tests to see how much it matter. Especially when it comes to the ArcCos, since the Atan2 is based on the ArcCos.

Looking forward to play with the code again.

[KurtEck]

It might be interesting to see how much of a hit we would take performance wise, if you simply used floating point math here. I know the Teensy 3.1 does not have it hardware wise, but if we are running the processor at something like 144mhz with 32 bit math, it might not mater.

Also I actually remember a post up on the Lynxmotion forum, where the floating point square root function was quite a bit faster than the fixed point one I ported in from the BAP...

Before I got onto the Teensy wagon, I built a version on Linux that uses floating point. I have not yet gone back to it to see how the performance compares, but the code is up on github: https://github.com/KurtE/Raspberry_Pi

Kurt

[jwatte]

The OpenCM 9.04, which is 72 MHz, no hardware FPU, can run a full floating-point IK solution and navigation for a quad in a little over a milisecond. The Teensy ought to be at least as fast.

[Zenta]

Thanks Kurt, I'll take a look at it.

The OpenCM 9.04, which is 72 MHz, no hardware FPU, can run a full floating-point IK solution and navigation for a quad in a little over a milisecond. The Teensy ought to be at least as fast.

Sounds very good! Probably a noob question, but are you using the math lib for trig functions or are there other better libraries?

[KurtEck]

I would probably just using the libraries. If you need/want high precision can try using the data type of double, which on the Teensy are 8 byte values. There is a test program to look at speed of them, that some up on Teensy are playing with to see the impact of different CPU speeds. http://forum.pjrc.com/threads/25888-...floating+point

Kurt

[jwatte]

are you using the math lib for trig functions

Yup; I just call the standard library trig functions (and square root.)

Interesting tidbit: The NavSpark board is an embedded SPARC with double-precision FPU (!) and a Venus 8 GPS unit in it. For very heavy FP math, I'd expect that to perform well.

[Zenta]

Hi,
I've been looking at your float Rpi code. I saw that you are using float all the way. For Teensy would it be faster to use float only when using trig functions and converting to fixed point for the other variables (positions)?

Edit: For Teensy can we choose to use float or double? In the library docs they refer to double only, I think.

[KurtEck]

I was thinking that maybe should try going straight float or double through the code, probably makes things a bit easier to read and the like and then see if it turned out to be an issue. However internal to the actual servo driver, I would leave all of the interpolation code using fixed point as the values we pass to the servos are integer values. I should just get my ... moving and install the teensy on the PhantomX again and try it. I might start off with the project: https://github.com/KurtE/Phantom_Phoenix_Serial
Which to start with use the Commander for input. Would probably either create a new Branch (floating point), or simply create a new project and try it out.

Should not take too long to use either winmerge on windows or Meld on linux to do a quick first pass of merging in my changes from the Linux project.

As a side question to myself (and others who may know), I wonder if the Arbotix Pro, will have hardware floating point?

Kurt

[KurtEck]

I am not at full strength yet, but am trying to make a bit of progress.

Ok today, I did the part of mounting a Teensy 3.1 on top of the PhantomX Hex. I did not use a 2nd hub, but instead made sure the 2 leg servo extension wires were long enough that I could move it between the two processors. As for the one supplying signal/power to Arbotix-m, unplugged, added 2nd one that was long enough to reach Teensy board. So now switching requires moving three wires...

I updated my build to the new Teensyduino 1.19 and then edited boards.txt to enable higher speeds again.
Uploaded Phantom_Phoenix_Serial (up on github) and verified things were working.

I did a first pass of building a floating point version. I used winmerge to try to bring in what I had up on Linux version. Code compiles, Some stuff appears to not go completely nuts, but not working correctly yet, now to start debugging.

On Bap Phoenix side, mounted Arc32, put on XBee, but the wires I soldered into the old sparkfun board are now breaking... So need to re-solder...

Also side project - I did a fresh install of Ubuntu 14.04 on NUC, also installed Ros Indigo. The install appeared to go through, but have not had a chance to try it out yet.

Kurt