Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HiTechnic Motor Controller Problem #104

Open
auryan898 opened this issue Mar 9, 2017 · 7 comments
Open

HiTechnic Motor Controller Problem #104

auryan898 opened this issue Mar 9, 2017 · 7 comments

Comments

@auryan898
Copy link
Contributor

auryan898 commented Mar 9, 2017

I tested HiTechnic Motor Controllers, and I found that the controller has a very low response time, I was doing this operation over bluetooth because I can't figure out usb connection, but I was able to use the nxt motors that come with the brick with very minimal delay.

So the HiTechnic Motor Controllers are slow to respond, and Daisy Chaining motor controllers doesn't seem to be an option anywhere, how hard would it be to add that? (probably adding Daisy Chaining is a good idea so that people have the option, even if it results in a lag in controller performance)

@auryan898
Copy link
Contributor Author

Correction: HiTechnic Motor Controller work fine now. They were set in a different mode than what I wanted to be used, and was confused as a result. Still a delay, but it's actually pretty reasonable.

Still though, I've been really trying to search through the source code of hitechnic.py to try and get Daisy Chaining up and running. The HiTechnic Specifications say that the chain is controlled by assigning different i2c addresses of 02/03 04/05 06/07 08/09 to the subsequent controllers in the chain but I can't seem to figure out how to send that from nxt-python.

It would be great if someone could give advice or some info about how i2c addresses are assigned to slave devices in nxt-python

@vishen89
Copy link

vishen89 commented May 4, 2017

ya even I am interested to learn as to how these i2c addresses are assigned?
I am totally new to programming. and I see that everywhere Hexadecimal is used.

@natebot13
Copy link

natebot13 commented Sep 6, 2017

I would be very interested in finding out how the addresses of the daisy chained motor controllers are assigned. Is there some proprietary protocol that gets sent from the NXT, or are the motor controllers just supposed to be able to let each other know about how they are wired on power up? Would greatly appreciate any info on that. Currently, I know the documentation say the addresses are supposed to be 0x02/0x03, 0x04/0x05, 0x06/0x07, 0x08/0x09, but when I do some I2C sniffing with an Arduino, all the it sees is 0x05, which, when signals are sent to that address, every controller picks up the data.

@Windwoes
Copy link

@natebot13 @auryan898 I figured out how to do the daisy chain. You need to connect the white wire (normally +9v from the NXT) to 5v though a 10k resistor. Then the controllers will correctly pick up daisy chained addresses.

@auryan898
Copy link
Contributor Author

auryan898 commented Feb 11, 2019

This is amazing because it looks as though the code for the Motor Controller and Servo Controller are both based on the BaseDigitalSensor class which uses self.set_input_mode(Type.LOW_SPEED_9V, Mode.RAW) as default because the Ultrasonic Sensor uses 9v. Adding a resistor shouldn't be necessary, and it seems as though it isn't.

import nxt
from nxt.hitechnic import MotorCon, Type, Mode

# In the case of creating a MotorCon object:
m = MotorCon(b,nxt.PORT_1) # using brick 'b' and assuming controller in port 1
m.set_input_mode(Type.LOW_SPEED, Mode.RAW)
m.set_input_mode(Type.HIGH_SPEED, Mode.RAW) # not sure which one would work

@natebot13
Copy link

@FROGbots-4634 Aha! yes, the issue was that the white wire was floating, and needed to be connected for the daisy chaining to work. I can now control my old robot with a WiFi Arduino. Pretty sweet.

@Windwoes
Copy link

@auryan898

Adding a resistor shouldn't be necessary, and it seems as though it isn't.

Well if I'm reading the spec correctly, then it is needed:

capture2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants