ottodiy/ottodiypython

port of the OttoDIY Robot API (Otto9.h & Otto9Humanoid.h) to a micropython based platform

OttoDIYPython

This is a port of the OttoDIY Robot API (Otto9.h & Otto9Humanoid.h) to a micropython based esp platform

This project has just begun ... it's not ready for use yet ... please look at the issues to see if you can help make this a reality ...

we now have added the humanoid support 😄 ... Read this issue post to see how it's used ...

The Motion Code has been ported ... and a test file has been created ... to test this out

1. Install Micropython onto your microcontroller (I used a esp8266 nodemcu board)
2. Upload these files on to the board ... Use uPyCraft or ampy
3. run the Otto_allmoves_V9.py file from the REPL with the following command

>>> exec(open('./Otto_allmoves_V9.py').read(),globals())

Example Code

"""
Otto All moves python test 
OttDIY Python Project, 2020 | sfranzyshen
"""
import otto9, time

Otto = otto9.Otto9()
Otto.init(5, 12, 13, 14, True, 0, 1, 2, 3)
Otto.home()

Otto.walk(2, 1000, 1) #-- 2 steps, "TIME". IF HIGHER THE VALUE THEN SLOWER (from 600 to 1400), 1 FORWARD
Otto.walk(2, 1000, -1) #-- 2 steps, T, -1 BACKWARD 
Otto.turn(2, 1000, 1) #-- 3 steps turning LEFT
Otto.home()
time.sleep_ms(100)  
Otto.turn(2, 1000, -1) #-- 3 steps turning RIGHT 
Otto.bend(1, 500, 1) #-- usually steps =1, T=2000
Otto.bend(1, 2000, -1)     
Otto.shakeLeg(1, 1500, 1)
Otto.home()

ottodiypython's Issues

optimization (HEAP/RAM usage)

Things are moving fast ... thanks to everyone pitching in 👍

our target platform is the esp32, but we should support the esp8266 as well. While the esp32 and esp32s2 have adequate RAM (especially units that have PSRAM) the esp8266 is a bit more limited. We should consider optimizing our development for both speed as well as efficiency. Additionally, we should consider releasing our project as a complete firmware binary release with our code preinstalled ready to go.

Internal Constant Values

One optimization is the use of const values for integers or numbers that don't ever change. There's a special const function added to MicroPython that allows you to tell the interpreter and other tools that a value will never change. When tools know the value is constant they can optimize its usage, like inlining the value where it's used instead of creating a variable that takes precious memory. As your saw in the driver code page it makes sense to set register and other fixed values as consts.

Compile Modules into Frozen Bytecode

When a developer creates a Micro Python application they are creating scripts that are executed by the Python interpreter at run-time. Processing the script at run-time will not only use space on the heap but can also cause the heap to become fragmented. Developers can take modules within their application code and cross compile it into bytecode that is stored in flash with the kernel code. Creating the bytecode will cause the modules code to execute from flash rather than executing from the heap. The result is that less heap space is used and there is decreased heap fragmentation. Constant values and strings can also be precompiled into frozen bytecode which will prevent them from taking up unnecessary RAM.

Custom Built Firmware With Additional Modules

build a module inside the firmware; this option optimizes the module execution and minimizes the size of the same on the device; the module is frozen into the firmware.

References:

https://docs.micropython.org/en/latest/reference/constrained.html#execution-phase
https://docs.micropython.org/en/latest/library/micropython.html#module-micropython
https://www.beningo.com/5-tips-for-optimizing-the-heap-in-micropython/
https://learn.adafruit.com/porting-an-arduino-library-to-circuitpython-vl6180x-distance-sensor?view=all
https://www.microdev.it/wp/en/2018/06/25/micropython-micropython-compiling-for-esp8266/
https://www.microdev.it/wp/en/2018/07/04/micropython-micropython-compiling-for-esp8266-with-additional-modules/

otto_gestures9.py

otto_gestures9.py

otto_sound9.py

otto_sound9.py

otto_mouth9.py

otto_mouth9.py

us.py for esp8266 & ESP32

https://github.com/rsc1975/micropython-hcsr04

eeprom.py (mock) for esp8266 & esp32

mock the eeprom library similar to the arduino esp8266 library ...

generic test code

Here is a simple test program to run on a OttoDIY ...

Otto_allmoves_V9.py

oscillator.py for esp8266 & ESP32

oscillator.py for esp8266 & ESP32

OttoDIYESPShield

Doing this obviously means we will need to change the core hardware design to handle the change from the Arduino Nano and the Expansion Shield ... to a NodeMCU ESP8266 Or ESP32 ... the only expansion board I have been able to identify as a possible solution is the L293D Motor Driven Expansion Board for NodeMcu I do not have one of these boards yet ... and don't know how it interfaces to the esp yet either and we don't need the L293D ... It may be worth creating a custom break-out board for the project ... based on the NodeMCU ESP8266 & ESP32 ❓

add humanoid code

update: code is up ...
I'll push code here today that adds the humanoid code to this project ... the changes have already been added to the Arduino 'unified' OttoDIYArduino project ...

uses the same import and initialization for either Otto or Humanoid

import otto9
Otto = otto9.Otto9()

to initialize Otto, call things as you would normally ...

Otto.init(YL, YR, RL, RR, load_calibration, NoiseSensor, Buzzer, USTrigger, USEcho)

to initialize the Humanoid ... there are several ways ... including initHUMANOID() to stay 100% backwards compatible ...

Otto.init(YL, YR, RL, RR, load_calibration, NoiseSensor, Buzzer, USTrigger, USEcho, LA, RA)

Otto.init(YL, YR, RL, RR, LA = 4, RA = 5, load_calibration, NoiseSensor, Buzzer, USTrigger, USEcho)

Otto.initHUMANOID(YL, YR, RL, RR, LA, RA, load_calibration, NoiseSensor, Buzzer, USTrigger, USEcho)

essentially, Otto is a Humanoid with the arms not hooked up ... so we could just use the Humanoid code ... however, steps were taken to only init, and update the connect servos ... if you call 'arm only movements' and initialized as a Otto (not Humanoid) the call will be ignored ...

Not A Issue

This isn't a issue but rather a notice ... A new devel branch has been started to bring things up to date. We will maintain the current master branch and will be using the devel branch for current development ... so please reference the devel branch with any updates ...

https://github.com/OttoDIY/OttoDIYPython/tree/devel

otto9.py for esp8266 & esp32

otto9.py

batteader9.py for esp8266 & esp32

batteader9.py

otto_matrix9.py for esp8266 & esp32

otto_matrix9.py

otto_servo.py for esp8266 & ESP32

servo.py for esp8266 & ESP32

Package Project for PyPI distribution (organize filesystem)

The Python Package Index (PyPI) is a repository of software for the Python programming
language. micropython-lib packages are published on PyPI (Python Package Index), the 
standard Python community package repository: https://pypi.org/ . On PyPI, you can search 
for MicroPython related packages and read additional package information. By convention, 
all micropython-lib package names are prefixed with "micropython-" (the reverse is not 
true -some package starting with "micropython-" aren't part of micropython-lib and were
released by 3rd parties). To install packages from PyPI for usage on your local system,
use the upip tool, which is MicroPython's native package manager.

even if we don't distribute on PyPI ... a organization of the files into the structure used for packages would still be useful for manually installing ...

References:

https://github.com/micropython/micropython-lib
micropython/micropython#413
https://packaging.python.org/tutorials/packaging-projects/
https://packaging.python.org/glossary/#term-Import-Package
https://docs.python.org/3/tutorial/modules.html#packages
https://docs.micropython.org/en/latest/reference/packages.html#upip-package-manager

noise sensor

noise sensor code