Terrain Control alternate to PAS/Torque control

Joined
Jan 19, 2022
Messages
81
I'm working on an alternate to PAS/Torque; namely terrain control.

I live in a hilly area and basing the motor power on the terrain seems intuitive.
Since I have plenty of power, I usually say in 7th mechanical gear and just up/down on the PAS based on terrain so basically, I am the inclinometer controller.

Automating would eliminate the endless PAS 1,2,3,4,5,4,3,2,1 going up and down a steep hill and give almost infinite PAS levels; never more or less than you need :)

I know I burn a lot of excess battery when hill climbing because of the granularity of 5 levels.

For testing this idea, I've mounted an Arduino (with a Pi/touchscreen for HMI) and located an inclinometer sensor near the bottom bracket.

Terrain Mode is triggered on by a button and is cancelled by a brake signal.

The throttle cable was dissected and fed V+ and com from the arduino; which receives the throttle signal input as an analog input, This works really good but the signal is a bit jittery so a rolling average was used to smooth it out.

The arduino can output the incoming throttle signal or override it with the inclinometer based signal.

The throttle output (PWM) is fed through a cycle analyst to the controller. The data stream from the cycle analyst is read by the Arduino and communicated to the pi for display and archiving.

The wiring is finished and I'm working on the Arduino program right now so any comments are welcome.
 
Potentially interesting project, but I'd recommend us moving this to it's own thread, since it isn't really about the specific topic, and it is going to get technical in a way that probably wont' fit this thread (and it deserves it's own thread so it doens't get lost in this discussion). If you like I can move it to it's own thread and then just link it in this one.
 
Sure, that would be great; please move to new thread. Thanks.

The quality of posts on this site are amazing; I feel like I found a group of like-minded riders.
Any guidance from a group like this is much appreciated.
 
I think noise reduction is going to be THE big issue.
Every bump in the road is going to send a burst of "noise" to the inclinometer.

The normal remedy of rolling averages isn't going to work in this situation where the amplitude of the noise is high.

My initial code is to use an accelerometer to signal the Arduino that the bike hit a bump.
Focusing on the z-axis if it exceeds the last reading times 2, discard the current reading and use the last.

Reading are coming in every second, so the response for a real change is inclination should not be seriously delayed unless the bike is on a really bumpy trail with sudden changes in incline.

In that case, the Arduino would not be able to control the bike.

Any ideas on how to handle this situation?
 
HillCruiser said:
I think noise reduction is going to be THE big issue.
Every bump in the road is going to send a burst of "noise" to the inclinometer.

The normal remedy of rolling averages isn't going to work in this situation where the amplitude of the noise is high.

My initial code is to use an accelerometer to signal the Arduino that the bike hit a bump.
Focusing on the z-axis if it exceeds the last reading times 2, discard the current reading and use the last.

Low pass filter is another option
 
If there's other data that could be factored in, for example that would show the drive slowing - the terrain handler could respond to that situation, and ignore inclines that are essentially spurious for one reason or another, i.e. have no effect.
 
afzal,

Thanks for the suggestion.
I checked the specs on the accelerometer board and it has a built-in HIGH PASS filter that can be enabled via configuration.

Pot-hole surveys (I didn't know there was such a thing) use accelerometers as sensors and again suggest a HIGH PASS filter; apparently accelerometers sensors themselves experience a lot of low frequency noise.

But that's the board itself; as far as the application, I think a LOW PASS filter will be helpful.

I'm a wee bit confused on the whole filter issue right now; but I know if the Terrain Control doesn't work, I will end up with a very expensive pothole detector. :?
 
Donn,
I think what you said is the key to the puzzle:
"If there's other data that could be factored in"

Searching "vehicle sensor noise from road" brought up some research paper links and it looks like this is being actively studied. Several teams were using "sensor fusion"; fusing the signals of multiple detectors, i.e. gyroscope/accelerometer.

Then I went back and reread you post and thought about other sensors.
I have a Neo6m GPS chip which will provide altitude information on a 1hz refresh. Away from cities (on trails) the GPS altitude should be fairly steady. Maybe this signal could be "fused" with the inclinometer signal.

Another sensor currently on the bike is a BMP388 barometeric pressure sensor. It outputs altitude as well as baropressure and could also incorporated in the code.

Both GPS and barometric pressure sensors are immune to road noise but of course don't have the sensitivity of the accelerometer.
 
Powered by USB, as sensors were added to the Arduino, the rail voltage started falling, so I powered the Vin with 12v.

Everything was fine until a "wire whisker" touched the positive and blew the fuse I had installed upstream.
Since the USB was still connected, it tried to power the sensor array and overloaded.

The Arduino will power up but I can't upload a new sketch; it times out.
Seems like I needed to cut the V+ in the USB cable when powering through the Vin.

Two steps forward, one back.

I can't seem to find a replacement (Mega 2560) anywhere as all are on backorder.
 
bunch on aliexpress but that's usually a couple of months for shipping time

https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20220124143329&SearchText=Mega+2560
 
Yes, amberwolf.

I have two on order with aliexpress.
My other parts ordered from ali have taken 4-8 weeks for delivery.

Strange thing is they have absolutely EVERYTHING, in stock and ready to ship,
while in the western hemisphere everything is on backorder?????????????

Sadly, they have become my go-to place for parts.

The new clone boards I ordered are being advertised as having better USB protection!
 
So when it gets hilly you want the controller to have speed based assist, and when it's flat have torque based assist?
 
Comrade,

"Closed Loop" speed control is not part of the programming right now because personally I don't think it's important to hold a specific speed when climbing.

The idea is to vary the motor power based on the inclination of the bike. So just for talking, let's say a ride will vary from -20 degree inclination (very steep downhill) to +20 (very steep uphill). Terrain control would give 0 watts of power at a -5 degree slope and apply more and more power as the bike tilts upward.

On level ground, the controller would deliver 200w of power (100# ebike, 200# rider) and at the maximum inclination of +20 degrees, the output would be full motor power; 1500w in my case. All of these values will need to be easily tuneable.

Other than occasionally shifting mechanical gears, the rider doesn't have to do anything else but pedal (optional).

The calculated power output is sent via a throttle signal to a cycle analyst v3 which will pass-through the signal to the controller, while providing ramping and smoothing out the power feed. The data dump from the CA_v3 will be stored in a database along with GPS data for analysis, tuning and graphing.

Here's a view of the test bike:
20220125_130329.jpg
20220125_105750.jpg

As you can see it's just a big box store bike :) with it's front rack turned upside down :(
On the cover of the project box, you can see the raspberry pi/touchscreen and cycle analyst mounted. Panel mounting the cycle analyst really worked good as all the connections and excess cable (including the 2m data cable) are inside the box.
The big square downtube was perfect for running all the sensor wiring
 
I'm really stoked on this project and can't wait for a new Arduino so I started re-routing the signals to the Raspberry Pi.

First I connected the CycleAnalyst 'TTL to USB' cable to the Pi, examined the serial port with putty and saw data was flowing; even without asking for it. It just flows :) Actually a little too fast, so I slowed it down from 10hz to 1hz in the CA configuration.

Serial communication is a bit tricky as it can slow down the response of the GUI, but luckily I found this really expertly written code to run the serial communication in it's own thread: https://iosoft.blog/pyqt-serial-terminal-code/

This became the basis for my program as it worked right out of the box. Thanks to Jeremy P Bentham for this fine work!
-
With serial, the data comes in one character at a time and I had to figure out where a CA data line began.
I just kept reading characters into a buffer until I saw TWO end of line terminators ('\r\n' which are the carriage return\line feed control characters). Between these terminators was a complete CA tab-delimited sentence. yes!

The line was parsed using the "\t" (tab delimiter) and finally there were these 14 pieces of data; endless repeating every second. Perfect! The Pi supports SQLite so I setup a table and saved the data stream anytime the bike is moving.

The next data I needed to capture was the GPS so I setup another serial thread as above, installed a NEO6M GPS chip and connected it to Tx1/RX1 on the Pi. When I interrogated the new port with putty, there was another flood of data coming in: long, lat,time, date, speed, course, altitude, etc. Yipee!

It's interesting that at 9600 baud, the GPS receives data every second at the exact UTC seconds tick. All the GPS IC's I've tried behave the same way, so the GPS signal not only tells you where you are but is a perfect timing signal; a one second clock based on Universal Time.

The GPS sentences (there's actually several with some overlapping, some unique data, see https://www.rfwireless-world.com/Terminology/GPS-sentences-or-NMEA-sentences.html), comes in comma delimited so after parsing I displayed it on the screen with the CA data and logged it into the same database table.

I'll start with the sensors tomorrow....
 
So I'm getting ready to rewire the sensors and a package arrives with a Arduino Mega 2560 that I had ordered months ago from Germany. A REAL one, not a clone. It's a beauty!

Also, the weather improved and I was able to get out for a test ride; snow over ice, treacherous roads and test riding ebike mods :roll:

All is good so far, the CA_v3 is performing nicely. It really is a well-thought out and executed device.
 
The new Arduino works great and now all sensors are reporting; but all need calibration.
After that, it will finally be time to start with the experiment.

I just left the serial links on the Pi since all were functioning and most of the data is for display only.
It'sa better setup because it greatly reduces the amount of data on the third link below.

One serial link is reading the CycleAnalyst data from the TTL to USB converter cable. The CycleAnalyst is constantly outputting data so the Pi just needs to read in a line and parse it (tab delimited) for display.

A second serial link is reading the Neo6M GPS data at 9600 baud and receives all NMEA sentences in a 1hz cycle. There's far more data than I need so I parse out what is applicable for display.

A third serial link is handling the bi-directional Pi to Arduino communication. The Pi sends out a message delimited with special character prefix and suffix so the Arduino can easily parse out the incoming comma separated data. Cadence, Speed, Throttle_In and Throttle_Out are used in the Arduino program and need to come from the CycleAnalyst, so the Pi relays the data.

Upon receipt of a valid message, the Arduino parses it out, populates variables and responds with a similarly formatted message with comma separated fields holding the sensor data. Both Pi and Arduino 'know' the order of the data fields so no metadata needs to be sent, minimizing the load on the comm link.

The Pi uses the pyqt5 library for building a display using Qt Designer software. The display is created in the Designer and then a very handy utility converts the native *.ui file into a python file that is brought into the program using an import statement. This really works good because you can modify the display, convert to a .py file and import without affecting the main program.

Here's a screenshot:
EBike Screenshot.jpg
It's not the final version but just a plain jane build that shows the pertinent incoming data.
(The other tabs on the display are for an autopilot project for a homemade sailing trimaran.)

I plan on taking a few rides just recording the data to build confidence in the sensors and accumulate some data points of inclination versus power. Not too much riding weather in the next 10 days so it's going to be a slow process.
 
The accelerometer data was coming in noisy but a rolling average on each value smoothed it out,
but will decrease response time of the signal. I still need to turn on the filters on the IC itself and see how much that helps.

I added three buttons to the display: Terrain On/Off, Terrain Power Up, Terrain Power Down.
The Up and Down buttons will bias the output in steps to tune the Terrain Control while riding.

The Pi, 7" touchscreen and case make a great package and being able to add soft buttons like this is really essential.
I'm sure there's some that think that a 7" display is too large for an EBike :), but for the experiment, it's perfect.

I cleaned up the database routines to include all the data on the display going into one table, all at the same timestamp.

The serial links are running flawlessly; really great news because in the past there were some phantom hangs on the
Arduino to Pi bi-directional link. GPS and CycleAnalyst links worked from the git-go and continue to do so.

I'm working on putting the throttle wiring back through the Arduino; right now its direct to the CA.
This time, there will be a relay on the throttle input that will direct it back to the CA if the Arduino is not running.
Before, if the Arduino was down, there was no throttle response. I don't use it for much but to get rolling but...

So just sitting here waiting for some riding weather so I can go out and gather some data.
 
I've been following this thread, very interesting project.
I know you're pretty far along but I have some thoughts in case the path you're on doesn't get your desired results. You mentioned your trimaran above so you're knowledgeable of sailing. Have you looked into how the foils on foiling boats are controlled? I saw an article a while back that I can't find now but apparently people are experimenting with having the foils electronically controlled in an effort to make foiling boats easier to sail. Granted they're controlling different things like foil angle of attack, etc, but there are similarities in that changes are made based on the boat's pitch (uphill / downhill), and they get knocked about by waves (potholes).
It might be worthwhile to do some digging to figure out what type of sensors they're using and how they're filtering or averaging the data. The article mentioned these were regular people tinkering and experimenting. If you could find them I bet they'd be happy to share what they know.
Just some food for thought.
 
I'm still confused as to why an inclinometer is necessary. Say you are going up a hill. It's not very steep, so you are at PAS level 1. Then it gets steeper, you increase it to level 2 (or have it done automatically using data from the inclinometer). The hill gets even more steeper, level goes to 3.

Why not control torque based on speed instead of incline?
 
Comrade,
"Why not control torque based on speed instead of incline?"

I really would like a bit of elaboration on this idea so I understand the control scheme.
Is just may have some bearing (no pun) on what I'm doing.
 
MattZ,

I'm getting ready to start a thread about the trimaran over on the watercraft side, but yes I did put a foil in the bow to lift it, as the biggest hazard of a trimaran is a cartwheel if the bow digs in too deep with a following wave.

The idea of adding more foils is something to consider.
 
Just an update:

I went to install a relay to always have the CA in control unless the "Terrain Mode" is activated; and the project box was too full so I did a complete power down and cleanup. After moving most of the TTL-USB cable out of the box, there was plenty of room for the relay. I took the opportunity to cleanup the wiring and baton down the components.

Today was warmer so I took a slow, short ride while capturing the data in the sqllite database.
Everything looks good so far but it was too slippery to turn on "Terrain"; probably good because it definitely needs a bit more training using the db data.

I need another display with just pertinent data in large font (like the CA); it was just too hard to read the numbers.
Also my glove doesn't register on the touchscreen so need some solution there...

The hardware and software are essential complete and for now it's just riding and recording data for a while.
 
HillCruiser said:
I really would like a bit of elaboration on this idea so I understand the control scheme.

So when you push the "hill climb" button your controller will vary current not based on incline, but based on speed. If hill becomes steeper, bike slows down, then controller gives it more current to maintain speed. Isn't that what you are basically attempting with the inclinometer?
 
Comrade said:
HillCruiser said:
I really would like a bit of elaboration on this idea so I understand the control scheme.

So when you push the "hill climb" button your controller will vary current not based on incline, but based on speed. If hill becomes steeper, bike slows down, then controller gives it more current to maintain speed. Isn't that what you are basically attempting with the inclinometer?
During a hill workout, my speed is all over the map. I'm controlling power level and changing cadence and mechanical gear just to get up to the top. On the 19 degree hill, I'm just barely crawling at maximum amps, in low gear and spinning fast. Given a lot more power and battery, I think speed control over the hills would work really good but it would suck the battery dry in a hurry.

But I do like the simplicity of the scheme; easily measured control variable and a closed loop control. Now that I have a working experimental ebike rolling over the roads I'd like to try various schemes and combinations so I'll definitely add a speed control loop and try it out. I think it will be useful for the long flat areas because wind becomes a bigger factor; depending on direction. It's just a matter of programming at this point and I've programmed more than my share of closed loop PID controllers.

Just wondering if any one else has had their bike start out across the garage without a rider?
I was checking if the CA was seeing the throttle output from the Arduino and had the KT controller energized to supply voltage to the throttle. I had the KT controller set on PAS 0; where it won't apply throttle. Well, reaching to turn the KT controller off, I hit the UP instead which put in in PAS 1 and enabled the throttle.

Luckily I was standing right there when the back tire started spinning on the rug, trying to catch hold. I quickly grabbed the brake before it shot into my beach cruiser ebike just ahead. Note to self: When you're directly manipulating the throttle, be a little more careful! You're playing with a lot of INSTANT power.
 
It's what I was talking about, about 18 posts back, as a way to filter out incline noise. The incline event you care about, is one that's accompanied by a perceptible decrease in speed. The tricky part might be correlating with pedal input to tell the difference between an intentional reduction in speed, that happens to occur on a grade.
 
Back
Top