Robot Controller board using Teensy 3.5/6

Status
Not open for further replies.
Hi All,

First I want to say I absolutely love the Teensy family of boards! Got my first during my PhD studies at university where I needed the robots I was building to communicate via CAN bus. Since then I have used Teensy's in many projects ranging from a USB keyboard to WiFi controlled Christmas lights!

I wanted to post about an idea I have for a robot controller board. See, 6 or so years ago I built myself a hexapod robot inspired by the creations coming out of the old Lynxmotion forums. As you can see in the video below, I was able to get it built and walking forward, but unfortunately my PhD studies started shortly after this so I never got around to finishing it.


Now my studies are over with and I've been in employment for a while, I thought this new year would be a good chance for me to revisit this old project. Of course a lot has changed in these past years. Not only have I forgotten how the code works, both the Teensy and Raspberry Pi are now a thing. So rather than try and get the hexapod's current Arduino Mega + ARC-32 servo controller combo working again, I had the idea of making my own robot/servo controller instead. This would be powered by a Teensy 3.5/6 doing both the IK and gait generation, and connect to a Raspberry PI 3 for receiving high-level commands. Also, I have several other ideas that could benefit from such a robot controller, and maybe if I add enough connections to it other people would be interested in it too.

That is why I am posting here. Does this community have any interest in such a board, and if so any suggestions on what features to include and how I may include them? I know that several members have created breakout boards in the past, such as this one by KurtE (who I remember from the Lynxmotion days), so it would be great to hear their ideas and about any challenges they faced when creating their boards.


The features needed by the board for my hexapod are:
- 26 servo headers
- Screw terminals for motor power
- 6 ADC inputs for distance sensors
- 6 digital inputs for contact switches
- I2C connector for addressible RGB lighting (pre WS2812's)
- Serial to the Pi (maybe as a full 40pin HAT connection?)
- Some other GPIO I've probably forgotten about

One thing I would also like to do is modify all the servos to expose their potentiometer outputs, as it is really quite heavy and that extra feedback could help it compensate. That would need an additional 26 ADC inputs, which i'm not quite sure how to add at the moment.

The other robot ideas I have include a Fallout 4 Sentry bot, so would need PWM for driving 6 DC/Stepper/Brushless motors, and a "centipede" so would need support for more than 32 servos (maybe up to 128 using shift registers).

Thanks and I look forward to reading your thoughts!
 
That's a lot of servos. I wonder if it would be better to break the servos into smaller sets, each handled by their own sub-processor, rather than try to have a single Teensy control everything. I wonder about the precision of the servo/stepper motor control when a single Teensy is trying control so many servos and do other things at the same time.

It may also make wiring simpler if you make things modular. In any case, without using a shift register, you will need additional hardware since a Teensy 3.6 only has 22 PWM pins. I know there are SPI and i2c servo sub-controllers from Adafruit (controlling 8 or 16 servos), and the USB/serial Maestro controllers from Pololu that can control up the 24 servos, but you likely know much more about this than I do.

In terms of communication to the Pi, remember, you can use the USB serial as well as 5 hardware serial controllers.
 
You make a good point about going for a modular design! If I can have the main board support 32 servos for example, then any additional servos could have extra modules attached. If I was just making this for the hexapod I could technically use all 22 PWMs of the 3.6 and the Servo library for the rest, but this seems like an inelegant solution and as you say will make wiring more complex.

I have come across those boards you mention by Adafruit and Pololu before. They look like they could do the job well, provided there is enough bandwidth. For servo connections on the main board though, a trick I've seen used on the Servotor32 board (an Arduino Leonardo clone) is to connect shift registers to SPI but select each one in turn to stagger their updates so only 8 servos have to be dealt with at a time. I think they get away with this because the maximum servo pulse is 2.5ms long and pulses only needs to be sent every 20ms. Has anyone tried this technique?

I think I have a few shift registers lying around so will try this myself when I'm next at my workbench. Potentially this could scale to the extra modules too, meaning the Teensy controls all the servos, but as you say precision could be a real concern. In either case, going for this or existing modules would leave the actual PWM pins free for controlling motor drivers / anything that does need a 0 to 100% duty cycle.

Thanks for the reminder about USB serial. Would you say that's better to use than the Pi's hardware serial? I was thinking that adding the full GPIO would be more useful as the Teensy and Pi could communicate over that serial but also have several digital pins indicate status. Would that actually be useful though?
 
USB/serial Maestro controllers from Pololu
I have used these boards for a robotic arm project I put together and they do work well. There are a lot of options the give you to "tune" the servos like the setting servo speed and acceleration.
 
Note: I have not used RC servos for a long long time now. But back then I used to use two different approaches to controlling the servos. The Basic Micro ARC32, which was discontinued a long long time ago)...

Or I used the Lynxmotion SSC-32. Lynxmotion is now part of Robotshop and their current version: https://www.robotshop.com/en/lynxmotion-ssc-32u-usb-servo-controller.html
This controller handles 32 RC servos. Note: this controller works great for simple RC servos. It has features built into the firmware that can help with controlling the servos.

That is if you have a 24 servo hexapod, you can tell all 24 servos to move from their current position to a new position in a specific amount of time, and it will take care of figuring out how much each servo should change for each servo refresh output (50 times per second by default), such that they all arrive to their new position and the specified time...

Some of the other controllers like the ones from Pololu do this as well.
 
Thanks for the thoughts on these servo boards. Last I remember I reprogrammed my ARC-32 servo controller to do the walking algorithms on-board, but ended up writing most of it in Assembly because I needed more performance than programming in Basic allowed (and I like punishment apparently). I realise I can reprogram the board back to stock and have another microcontroller or a Pi send servo move commands to it, but I quite like the idea of having an all-in-one board again but this time using a more capable microcontroller and a programming language that I actually understand. Hence wanting to use a Teensy.

I'm curious KurtE, if you still make walking robots, what motors do you now use instead of servos?
 
Hi Zodius, I too was a gluten for punishment back then ;) But I actually liked their assembly language, it was nice and easy to work with...

Yes I still have some hexapods sitting around here. I have not done much with them in awhile as I find I enjoy more playing with the controllers and hopefully helping out with things more than I do with actually doing something with a hexapod...

But sitting somewhere around here, I still have a Lynxmotion Phoenix (I think this one still has an ARc32 in it). I also have a T-Hex which had SSC-32 and has had some different Linux boxs in it like (RPI, Beagle Bone Black, Maybe Edison...).

But mostly since those days worked more with Robotis servos, and hexapod from Trossen Robotics. Current version: https://www.trossenrobotics.com/phantomx-ax-hexapod.aspx
Which currently uses their older AX servos. At some point they were going to come out with a newer version using XL430 servos... Which would be nice... I have code bases that work with the current AX servos, for both their default configuration, plus I have version that works with just OpenCM board.

I have also versions that Linux board talking to USB2AX or Teensy 3.x or ... And their is a version of ROS code that works with RPI and USB2AX...
 
There must have been something about the assembly language that I liked at the time, but I have no hope of understanding the code now :p. Plus my understanding of how to make robots walk has advanced a lot over the past years so I doubt much of it will be relevant any more.

That Trossen Robotics hexapod does look nice! I think I saw Zenta post a video showing one in action fairly recently, moved really well! That does make me want to give Dynamixels a try. Maybe I could add support for them to this controller board? I notice your boards (images below) have connectors for them.

attachment.php

(https://forum.pjrc.com/threads/3830...ic-3-2-shields?p=119311&viewfull=1#post119311)

attachment.php

(https://forum.pjrc.com/threads/3624...st-things-with?p=146545&viewfull=1#post146545)

Do you happen to remember how they were controlled by the Teensy and what connector type those are? Also, any schematics or lessons you learned from creating these boards that you could share to help me in creating mine?
 
Most of my files for these controllers are up on my GitHub account. https://github.com/KurtE/Teensy3.1-Breakout-Boards

Again they were mostly for my own usage.. So no guarantees. They were done with DipTrace and most have the schematic and Layouts. Sometimes zip file with gerbers to send to place like oshpark... Sometimes these zip files have the dip trace files in it as well. Also for some of these there are excel documents with part numbers, which may or may not be fully up to date...
 
Thanks very much KurtE! I was able to load the two boards I pictured earlier in DipTrace without issue.

I notice for your Dynamixel connections you have two buffer chips. Am I right in thinking they are to make the half-duplex serial line, or are they more to deal with the different voltage levels? I am just wondering if they can be omitted if I use the 5V tolerant Teensy 3.5. Unfortunately, I don't have an AX/MX servo to test with yet.
 
Hi ZoidiusInfuser,

I have played around with at least three different ways to control these servos using Teensy 3.x boards.

a) Simplest - Simply connect up to TX pin of Serial Port. There is a half duplex sort of mode with the serial ports (LOOPS, ...). Worked fine as far as I could tell, but again with T3.2/5 yes it is 5v tolerant, but only outputs 3.3v output levels. As far as I could tell the servos worked fine on this, but their spec says 5v signals, and I have seen servos reset where their IDs go back to #1... But then again this also happened with Arbotix board which was AVR 8 bit 5v boards so... There is code in my library which will automatically set the direction for TX or RX... Note: I have to go in and directly set the appropriate values in the correct registers to make this work.

b) like a) but added a level converter to get to 5v. Again simple, gets the servos up to spec...

c) A setup which takes care of converting full duplex to half duplex... I have done this a few different ways with different chip/chips. There was one I first used which was nice in that it was all done by one chip... Downside was it was a rather large chip, that could actually translate 4 or was it 8 signals, with two different direction pins that half were on high and half on low... So worked great. But then have used a few different smaller setups which took multiple chips...

Hope that makes sense.
 
Sorry for not replying to this sooner. Was waiting till I had made some progress, which unfortunately didn't quite happen as I planned.

Thanks for all that info Kurte. Indeed it does make sense. I haven't ordered a dynamixel yet to try out but definitely want to include support in this board for them.

------------------------------

I started work on designing the schematic for the board with the features I currently know about. Don't really have much to show on this front unfortunately, but I have at least narrowed down Teensy pin functions. You can see my current arrangement below.

Teensy35Pinout-v1.png

Some of these will be used for components directly connected to the board, and others will go to headers so that I can add custom "shield" support. Also, because this will be replacing the ARC-32 currently on the robot, I want to keep a similar footprint, so shields could be a good way to give me more surface area.


Other than that, the most recent thing I've been working on for the project is a simulator in Unity to test out the walking algorithms I plan to have the Teensy run. I realise that there's code like that for the Phoenix Hexapod out there that I could easily use, but walking algorithms is something I've been researching on and off (more off really) for over a decade, ever since I first made a little script for a video game mod. Below you can see my efforts from 2009 to create a simulator, which although cool looking had a lot of problems.


Needless to say, my programming skills and understanding of the problem have improved since then (not to mention the scope has increased), so what I've been doing is building up a new simulator in the Unity game egine. It's visually not much to look at currently, but its helping me confirm my ideas work.

Hexsteps1.jpg

I have been posting gifs from the simulator on my twitter if you're interested:
https://twitter.com/ZodiusInfuser/status/1087863512532176896
https://twitter.com/ZodiusInfuser/status/1087901565191708674
https://twitter.com/ZodiusInfuser/status/1087901572032544768
https://twitter.com/ZodiusInfuser/status/1088967042525474823

I'd like to get back to looking at the electronics soon, but doing these algorithms now could prove useful in determining if the Teensy 3.5 is up to the task, or whether I need the higher clocked 3.6 or a co-processor of some sort.
 
Status
Not open for further replies.
Back
Top