Open kasbah opened 10 years ago
chpatrick
commented
10 years ago Unfortunately the timing of the code might be a bit "computer-specific" at the moment. :( It's also possible that the Q4 has different timing characteristics. I wouldn't recommend setting the a7105 loglevel to DEBUG as the overhead of logging will definitely throw it off. You could try running with chrt -f 40 python2 ..., which will give the process realtime priority and should make the timing more accurate.
chpatrick
commented
10 years ago Any luck?
kasbah
commented
10 years ago I tried with chrt but that didn't help. I also tried your (edited out) suggestion of trying to sniff what the remote is sending but I didn't have time to find out the differences and do thorough analysis. I have yet to try it with an X4 too.
kasbah
commented
10 years ago Tried with an X4 today and the issue is the same. For both quads it looks like it repeatedly manages to bind briefly (the lights starting blinking in sync) but then drops it again (the lights go back to alternate blinking).
kasbah
commented
10 years ago Got some more A7105 modules. Still the same problem.
chpatrick
commented
10 years ago If the quadcopter is changing its blinking pattern it's definitely receiving the messages. I'm pretty sure it's the timing - I had the same problem when I was developing the code. I think it's probably due to the computer not waiting long enough for the quadcopter's response, or something in that vein. Unfortunately I can't work on it right now as I don't have access to my quadcopter.
kasbah
commented
10 years ago Yeah, when I have some more time I will try and compare what the remote-control sends to what this code is sending or at least play with the timing a bit more.
srikanthnv
commented
9 years ago @kasbah were you ever able to get it to bind? I'm trying this with a Hubsan X4 and see the exact same problem - there's no response to the stage 1 bind. I see the blue LEDs blink together for a while and then lose synch again and blink alternatively, so the X4 is receiving something, but I can't make out why it's not binding.
kasbah
commented
9 years ago No, I never got this to work unfortunately.
srikanthnv
commented
9 years ago @chpatrick do you suspect this is caused by the scheduling jitter alone? If that's the case, I'd be happy to explore more accurate sleeps using RTC. I'm trying to understand if this is an avenue worth pursuing.
chpatrick
commented
9 years ago @srikanthnv When I was writing this I evaluated different forms of sleep (nanosleep, busy wait etc), and found that Python sleep was actually quite accurate. In the end it worked for me without real time scheduling too. I suspect it's more to do with a sleep missing somewhere, or not enough. Sorry for not having more info but I don't have much time to work on this any more, but if it helps I saw the behaviour you described when I was writing this and eventually got it to work by fiddling with the timings. Here's the original C version if you'd like to compare.
srikanthnv
commented
9 years ago Totally understand! Thanks for taking the time to respond @chpatrick and @kasbah!
joihn
commented
9 years ago Hello everybody !
I have the same problem, did anyone solved it ? Here is my work (I have a H107L): I have found that the problem is in the file hubsan.py line 79.
if self.a7105.read_reg(Reg.MODE) & 1 == 0:
this is an bitwise operation (documentation here http://stackoverflow.com/questions/29663428/strange-if-statement)
Basically, this line check if self.a7105.read_reg(Reg.MODE) is even. If it is, it execute the code, else it raise a BindError, and the stuff start again.
The problem is that self.a7105.read_reg(Reg.MODE) is always 25. (so not even, so doesn’t work) This is always 25, even when there is no powered hubsan in my room.
I have tried to change the timing at line 78, but no result…
chpatrick
commented
9 years ago Can you try running sniff.py? Plug in the Hubsan, start the script, then power on the remote. It should start printing out the messages from the remote to the Hubsan.
joihn
commented
9 years ago thanks for the fast response :)
here's the output:
scanning channel 120 channel: 120 session_id: 08 d1 98 0c 0 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 16 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 16 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 14 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a stage 3 packet received, switching ID 9 ms 03 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 08 9 ms 01 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 8 ms 09 78 00 d1 98 0c 00 00 00 00 00 00 00 00 00 0a 22 ms 09 78 01 d1 98 0c 00 00 00 00 00 00 00 00 00 09 22 ms 09 78 02 d1 98 0c 00 00 00 00 00 00 00 00 00 08 24 ms 09 78 03 d1 98 0c 00 00 00 00 00 00 00 00 00 07 23 ms 09 78 04 d1 98 0c 00 00 00 00 00 00 00 00 00 06 23 ms 09 78 05 d1 98 0c 00 00 00 00 00 00 00 00 00 05 22 ms 09 78 06 d1 98 0c 00 00 00 00 00 00 00 00 00 04 22 ms 09 78 07 d1 98 0c 00 00 00 00 00 00 00 00 00 03 22 ms 09 78 08 d1 98 0c 00 00 00 00 00 00 00 00 00 02 24 ms 09 78 09 d1 98 0c 00 00 00 00 00 00 00 00 00 01
at this point, it stop because my throttle isn't 0 (security)
if I put the throttle to 0, then it continue writing other things.
chpatrick
commented
9 years ago OK, so it looks like the A7105 part is working fine. I'll dig out my Hubsan this weekend and take a look at the code. :)
joihn
commented
9 years ago Hello Any update/idea about this ? Does your hubsan still work with the script ?
other idea: I have looked at the coment of this instructable http://www.instructables.com/id/Easy-Android-controllable-PC-Interfaceable-Relati/
some people say that the hubsan is very time time relative. With the arduino, if you put a line to output the data to screen( with Serial.print), it could destroy the binding (and some people experienced strange blinking pattern as well...) here is the most usefull comment (it's abour the proto X, which use the same protocol as hubsan
Quote: This is cool! I haven't built a custom quadcopter yet, but I have been using these Arduino instructions to control an Estes Syncro / Proto X.
I went ahead and set this up slightly differently--I got it working using 4-wire SPI, rather than 3-wire. This made it a lot easier to interface with the 5v arduinos, and also removed the guesswork from the resistor values. For a Due (or other 3.3v arduinos), 4-wire SPI doesn't require any resistors at all; for an Uno (or other 5v arduinos), a simple voltage divider (11k from MOSI to SPIO, 22k from SPIO to ground) handles writing, and reading (from GPIO1 on the left side of the radio board) doesn't require any resistors.
Three aspects of this took me a while to work out. First, there's commented-out code in the A7105_Setup function that claims to set it into 4-wire mode, but there's an error in it. It writes the value 0b0110 to register 0x0b. This is the correct register, but the wrong bit pattern--the bit pattern should be 0b011001, where the final two bits are 0 for non-inverted output and 1 for enable output. In hex, this value is 0x19. I probably would have caught this sooner, but the error codes in the Hubsan initialization routine all check for specific error flags set to 1...so if all your "read" calls are returning 0, the system thinks initialization has passed.
I added this routine to read the chip's "ID" register. This value is 32 bits long, so I write it into an array of uint8_t variables:
void A7105_ReadChipID(uint8_t chipID[]) { CS_LO(); SPI.transfer(0x46); // 0x40 | 0x06 for (int i = 0; i < 4; ++i) { chipID[i] = SPI.transfer(0); } CS_HI(); } You call it like this:
uint8_t chipID[4]; A7105_ReadChipID(chipID); If all four blocks of that are zero, there's something definitely wrong with the connection to the chip. I think this is akin to the MAC address for the chip--it should be constant for any specific a7105 chip, but it should be different for any two a7105s. Third, and perhaps most importantly, you can't rely on Serial.print in this sketch. Other people have pointed this out as well. Any Serial.print instructions in the sketch will make it unstable. You should comment out any Serial.print instructions before testing the sketch. When the sketch was half-working--talking to the radio correctly, but getting interference from the Serial.print commends--the front two lights on the Estes Syncro would blink in sync with each other, rather than the alternating flash they do when the craft can't find any radio. If you get to this point, persist! You've almost got it working. I'm planning to use this to build a more useful controller for the Syncro. In particular, I'm going to separate the throttle control from the yaw controls, because on the stock controller it's hard to turn without also bumping the throttle; I'm going to make the throttle control relative rather than absolute, but add a "panic" button to set the throttle to zero; and I'm going to add buttons for extra features, like buttons to adjust rate settings, buttons for flips, and so on. The Hubsan controller offers most of these features, but I'm confident I can produce something superior now that I have the freedom to tweak it to my heart's content.
\end of quote
but you said that, for you, it worked without real time scheduling... Maybe this problem is only there with the arduino method
joihn
commented
9 years ago Spent the whole day messing with the sleep... No luck :(
edit : I gave up using python directly. For the one interested about controlling hubsan x4 with python, I'm using this https://github.com/napsternxg/coptermanager-arduino and pyserial to talk to the arduino via serial communication
Hey, thanks for sharing this!
Having some trouble using this to bind to a Hubsan Q4 though. Gets stuck at binding. The blue lights go from alternating to in-sync flashing (like they should) but then go back. I tried increasing the timeout at hubsan.py line 78 but that makes it worse.
Works fine with the controller that comes with the X4 -- it should be the same protocol. I'll try with an X4 soon but do you have any other ideas?
Output with loglevel set to DEBUG in test.py: