Processing IMU’s data

Hi,

I have been working on the IMU during the last few days. First, we have run some test with data coming from the IMU and our implemented DTW algorithm and the results bode well. By this I mean that if we compare two series of acceleration data from two gesture more or less similar, we get a much lower value than if we compare two different gesture. Not a big surprise but at least for precise gesture, there will be no doubt that we can guess the one that has been made by the user.

Nonetheless I have some troubles : The data given by the IMU are given along the IMU’s axis and we would like to have them along the user’s axis. The aim is that even if the user doesn’t hold the wand quite right, calculation will compensate for the wand’s bad orientation. On a mathematical viewpoint, it’s quite easy, it’s just plain projection with three-dimensional basis, still my results in that area are a bit disappointing : I use the quaternion data given by the IMU, from them I can guess the coordinates of each axis of the IMU’s base into the user’s base (the rotation matrix from the quaternion). Since I know how to write the IMU’s base into the user’s base and I also know the coordinates of the acceleration vector into the IMU’s base, I can calculate the coordinates of that same vector into the user’s base… But with all the multiplications and divisions that implies, the result isn’t quite what it should be, values move a lot even if the IMU is still and the gravity’s vector is sometime more horizontal than vertical.

So more about it tomorrow, I hope I’ll have a solution and I am open to suggestion 🙂

Hugues

[Expelliarose] Laser Tag and DTW

Here it is :

The IR emission and reception have been included in the wand handler thread. Now if receive an attack from any opponent that hasn’t attacker for less than 2 seconds, a led animation will be displayed. We have done some test : even in the wand, the receiver seems to work great, still the range is not that high : a few meters (2-3) but we can still increase the power of the emitter by reducing its resistance. So we have been able to play some laser tag as tests.

However : we are facing some weird bug : if the PCB is not connected via USB to a computer, the thread seems to crash after a few receptions. We will have to handle that problem tomorrow.

Moreover, I’m still continuing to do some test for the DTW algorithm for gesture recognition. The first results seems encouraging and now I’m coding a better program that will handle new series of data faster because we are going to do plenty of tests to see what gestures are best recognized.

See you,

Mickaël

Take that spell

After a few more days to tune the API between the nRF and the STM32, we’ve managed to get some interesting results. We’re now able to detect an incoming spell, to trigger wonderful LEDs animations, and most of all to broadcast it to the client. It is also working the other way around (if the server decides to attack the wizards!). The communication between the phone and our PCB is operational, and I have worked on the wand’s main thread to gather the different modules we’ve all been building. We have chosen to use an event-driven structure to keep the different parts of our code quite independent (that way, we can parallelize our efforts) and this choice seems so far efficient enough for our purpose. The connection between the BLE, the IR emitter/receiver, the LEDs and the motor is functional.

The rest of the team is working hard on the IMU, since movement recognition is a crucial part of our project. The last part of our 3D-printed wand was successfully printed today ; we made it very practical, and we will try to make it shinier when we have some time. We also decided to slightly switch priorities: instead of focusing on firmware flashing over USB (which is not essential for a prototype), we’ll try to set up the microphone when the human power becomes available. Yelling wizards would definitely improve the game play!
Oh, and we are struggling on the capacitive controller that yields unexpected (or un-understood) results. We’re not giving up since it would provide a much better user experience than a regular, poor, depressing switch. The great magi have been summoned. Continue reading Take that spell

Wanderful !

Hi !

Since few days, I’ve worked on the capacitive sensor controller but I still get a problem : when I read the capacitance of the sensor I use, I always read the same value, even if I put my hand on the pin sensor.

This CapSense controller converts the sensor capacitance into a count value, coded on 2 bytes. There are some debug registers and with them, I can read the count value. This one changes when I touch the pin with something but it changes a lot even if I just plug a simple wire on it, without touching it. Alexis has decided to take the board and try and understand this problem.

Thus, today, I didn’t work on the electrode part, but I have coded the sensor detection thread. Basically, when a player puts his thumb on the sensor, if he lets it enough time on the sensor, it means that a gesture spell will be done. During all the spell, the player has to let his thumb on the capacitive sensor. Once the spell finished, he just has to release his thumb of the sensor.

Moreover, I have corrected small bugs on the 3D model of the wand and we have printed it. For your enjoyment, here are some pictures of our wand (it’s the debug version, we’ll improve the design later 🙂 ).

20150411_21254920150411_21240920150411_212722
See you !

Visual over the IMU

Hi,

here is to tell what I have been busy with during the last few days. For a few hours I have tried to enable the I2C communication with our capacitive sensor, but my main concern has been toward configuring the IMU and getting a visual over its rotations to check the referential’s axis. A movie is better than a long post so check out my video !! I have to tell it wasn’t easy, I used pyqtgraph for the graphics  and the quaternion data given by the IMU in fusion mode to get the rotations (much easy to use than the euler’s angles I tried to calculate and represent before, wasting quite a few hours !!)

Hugues

Capacitive electrode and the wand

Hi,

I’m currently dealing with the creation of a capacitive button. Since yesterday, I can talk with the capacitive sensor controller and thus, I can read the state of a specific sensor that I’ve configured as a button.

The problem is that as soon as I plug something on the sensor pin, I got the maximum value when I read the sensor output, in counts unit. I have tryed and tunned different configuration registers but I still got the same issue.

I was using a simple iron wire with a circular copper welded on one side, and the controller sensor pin on the other side. In general, the electrodes are directly over the PCB but in our case, we want the electrode to be remote from it. So, I think that the design of the electrode wasn’t good there is no ground close to it. I am presently reading the doc more carefully and I will try an other electrode design tomorrow, based of the information that I found on one of the datasheet.

Lastly, two wands have been printed but they have been a little deform, because of they’re position during the printing, implying difficulties to fit together the different parts. Mickael has adjusted some parts of the wand this evening to avoid this problem during the next printing of tomorrow.

You can see below 3 members of the Expelliarose team and the actual printed wand.

IMG_20150409_215646

Good night !

A week in the BLE desert

Long time no post, because, well, I didn’t feel like bragging about my struggle with the Nordic chip.

But here we are. Let’s make the most of it! The mission (I accepted): building the communication between the STM32 and the user’s client (a bluetooth low energy device).

Quick reminder: we had decided to use a SPI bus to connect our STM32 and the Nordic nRF51822 chip. But since we only added one chip select wire, we realized our schematic didn’t fit our purpose: both chips should be able to act as master and could want to initiate a transaction. Hence the decision to go back to the UART (we’d planned this, but not thoroughly enough: the RTS and CTS pins are not mapped, so we’ll lose the hardware flow control).

Starting from there, and discovering with enthusiasm that the last Nordic SDK 8.0.0, freshly released, was compatible with our evaluation board (PCA10001, embedding the same chip than us), I developed a custom 8.0 BLE service (with the numerous Nordic examples as a base). Continue reading A week in the BLE desert

Communication I2C with the capac sensor controller

Hello,

Yesterday, I have worked on the I2C communication with the capacitive sensor controller.
I got a problem because I received a NAK when I tried to read or write a register but, thanks to Samuel, I finally solved it. In fact, the device, after receiving its address, wakes up but sends a NAK. It expects the master to retry the transaction until it accepts it.
Now, I can read and write any registers and I’m tackling with the sensor itself, by creating a capacitive button with some copper 🙂

About the wand, we had to make some changes on it, because it has been a little deformed during the last printing. It is currently being printed and we will share some pictures of it tomorrow 🙂

See you !

communication with the imu

A short post to say that i can now access the imu’s registers for writing and reading from the shell. So it s all going well, i need now to learn how to get the right configuration and also find something to have a visual of the movements of the imu, apparently opengl would be a good idea.

Hugues 

3D model of the wand

Hi,

During several days, I have worked on the establishment of a 3D model of the wand. I used Solidworks for that.

Our wand is actually composed by 4 parts :

  • a handle with some holes for the USB plug, the ON/OFF switch and other things. There is a recess to know how to catch it with your hand.
  • a central part to principally support the LED strip
  • an external shaft to hide the LED strip
  • th tip which contains the IR receivers and the emitter, and also a RGB led

The handle and the external shaft are linked thanks to the central part. In fact, they are screwed to the middle part. The board and the battery are contained in the handle.

3D model of the wand

I have been helped by Mickael during this task for the creating of the thread, for the screwing.

Today, we have launched the printing of the handle and the tip and tomorrow, we will launch the rest.

 

You will be kept in date of the progress of the printing with some other pictures. BYE BYE !