Falling-Up Robot Project for Teensy 3.6

EVL

Member
I'm developing the Falling-Up Robot, a 6-foot tall balancing inverted pendulum bot, using the Teensy 3.6. I want to practice feedback control systems, and keep it from falling over. I eventually want to let it roam autonomously and I let it interact with it environment. I've done this with the Arduino Due, but now I'm a PRJC convert. I’m building this in stages - so far, the brain and chassis is in place.

The Teensy 3.6 is connected to an LSM6DS3 IMU with SPI to sense orientation, and iLi9341 display with SPI for status, CUI AMT10 encoders for wheel position, and stepper drivers to control a pair of 3A stepper motors.

The software is written in the Arduino 1.6.12 IDE with Teensy Loader 1.34. I use PRJC libraries for the display and encoder readings. I use the Eigen C++ library to calculate orientation angles with an Extended Kalman Filter (EKF).

After dealing with EMI issues, the system with operating steppers, is working very well. I basically use CAT5 or CAT6 cables and shielding where practical. The power source cables are only as long as needed and also shielded. Next step is to finish the chassis and have it operate without the umbilical (USB and desk power supply).

Pictures enclosed.

The Teensy 3.6 pin assignments page says "Cut to Separate VIN from VUSB...". Is this really necessary when I bring in regulated power (5V) to VIN? Will that damage the USB circuitry?

E.V.L.
(Escape Velocity Labs)

Picture9.jpgPicture10.jpgPicture11.jpg


2/12/2017 Update. First video:

4/3/2017 Update. Part 2 video:
https://www.youtube.com/watch?v=QHb9eYAyGJc
 
Last edited:
Not cutting the trace will not damage the USB on the Teensy, but will leave you with 5V supply and PC USB 5V connected to each other. If both of these feature good design this is OK, but if say your PC is producing 4.7V regulated as USB and your PSU is producing 5V you can end up with your PSU driving current into you PC while trying to lift the 4.7V to 5V. Lots of interesting and expensive things can happen then.

Again good design prevents anything but general rule of thumb is to never connect PSUs that you don't know are specifically designed for load share.

As a single data point have destroyed a smart (ish) TV this way, so it's certainly not impossible.

Depending on what you are trying to do you can

Just do it and see what happens (if hardware is cheap and time is not), possibly having added a low values resistor so you can measure the current flow between the two PSUs
leave the USB uncut and just try to remember never to have both things plugged in at once
cut the trace and add a SMD diode across the gap + diode on the 5V VIN (means 5V will be ~4.5, teensy will work fine but other devices may not)
Not use any of the 5V circuitry on the Teensy and supply the Teensy with 3.3V from your own reg, having bench tested to confirm it can cope with power on it's VOUT pin while it's off (most 3 pin linear devices can)
Have a USB cable modded to break or have a switch on it's 5V wire
Add some form of dedicated power sharing solution featuring active diodes (overkill for this but what you use in low voltage battery/mains powered things where 0.5V drop is not acceptable).
 
Not cutting the trace will not damage the USB on the Teensy, but will leave you with 5V supply and PC USB 5V connected to each other.

I should clarify. When the robot is hooked to the PC for uploading programs, I solely rely on USB power. And I use my desk PSU (30V, 5A) for the stepper motors. The teensy and stepper drivers are optoisolated. A separate battery is used for the drivers. This is what is shown in the pictures.

When the robot is unhooked from the PC, I plan to use on-board 5V regulated power for the Teensy VIN. The optoisolated drivers will still have a separate battery. The stepper motors themselves have their own LiPos.

So I see no reason to separate VIN from VUSB. I will never simultaneously use USB power and on-board VIN power.
 
Last edited:
I'm looking for smooth robot balancing while standing still. So I went with stepper motors to get high torque at low RPM, no gearbox needed, so this means zero freeplay (or backlash) angle. These features are very difficult with conventional low cost gear motors.

On the other hand, steppers come with big disadvantages: they are power hunger especially at low RPM, and produce high vibration, including at low RPM. And because the IMU is near the stepper motors, the accels and gyros readily pick up the vibration.

To counter this, I found these design features extremely helpful: do stepper driver micro-stepping, use stepper driver with sinusoidal current control, mechanically vibe isolate the stepper motors, use anti-alias filtering with at an appropriate cutoff frequency (parameters in LSM6DS3 datasheet), and use a Kalman filter.

The enclosed plot shows the raw gyro and accel readings (100hz sample rate) while manually rocking the robot. The stepper motors induce high vibration, especially when crossing zero pitch angle (or tilt angle). But with the Kalman filter, you can still achieve a smooth pitch angle response (see last strip chart).

raw_response.jpg
 
Last edited:
I didn't expect to have problems with my optoisolated CUI AMT10 encoders connected to the Teensy 3.6. I'm using the PRJC encoder library.

The problem: encoder.read() picks up more rotations than actuality, and registers rotations when the motors are unpowered and not spinning. I tried two separate optoisolators, the HCPL2631 and PS2501-4, but no success. If I connect the AMT10 directly to the Teensy, the encoder readings are correct, but then I run into the EMI issues with the iLi9341 display. So I need the isolation.

Can you recommend a high speed optoisolator suitable for this application?
 
Last edited:
I'm looking for smooth robot balancing while standing still. So I went with stepper motors to get high torque at low RPM, no gearbox needed, so this means zero freeplay (or backlash) angle. These features are very difficult with conventional low cost gear motors.

I built one severeal years ago (btw, a nano is fast enough ) - much smaller than yours (height ~ 20 cm). Surprisingly, gear motors work very well, very quit and smooth. You can't hear them when balancing, and a little bit when driving.
 
Last edited:
@FrankB, nice robots, nice balancing. For me, I need more steadiness while standing still. With a very tall robot, the tilt oscillations are more noticeable. I'm going with height because it feels more interactive, I can add more sensors, and the main breadboard and Teensy are at eye-level from the desk.

But for now, I'm stuck with the opto-isolated encoders. The Teensy Encoder library is falsely picking up more rotations than reality, even when the motors are not spinning. I probably need more responsive opto-isolaters. I tried the HCPL2631 and PS2501-4 with no success.
 
Nice project, I don't quite understand why you would need encoders at all if you use steppers? As long as you don't get steploss errors the step counter should give you the current wheel position precisely enough? If you really need the encoders for some reason I wonder why you want to opto-isolate them?
 
Nice project, I don't quite understand why you would need encoders at all if you use steppers?

In theory that is correct, but in practicality, there are stepper errors in this project. This is especially true at higher RPMs because torque decreases, so there is slippage. And microstepping reduces torque further. I use microstepping to reduce stepper mechanical vibration. Typical stepping is 200 steps/rev; I'm using 3,200.

On the other hand, a major advantage is that stepper shaft backlash (or free-play angle) is zero. So nonlinear effects related to standing still are mitigated.

If you really need the encoders for some reason I wonder why you want to opto-isolate them?

I found that without opto-isolation, I get EMI issues and/or grounding issues with the stepper motor power supply unit (PSU) and Teensy. The issue causes display errors on the iLi9341 display with SPI communication. Here's a related thread:

https://forum.pjrc.com/threads/41244-EMI-Affects-Teensy-3-6-More-Than-3-5-and-3-2
 
Last edited:
Problem solved with opto-isolation and encoder error. Background: the optoisolators caused false encoder readings, even when the steppers are unpowered and still.

My shipment of very high speed HCPL-9030 isolators by Avago arrived. Very simple installation; no pull-ups or pull-downs required. Result: the encoders function properly. The Teensy 3.6 system is solid. These are very fast isolators: 2 nanosec rise time, 12 nanosec propagation delay. They isolate on the principle of giant magnetoresistive (GMR) action, not photo-isolation. Very expensive chips ($5.36 at Mouser). But as it turns out, not necessary.

I also found the problem with the the Fairchild HCPL2631 optoisolator. Reading the datasheet closer, it says "Notes: 1. The VCC supply to each optoisolator must be bypassed by a 0.1µF capacitor or larger. This can be either a ceramic or solid tantalum capacitor with good high frequency characteristic and should be connected as close as possible to the package VCC and GND pins of each device." Well, I was missing that capacitor. Putting that in fixes the problem too. On a positive note, the problem is fixed, I will pay closer attention to datasheets, and I learned about GMR isolation.

Next step: install the wheels and implement basic balancing.
 
Last edited:
RE scans from a design that used T3.1/3.2 that had been converted to use a T3.5. Running same code, but PCB updated to fit T3.5 and different fuse, otherwise no other significant construction differences. Test method and test conditions per CISPR16-2-3, and EMC report per IEC61000-6-1 and -3.

using T3.2
RE_DL141_rev2_T32.PNG


using T3.5
RE_DL141_rev2.1_T35.PNG

While the scan coverage is not adequate per 47CFR15/ICES-003/EMC directive (because done as 'side' test while testing a power converter), it suffices to demonstrate relative emission expectations between the various Teensy models.
 
Last edited:
Thanks for emission plots. What is the overall conclusion of your results? Hopefully you can do the Teensy 3.6 too. It triggered this thread:

https://forum.pjrc.com/threads/41244-EMI-Affects-Teensy-3-6-More-Than-3-5-and-3-2

Reference my comments in that thread.

What we can say, is that the Class A margin for my box decreased by approximately 3 to 15dB for the frequency components important for my application when the design was changed to use a T3.5 - some margin decrease may be from the higher clock frequencies, but some is probably from the slightly different layout to accommodate the mechanical differences in T3.2 vs T3.5, and some may be from the 1cm offset in connector placement and associated cable routing.

Use the test data found in EMC reports with much caution and skepticism and understand the relativism of data. These RE scans have absolute meaning only for my box, and for the defined scope and conditions of acceptability that would be found in the respective CB report and other national body reports for the end-use equipment (in this case IEC62109-1 and UL1741).

Have no plans to use model T3.6 in employer's equipment, and have only used in the nephew's project - kids always must use the biggest and best...
 
Last edited:
Tested stepper RPM response to make sure the encoders work properly. I stepped up the RPM vs. time and the encoders measurements match the commands. But at higher RPMs, the error begins to grow almost linearly with RPM command. See enclosed plot. The error is small and acceptable, but worth investigating a bit.

rpm.jpg

I tinkered with the DDS (Direct Digital Synthesis) parameters that drives the square-wave input, and the only one that yields an improvement is the clock rate. If I halve it from 65,536 Hz, I get a very slight improvement. So I suspect the HCPL2631 optoisolators for the stepper drivers are not fast enough. I'll try my new HCPL-9030 GMR-isolators. I use them for the encoders, and they work wonderfully. Just don't want to use them unless absolutely necessary because they are pricey ($5.36 per chip).
 
Last edited:
Faster GMR-isolators did not fix the RPM error. This error is very small and negligible as shown in the following plot, but I want to learn about the underlying cause. It's certainly not the circuitry or isolation speed.

factor.png

I suspect it's an mcu timing issue because so far, the only parameter that improved the RPM error was halving the DDS (Direct Digital Synthesis) clock rate. It's currently set at 65,536 Hz to allow a max spin rate of ~600 RPM (with microstepping set at 3200 steps/rev).

I use the IntervalTimer method. Does this have limitations with timing? My program currently uses two IntervalTimer objects: one for the main program loop (100hz) and the DDS (65,536Hz). Is there a limitation on the number of objects?
 
Last edited:
Okay, I found why the stepper motor RPM response did not match the command. The error is that I had multiple calls to the stepper driver function. As time elapsed, I progressively had more stepper driver calls within each program loop. When I rectified the software problem, the Teensy 3.6 and stepper motors functioned properly. See enclosed plot. Next step is to do basic tilt balancing.

debugged.jpg
 
I'm currently tuning the basic PID control system for tilt balancing. But the cycle of adjusting the gains in the code, re-compiling, uploading, running the robot, and observing responses is becoming time consuming.

So I'm writing code to update the gains real-time by sending strings to the Teensy 3.6 via USB Serial. I want to use Serial.available() to trigger a function to read the string. How many bytes can the Serial buffer handle? How can this be changed?
 
Last edited:
I think it's 128 bytes. However, you could try just six single keys for P/p, I/i, and D/d for the three parameters up/down. That would be faster than typing a string.
 
However, you could try just six single keys for P/p, I/i, and D/d for the three parameters up/down. That would be faster than typing a string.

That's a good idea. I will probably type in the three parameters so I can skip and jump values.

The USB serial section in prjc.com has more information than the harware serial section. The receive buffer size is 64 bytes:

https://www.pjrc.com/teensy/td_serial.html#rxbuffer

I'm sending 16 bytes directly from the Arduino IDE serial port. Timing on sending & parsing packets of data will need some scrutiny. My Serial.begin is set at 115200 baud. The moment the IDE detects I pressed the "Send" button, it fills the Teensy Serial buffer at a rate of 115200 baud, correct? On a Teensy 3.6 connected to a Windows 10 PC, what is the maximum reliable baud rate for Serial USB?
 
Last edited:
Check the buffer size again. I'm getting 128 on a T3.2 and it seems strange that the T3.6 would be less.

I've tested the hardware serial between two T3.2's and got 4.5Mbps with 128 byte packets. However, when going from a T3.2 through an FTDI/USB adapter, I had to drop to 2.25Mbps for reliability.

The serial monitor does not pay attention to the baud value but instead works directly by USB. I don't know what the equivalent rate would be but it is quite fast.

Don't know about the timing of the transfer but it acts as if the typed string sits in the monitor program then goes as a packet to the Teensy and raises the 'available' value from 0 to buffer content.

My idea for the P/p, I/i, and D/d approach is to use just one of the six keys to increment or decrement the appropriate value by some step or fractional value. That would allow you to tune in sort of a 'live time' mode.
 
Check the buffer size again.

For all Teensy-boards:
TX: Serial1 : 64 Bytes, Serial2..6: 40 Bytes. RX: 64 Bytes (Serial1..6)
(Of course, not all boards have 6 Serial..)

It's easy to change via gcc-commandline (well, if you have a good way to edit the comandline - depends on your tools)
Example : -DSERIAL6_RX_BUFFER_SIZE=512 or -DSERIAL6_TX_BUFFER_SIZE=256

Another way is to edit the sourcecode in the core - but this will affect all your sketches.
 
Last edited:
The 64 byte buffer was more than adequate - no need to change it. Dialing-in the control system gains real-time via serial USB was a major time saver.

Here's a video of the Falling-Up Robot during a stability check. It just stands still. Very steady. Very spooky. The robot is balancing as soon as it appears in the video. Then I rap it a few times, and it stabilizes. Result is good.


Next step is to add remote control capability, then full autonomous roaming.
 
Back
Top