I'd actually be curious to see how well this would work with a 1:1. I'd still want some sort of closed loop to prevent restriction when the system is in standby.

ehh, that'd be easy for sheezy but would run the battery down. Maybe something like
0-15% throttle = off
15% - 50% throttle = linear enough not to be a restriction
50% - 100% throttle = linear x% to 100% power (MAP limited for boost control) <---still...I think this could be more difficult than expected

I would run it off under some variable rpm (maybe 2.5k or so) and just closed loop to a boost target from there on out, with a variable target and gain. That seems like the biggest ban for the buck in terms of implementation effort.

Also, have some minimum (variable) throttle % so that you won't be boosting off throttle.

Once we know how to interface with the motor (control and monitor its speed), that shouldn't be difficult at all.
It's as simple as watching rpms and throttle position and referencing a table that has target boost values stored where they cross. The motor speed is adjusted up or down until the boost pressure matches the target.
Just a little more sophistication and you can reference a second table that provides rpm for the target boost.

Sounds awesome. It'd be great to try and use off the shelf components as much as possible and to make it modular as well so people can run whatever combination of hardware suits their needs (and budget). What about an arduino to drive the logic? It seems like it has more than enough I/O capability for this application.

You don't need any of that. Way too complicated. You don't need to know how fast the motor is spinning to control boost. All you need to know is what the target is at any given time and what your current value is relative to it. A wastegate doesn't know anything about the turbo it is controlling. It only knows what it's spring pressure is and what it's boost reference is relative to it (mechanically speaking, but you get the point).

Sorry should have specified, I was thinking of using "Processing" processing.org but that would just be for finalizing code. Arduino can output to LCD screens. That would be great for the final implementation.

Throttle body signal vs. pedal signal.

Pedal shows your intent while throttle body shows what's really going on. Not sure which would be best. Maybe an average of the two?

heres literally a 20-second effort at what we'd want, in Ruby just for kicks.

# half-baked example code
board = Dino::Board.new(Dino::TxRx.new)
sensor = Dino::Components::Sensor.new(pin: 'A0', board: board)
motor = Dino::SomeSubclassOfMotor.new(some_options)

TARGET_BOOST = 10.0
GAIN = 1.0

sensor.when_data_received do |data|
current_map = sensor.from_adc(data)
return if current_map == TARGET_BOOST
current_map >= TARGET_BOOST ? motor.throttle_down(GAIN) : motor.throttle_up(GAIN)
end

again just a quick thrown together example to illustrate the idea in a language people who don't code can read and understand. obviously this would probably be c, and a lot more complex.

sorry this stupid ass ancient relic-from-the-90's forum software doesn't understand markdown and won't let me format anything properly.

dangit. My MAP sensor won't show up till Thursday and I'm gonna be out of town till Sunday....not that it really makes a difference because I have no way of turning motor RPM into actual pressure :(
@jamesm - I hope it's close-to-that-simple. I mean...it could be. It would just have to know how often to adjust the ESC.

Off topic, but Ruby looks weird as balls. Your code reminded me to make a proper object out of my motor. I usually code procedurally. I'm about 20 years behind programming-wise.

if by 'weird as balls' you mean 'the most beautiful awesome thing ever', i totally agree :).

seriously though it pretty much is that simple. that's code i roughly ripped from another project i've done that basically did the exact same thing (headspeed governer for an rc helicopter, using a hall sensor for feedback instead of map, but same difference). works like a charm. i didn't even re-write it in C, just ran it as straight ruby off of a raspberry pi with a slave arduino feeding events. very, very simple and effective way to control the speed of an electric motor based on some sort of feedback and target. the trick is tuning the gain, but that can be a simple pot to make it easily adjustable (boost could as well).

of course for this purpose i'd re-write it (and the rest of the necessary code) in c and burn it to an atmega so it'll be self-contained and cheap as hell to reproduce.

The three dimensional reference table gives us the ability to have different boost targets based on the combination of rpm and throttle position. This is far more versatile than just a simple loop keeping the boost stable relative to throttle position or rpm.
It could be done without the motor speed but I wanted it for a reason that eludes me now.

i agree. the boost target could be referenced from a table of throttle position and rpm, that's simple enough. the part i was talking about being too complicated was the suggestion of adding motor rpm. we need to control boost, we can read boost, so no need to know the motor rpm required to achieve said boost i guess was my point.

basically you shoot for a boost target, not a motor rpm target, because you don't need to know or care how many rpm's it takes to make the boost you want at the rpm and throttle position you're currently at. only need to know your current value relative to the target.

think like a wastegate. wastegates don't care about compressor rpm :).

There was a good reason for wanting to know the motor speed but I can't remember it right now. Sucks getting old. It'll come back to me eventually though.

Tuning gain is great, but a system like this would require the ability to correct offset as well. Otherwise the system could settle out at the wrong boost pressure and as long as the error signal (feedback compared to setpoint) is steady then the system wouldn't correct for it.

I've calibrated and rebuilt more then my fair share of pneumatic controllers that can do this, but I have no idea how to do it in the digital world. Basically for this to work well a controller that can do both proportional and integral adjustment is what to look for. A full PID wouldn't be required though, I don't think.

Or am I an idiot and that's already in the code above?

Also, I really think we need to get past the idea of boosting to the back of a partially closed throttle. That's inefficient and with a setup like this shouldn't be required. If BRZ edit could be used to remap the throttle plate vs. pedal maps, then you could just set WOT to something lower in the pedals travel range then 100% and then use the rest of the pedal's travel to increase boost pressure to a max.