m8ta
You are not authenticated, login. |
|
{1052} | ||
IEEE-5332822 (pdf) Neural prosthetic systems: Current problems and future directions
____References____ Chestek, C.A. and Cunningham, J.P. and Gilja, V. and Nuyujukian, P. and Ryu, S.I. and Shenoy, K.V. Engineering in Medicine and Biology Society, 2009. EMBC 2009. Annual International Conference of the IEEE 3369 -3375 (2009) | ||
{850} | ||
Historical notes from using the Kinarm... this only seems to render properly in firefox / mozilla. To apply cartesian force fields to the arm, the original kinarm PLCC (whatever that stands for) converted joint velocities to cartesian veolocities using the jacobian matrix. All well and good. The equation for endpoint location of the kinarm is:
L_1 = 0.115 meters, l_2 = 0.195 meters in our case. The jacobian of this function is: etc. and (I think!) where tau is the shoulder and elbow torques and F is the cartesian force. The flow of the PLCC is then:
substitute to see if the matrices look similar ...
where
I'm surprised that we got something even like curl and viscous forces - the matrices are not similar. This explains why the forces seemed odd and poorly scaled, and why the constants for the viscious and curl fields were so small (the units should have been N/(cm/s) - 1 newton is a reasonable force, and the monkey moves at around 10cm/sec, so the constant should have been 1/10 or so. Instead, we usually put in a value of 0.0005 ! For typical values of the shoulder and elbow angles, the determinant of the matrix is 200 (the kinarm PLCC works in centimeters, not meters), so the transpose has entries ~ 200 x too big. Foolishly we compensated by making the constant (or entries in A) 200 times to small. i.e. 1/10 * 1/200 = 0.0005 :( The end result is that a density-plot of the space spanned by the cartesian force and velocity is not very clean, as you can see in the picture below. The horizontal line is, of course, when the forces were turned off. A linear relationship between force and velocity should be manifested by a line in these plots - however, there are only suggestions of lines. The null field should have a negative - slope line in upper left and lower right; the curl field should have a positive sloped line in the upper right and negative in the lower left (or vice-vercia). | ||
{487} | ||
here is the final, concluding, email i sent to nordic semiconductor concerning my 'troubles' with their chip. I post it here in hopes that it may help somebody else out there via the magic of the internet. See {485} for the development of the mode-switch solution (2) and {484} for the dropped packet investigation. Hi xxx, Ok, i figured out both of my problems:
As a result, I'm getting 99.99 % reliability on bidirectional bandwidth of 1.39mbps PTX->PRX and 18.3kbps PRX->PTX. So, I'm a happy person :) :) Hence, I don't have to try another radio solution. Just wanted to pass the information along in case it would help your other customers. cheers, Tim Hanson | ||
{485} | ||
Problem: switching modes on the nordic radios. see also {486}
solution-
present performance: txed packets = 118513 rxed packets = 118218 (note: computer has seen 118512 packets ) (and 118414 status packets, ratio: 0.999165 ) (note: 'stage ratio 0.997511 )(this includes code validation) now, if i boost the SPI clock on the bridge up to 5 mhz (headstage clock still running at 8.25mhz) to eliminate race-case (?) & add in 16 data packets before the status packets, perfection: txed packets = 44151 rxed packets = 44151 (note: computer has seen 750583 packets ) (and 44152 status packets, ratio: 1.000023 ) (note: 'stage ratio 1.000000 )after adding separate counters for TXed status and TXed data packets: txed packets = 808640 rxed packets = 50538 txed status packets = 50540 (note: computer has seen 808639 packets, ratio : 0.999999 ) (and 50540 status packets, ratio: 1.000000 ) (note: 'stage ratio 0.999960 )yay!! almost no dropped packets!! This equates to :
| ||
{486} | ||
here is an email I wrote to nordic semiconductor technical support concerning switching reception/transmission modes. see also {487} & {485} Hello, I've been having problems with switching modes on the nRF24L01. I want to implement a asymmetric bidirectional link, where there is a periodic (every ~36ms) time when the primary transmitter sends a status packet, then listens for a 32-byte command packet from the primary receiver. The command packet is for conveying configuration information, etc. I am driving both radios with blackfin DSPs using the built-in SPI port @ 4mhz, and am very careful with the CSN signal. The shock-burst feature is not enabled. Unidirectional transfer works great - I get nearly 0% dropped packets when the primary transmitter & receiver never change modes, up to a rate of about 1.5mbps. Of course, I am careful not to let the radio stay in TX mode for more than 4 ms - every 3ms i give it a 'break' by de-asserting CE. But bidirectional does not work reliably. Here is my procedure, on the primary transmitter side, for sending a status packet then changing from TX to RX & back to TX, with the initial condition that CE is asserted:
The process on the primary receiver is basically the same, but inverted. Upon receiving a packet of the correct type, it switches to transmit mode, sends off a packet, waits for the TX_DS interrupt, and switches back to RX mode. Like I said, when the transmitter and receiver never switch modes, the packets always get through without any corruption. When they switch roles for one packet, only ~ 78% get through, making the status packet -> command packet reply about 62% reliable. This is when the radio is only sending status packets - hence mostly it is in what the datasheet calls 'standby-II mode'. When the radio is also transmitting data packets, the status packet -> command packet relay is about 79% reliable, suggesting that the first packet after a switch from RX to TX mode is somehow being lost. Indeed, when I look at the IRQ signals on an oscilloscope, it is apparent that a certain percentage of the time the TX_DS interrupt is not followed by a RX_DR interrupt. so - what am I doing wrong??!! I'm desperate to make this work, and have tried almost every permutation! thanks, Tim Hanson | ||
{484} | ||
experimential results with the Nordic nRF24l01 (recall, as per {477}, that all SPI signals have an in-line 100 ohm resistor on both the headstage and bridge)
finally, it is solved!how:
| ||
{477} | ||
I've been having problems transmitting packets in a pipelined fashion using the nordic nRF24L01 tranciever IC. Namely, I cannot send multiple packets at once by keeping the on-chip 3-packet fifo full (note packets are 32 bytes data, max; with header/CRC, they are close to 40 bytes). If this fifo is full, the radio should remain in transmit mode - see {470}, and also {484} Above, what happens when I let the fifo go dry / empty, and force the PLL to resync for each transmitted packet, as per the following sequence:
Note just about all packets are received properly and that the RX irq closely follows the TX irq. Above, what happens when i try to pipeline transmission, e.g.
One initial theory was that noise on the SPI bus was corrupting the packets. However:
|