I think things are more clear now. I don't have nothing more to say at this time, that can add value and I will ignore messages that don't bring value.
Looking forward to see what you can get. Would be great if you can share the tutorials, etc that you will be following as I would like to learn!

I am pretty sure it can be done with EBike controllers running our OpenSource firmware, were the variables values for torque, motor rotation direction and motor current speed can flow over UART (the controller has wires with UART header because it uses a Bluetooth module). And since there is already working code for Arduino to UART and MPU6050, I think this aproach is a good idea for something to be done fast as prof of concept and to learn and have fun :-)

I understand, you can see as you go, I like to do that also :-)
One note: as you can see on next video, XenonJohn, needs to configure motor and regen speeds. In the case you discover you can't do with that controllers, you then can try our OpenSource firmware where you can control regen current and motor speed/acceleration.

Seems that MicroWorks is back online again and has listed the MicroWorks 30B4 board: http://microworks.en.alibaba.com/product/60430498308-801473537/self_balancing_scooter_sourcing_codes_programming_board.html

You would be the first one!! :-) XenonJohn is doing that but using a commercial and expensive motor controller.
I think would be great if someone do what you are thinking, I want to do it also but I first I want to read and understand the math and also find free time :-) -- If you do it, in full or part, as long as you share information, everyone will win.
I would like to help but I am very limited of time -- at least I think I can try share and discuss tecnhical information.
So, about using a cheap EBike motor controller for running the motor on both directions:
- the firmware I did for this STM8 EBike motor controllers, follow the same PWM code I did for EUC firmware on STM32F103
- the STM8 EBike motor controller firmware currently don't support invert direction as it was never developed as there is no need for ebike application but I think I can do it relatively fast and include simple UART commands to make the motor rotate on both directions
- as for STM8 flashing firmware, I am using Linux and another developers using Windows, you would need to try for yourself and ask help on the forum
- see here which cheap controllers are supported and where to buy them: https://opensourceebikefirmware.bitbucket.io/
- as for Arduino, I would go with Bluepill Arduino as it is very cheap and uses just the same STM32F103 ARM used on EUCs boards: http://wiki.stm32duino.com/index.php?title=Blue_Pill -- get it on Ebay
- you can also get on Ebay, very cheap, the MPU6050 Arduino module, so you would be using the same hardware as EUCs and the same firmware I did developed would work

I would like to try develop balance code but for fun, as I don't plan to ride EUCs. I like the math challenge, I need to learn more and more because is important for me professionally.
After 3 years, I learned a lot and assembled a notes file/site with a lot of technical documentation: https://eggelectricunicycle.bitbucket.io as no one ever did, so I am really happy.

Are the EUC riders inverted pendulums??
I was looking to some videos about balance and I found a lot of examples, of classes, showing inverting pendulum and how to get the motion equations. Seems inverted pendulum is a typical challenge for students and so we get a lot of videos about it -- here is one that seems relevant to get the equations that may be applied to our firmware:

Last month, January 2018, I started to work professionally, for a greener environment <3
I joined BFO Mobility, a German company that develops high technology for electric bicycles, like ABS brakes!! They also develop products for electrified micromobility as the Flynn scooter -- this scooter don't have a throttle and user needs to kick for the motor to run, it is like electric unicycles, without throttle but using sensors like IMUs to feel the user <3 <3
Both Ebike ABS system and the scooter are using IMUs and a lot of math :-)

Our OpenSource firmware is now running on some EBikes :-)
Today I tested the ebrake regen, this is my first direct drive motor that I am running at 1200W (48V 25A) and run at max speed of 42km/h at 48V. This motor could work for an EUC but it needs a large EBike rim :-)
Electric brake is so fast and powerful on an EBike!! I just implemented ebrake/regeneration on our OpenSource firmware for EBikes -- on the video, the wheel was rotating at 42km/h and the motor was also doing electronic braking: very strong and fast!! -- not mechanical braking were used. Our OpenSource firmware works for EBikes motor controllers from 0.25KW up to 4.3KW and can run motorcycles up to 120km/h.

So I tested the FOC of this dirty cheap motor controller: https://opensourceebikefirmware.bitbucket.io/Various--Endless-sphere.com_forum_messages--2017.10.23_-_FOC_and_no_FOC_comparison.html
2017.10.23 - FOC and no FOC comparison
The next information is about the results of using “very low resolution FOC”.
On the tests I run the motor with or without “very low resolution FOC”. The motor was providing the same mechanical output, was running at the same speed 16km/h and with the same load (on a bike training roller). With “very low resolution FOC”
As we can see, the phase B current is aligned with the all sensor signal, meaning the Id current is zero and IQ current is max.
The phase B amplitude is 0.94V that represents a current of 5.8A. Without “very low resolution FOC”
For the motor to be able to run at the same speed 16km/h as on the first test, the PWM duty_cycle / energy had to be increased.
The phase B current is not aligned with the all sensor signal (and this misalignment varies with motor load and speed), meaning the Id current is not zero and IQ current is not the max possible.
The phase B amplitude is 1.2V that represents a current of 7.4A.

On the firmware I did and I am developing, for Unicycles or EBikes https://opensourceebikefirmware.bitbucket.io/
the UART/Bluetooth communications interrupt have lower priority than the motor control interrupts. The motor control interrupts like the PWM interrupt have the top priority so the motor control code will always run! Here is my current firmware for the motor controller and communications controller:
while (1)
{
// because of continue; at the end of each if code block that will stop the while (1) loop there,
// the first if block code will have the higher priority over the others
ui16_TIM2_counter = TIM2_GetCounter ();
if ((ui16_TIM2_counter - ui16_motor_controller_counter) > 100) // every 100ms
{
ui16_motor_controller_counter = ui16_TIM2_counter;
motor_controller_high_level ();
continue;
}
ui16_TIM2_counter = TIM2_GetCounter ();
if ((ui16_TIM2_counter - ui16_communications_controller_counter) > 150) // every 100ms
{
ui16_communications_controller_counter = ui16_TIM2_counter;
communications_controller ();
continue;
}
ui16_TIM2_counter = TIM2_GetCounter ();
if ((ui16_TIM2_counter - ui16_throttle_pas_torque_sensor_controller_counter) > 100) // every 100ms
{
ui16_throttle_pas_torque_sensor_controller_counter = ui16_TIM2_counter;
throttle_pas_torque_sensor_controller ();
continue;
}
}
https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/blob/master/motor_controller_low_level.c
https://github.com/OpenSource-EBike-firmware/BMSBattery_S_controllers_firmware/blob/master/communications_controller.c

Yesterday, I did the very first ride on one EBike, with OUR OpenSource firmware -- and I was happy because my son was the first to see and try :-)
And 3 days ago, XenonJohn just post a video where it shows how he is building an EUC using Arduino + a brushless motor controller:

Lucky you because that boards seems to be a MicroWorks 30B4: https://eggelectricunicycle.bitbucket.io/MicroWorks_30B4_board.html
There are 2 pins for calibration, at least for what I remember. Don't remember now which was them but search on google for the board name and calibration!!

Just recorded some minutes ago -- the video shows the motor running using my lab power supply (that can handles max of 10A). Firmware was limiting the motor max current to be about 8A. Motor max speed is 45km/h when the wheel is on the air.
This controller family supports from 0.25kW to max of 4.3KW (72V, 60A), which should be ok to implement vehicles like hoverboards up to motorcycles running at 100km/h!!
Current motor interface implement the following methods, that can be used to control the motor and get his running speed value. This was tailored for EBike application but if anyone want to build a different thing like an EUC, we can help developing the firmware for that specific needs of the motor control.
/***************************************************************************************/
// Motor interface
void hall_sensor_init (void); // must be called before using the motor
void motor_init (void); // must be called before using the motor
void motor_set_mode_coast (void); // disable PWM output
void motor_set_mode_run (void); // enable PWM output
void motor_set_pwm_duty_cycle_target (uint8_t value);
void motor_set_current_max (uint8_t value); // steps of 0.5A each step
void motor_set_regen_current_max (uint8_t value); // steps of 0.5A each step
void motor_set_pwm_duty_cycle_ramp_inverse_step (uint8_t value); // each step = 64us
uint16_t motor_get_motor_speed_erps (void);
/***************************************************************************************/
Another project developer implemented support the LCD and mobile app:

Happy that we achieved the same performance as the original firmware (pretty sure the Kunteng developers also implemented that very low resolution FOC) -- here the tests the other developer did -- I have some more ideas to try improve the results :-)
The new controller arrived today. I've done some measurements on the test bench with the original firmware. The effiency is worse at higher mechanical loads in comparison to the 12 FET Lishui (FOC sensorless)... With your SVM_4 (8bit) algorithm we seem to do quite the same as the original firmware