gbadev.org forum archive

As a sequel to the GBAccelerometer, I have made a motion sensor for the DS. It plugs into slot 1 just like a DS card, and contains a tri-axis accelerometer AND a single-axis gyroscope. This means that it can sense motion (like the GBAccelerometer), tilt (like kirby tilt-n-tumble and yoshi topsy turvy) and twist (like warioware twisted).

I have placed an order for the circuit boards and plastic cases, and it will be about 1-2 months before these are completely done. When they are done, they'll be available for sale for around $25 each.

To help jumpstart the development of motion sensitive DS games, I'll be giving away some DS motion sensors to developers who are interested. If you would like one, post your plans for using it and I'll pick the best ideas to recieve a free device.

Another opportunity to get a free device would be to help me come up with a name. Post your ideas here for a name, and I'll choose my favorite. My default choice right now is DS motion sensor, but somebody must have a better idea than that.

I also need labels for these devices. I've found a local source to do the printing, but I need help with the graphical design. If you are interested in doing the design, send me a PM. I'll give you a free device for your work.

edit 12-8-06: The name and graphics are finalized, and there is now a website.

Last edited by KeithE on Fri Dec 08, 2006 5:35 pm; edited 1 time in total

I have a couple of ideas for both name and graphical design. What is the size of the labeling/box art you will need?

I can see some serious potential for using this in conjunction with any Wii homebrew to combine both motion sensor technology and drawing in the same fell swoop. (think like Lost Magic + Proper aiming of spells) Of course, that would be quite the achievement for any hobbiest programmer to pull off though...

-gamefreak
_________________
What if the hokey-pokey really is what it's all about?

[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]

The labeling will be on the card only - no custom box.

DSensor
DSensitive
MotionSensitive
Twist'n'Tilt
DS MotionSensor ( :P )
Motion Add-on for Nintendo DS
...

:(
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

MotionSensinator
DSMotion
MotionDS
MotionDSensor
MotionDsenSor
GyroSense
GyroDS
DSGyro
Tilt'n'DS
GyroTilt
NDSTilter
NDSGyro
NDSensometer
GyrometerDS
DSAccelerometer
Wiimulator (get it? wii + simulator? cause it simmulates the motion sensors of the wii? ha ha)

Hello,
Your GBAccelerometer looks like it would have been fun to program for; a shame it doesn't fit on the NDS, but I guess this solves that problem. Kudos for homebrew hardware!

Right now I'm designing a DS rhythm game--perhaps on a similar vein to Elite Beat Agents, or maybe not--which would come with the ability to upload songs and design your own patterns for them. I can think of some neat percussive motions that could be detected with such a cart.

As for names, the only ones that springs to mind involve the good old *Me convention (TiltMe, TwistMe, MoveMe, etc.)
Hope this helps!

I was actually planning on using Natriums42 DSserial to make some tilt sensor demo's and games, porting it to your board would certainly broaden compatibility
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

Plus I don't believe DSerial is planned to sell with the tilt sensor on the standard board.. I could be wrong, but it's not shown as one of the things soldered on the video.
_________________
NDS Homebrew Roms & Reviews

I would like to update SpoutDS to support this.
_________________
GTAMP.com/DS

Actually, I have already updated SpoutDS to support the DS motion sensor. It changes the gameplay a bit - adds an interesting twist :) It is the only game that I have modified to use the DS motion sensor so far.

The first demo I made with it was to modify Davr's water drop demo so the water drops move across the screen in the direction of the tilt, and bounce off the edges. It has a good feel to it, and people who have tried it are immediately captivated.

To the folks who are PMing me with your game ideas - thanks for sending them, but please post them here - maybe your idea will inspire others.

Thanks for all your comments so far - it is great to hear the enthusiasm!

That sounds really cool. :)

On a bit of a side-note, about a week ago (or so) I spotted this:
Please use [url=] syntax for long URLs -- MOD

That guy also did some other interesting stuff (I've been checking out his things for a while now):
Please use [url=] syntax for long URLs -- MOD

Sorry for taking away the attention a bit, like I said, sounds really cool. :)
Can't wait to see/try it. :P

Heh, the guiding ball around holes game would own with a tilt sensor. Didn't someone make a ds tilt sensor with a box over the touchscreen with a ball inside? Or maybe that was april fools or something...
_________________
"no offense, but this is the gayest game ever"

DMotion (Demotion)
DSensor (Decensor)

Hey look, first post.

I must say I'm surprised nobody's said the obvious yet. Since it combines two sensors, call it DualSensor. One possible use is a GPS system in a car, which can detect if you've fallen into a ditch or rolled over (tilt sensor) and call for help, either by VoIP or being connected to a cell phone via serial port. (It DOES have a serial port, right? Pleeeease? :p If not, hack it into the GBA slot instead.) It could also tell you if you're speeding. Similarly you could put it in your pocket to have the tilt sensor act as a pedometer.
Heck, combine this with the thermometer already in the DS and it could control the car's heating system - maybe turning it on soon before you leave for work (most cars have an AC-powered heater for the Winter) - or notify you if you're in danger of hypothermia while you're out hiking. A device that tells you where you are, how fast you're going, how many steps you've taken, what the time and temperature are, and can be used to communicate - even with voices - over wifi would be pretty damn handy to have during a hike in the woods or a drive in these harsh Alberta winters. It could even use the speakers and backlights to flash/beep out an SOS if you get trapped somewhere. :p
(I know you didn't mention a GPS system - I misread it - but you could stick one in the GBA slot or fake it by having the user tell it where they are and then tracking where they go from there with the accelerometer. Or you could add a GPS tracker because that'd be awesome.)

Games? You could make all sorts of fun games out of it. Perhaps a minigame in which you prepare food - use the stylus as a knife, put things in a container and shake it, and twist to simulate twisting the objects (EG to squeeze juices out of something). Or a driving/flying game in which you can steer by tilting and/or twisting the system. Perhaps a pinball game; I always wished Mario 64's pinball minigames were tilt-sensitive, and twisting the table could be interesting too. Maybe draw by tilting to roll around a ball of ink. Tilt-activated scroll bars. All sorts of fun things you can do here.
_________________
I'm a PSP hacker now, but I still <3 DS.

Actually, to go along with the GPS idea, it can be used for speed and direction calculation. As GPS is only accurate up to a meter or something, I know my brothers GPS system has a gyro as part of it for those calculations as well..

As for device names, here are some:

Twister (Could make for nice logo possibilities)
Tilt-R-World (Tilt your world/Tilt are world)
Tilt FX
Twist FX
G-FX
G-Force

Then, to follow the croud (Meaning major company names):

Tilt Plus
Tilt Pro
Tilt XP
Tilt Extreme
Tilt XT (extreme technology)
TTX (Twist/Tilt Extreme)
Tilt 4D (4th dimension?)

Swap the Tilt with Twist for any of those, as well as add NDS in front/behind any/all as well.

And just for old time sake.. I know Natrium42 will LOVE these! :)

TwistMe
TiltMe
ShakeMe
SpinMe
ShoveMe
LiftMe
BounceMe
SwingMe
Don'tDropMe

Those are a joke.. PLEASE do not use any.. *Me is TM of Natrium42 (C) Enterprises (R). All rights reserved. No PassMes were harmed in the posting of this message.

Edit: Oh.. I forgot game ideas.. not that I can program to save my life, so these are open to anyone.. :)

Of course, a driving game, where you tilt to steer.. that would be cool.. But, for a game that doesn't concentrate on the sensor (meaning playable without it or a cool add-on) would be a pinball machine that you could "help" the ball.. of course with a TILT light.. :)

My bad.. didn't see the idea in the previous post.. :P
_________________
NDS Homebrew Roms & Reviews

Heres some ideas.

DSoTilted
DoSpin

DShaker

DSensitive

MoboDS

Mobolity Does Sound (good)
MDS

DoSpinMe

Just a few random ideas.

BTW, what sizes are you looking for for the graphics?
I'll try making a few :3

Lots of great suggestions so far! Thanks for all the input. I can't wait to finish this product and see the software that gets developed around it. I'm in discussions with a retail website to host a motion sensitive GBA/DS game competition when the hardware is ready.

Unfortunately, there is no serial port, just the two sensors. Maybe my next project will be a motion sensor for the GBA slot.

For the graphics, here are some requirements:

Same size as a standard DS card label.

The graphics need to be in vector format, illustrator version 9 or earlier (these are requirements of the printer)

Must have the name of the product, and "Motion Sensor for NDS" if the name does not end up being "DS Motion Sensor"

KeithE: I'm a student of the university of technolgy, Delft, where I am currently working as a teacher's assistant. We are teaching a course in wich students have to use an embedded linux and an accelerometer to write pedometer software. They have to measure distance walked with the portable device by some means of counting steps (simply integrating the acceleration twice is impossible because the error introduced by the accelerometer chip explodes over time).

I just heard about GBAccelerometer, and I ordered one immediately. I will port my version of the software as soon as I get it in the mail.

Given that the system has been properly-calibrated, the error of the measured distance is about 3%. This means that over 100 meter walked, it will register somewhere between 97-103 meters.

I have a DSLite and M3 card as well, so if you want me to create a DS version of this thing feel free to send me one. I can't really think of any interesting use of this algorithm, unless you would add a digital compass. In that case you could calculate the actual position of the person in the 2D plane. Combine that with WiFi and you can make some really interesting real-life games like virtual pacman/bomberman, in wich you can move the character my actually walking in a certain direction and turning.

If you feel like talking about it, you can concact me at niels.brouwers at gmail.

Well, nice to see your new product Keithe ;)
I think a nice project will be to adapt my arcade emulator MarcaDS with your ds sensor (playing the real arkanoid arcade game with it will be great :-) ).
For the name of your new sensor ? well, here are some ideas :
Sensorometer,
Tiltometer,
Gravitor,
GyroWheel,
with DS or not in front of the name :D !

My ideas for it's name:
MoveIt!
DSpin
RotateDS
GraviDS
DS Force

I'll want to make this game: there will be a rotating line and you have to rotate your DS to keep the line horizontal. And there will be some bonus things like: rotate your DS 360? in 2 secs to get 1000 points, etc..
And I'm thinking about a multiplayer game too: Spin-Pong :)
Another idea (I don't know it's name, you have to move the 2 balls to the 2 holes): [Images not permitted - Click here to view it]

Just popped into my head! SOMEONE MUST MAKE THIS (not that I would actually play it, but still).. :)

TEMPEST!

It's like the game was designed for this product! :D
_________________
NDS Homebrew Roms & Reviews

Keep the name simple, unlike all the other DS software and hardware which makes learning it half-impossible to keep straight in your head. >_<

DSMotionSensor or MotionSensorDS would be fine.

its a very interesting gadget for the nds

names? try these

1: TRI-MO (3d rotating motion)

2: TILT-O-metric ?

3: MOVE-IT! (tilt,shake,...whatever) (didnt realise its already used but ill place it here anyway)

4: Reacto - DS

5: Interacto -ds

happy choosing :P

I plan on using it to make an in car diagnostic tool showing the forces acting upon the car as it moves around. I could use a 3d car model to show the rotational forces acting upon the car.

It will be fab.

I cant wait for it.
_________________
--------------
^thom(as)?
--------------

Another fab idea!

I could use it for fractal landscape generation. Using a random midpoint displacement algorith, I could get the displacements from the z reading.

when generating the landscape the more you shake the device the more rough and random the terrain is. :D

i cant wait to mess around with this device.
_________________
--------------
^thom(as)?
--------------

Hm, nice idea. Use the tilt sensor for random seeds.
_________________
I'm a PSP hacker now, but I still <3 DS.

DS-TS
_________________
Not active on this forum. For Lemmings DS help see its website.

HyperHacker wrote:

Hm, nice idea. Use the tilt sensor for random seeds.

With the wifi, you could send any randomness you generate to a pc or webserver, perhaps you could use it to generate one time pads.
_________________
--------------
^thom(as)?
--------------

Name suggestions:
the name should sound cool or high-tech, nothing like 'tilt-o-rama'
DS++ (already been used?)
PhysiDS
D.S.P.*blank* - DS Physics (Amplifier, Augment, Boost, Accessory, Attachment, Component... the list goes on)
NDS Ph. D - Nintendo DS Physics Device
M. D. NDS - Motion Device NDS (Dr. NDS)
other possible D names for NDS Ph. D / M.D. NDS:
Dingbat
Doodad
Developer

I think it should have something to do with physics or something...
As for games the obvious things would be like racing, tilting ball games, basically anything on the Wii that doesnt use the pointer feature, naturally i dont think anyone wants to swing thier ds around like a sword though. But multiplayer might be cool, with local DSes that have the sensor in them and could tell the relative position of each player somehow, you could then have some kind of a fight with the DSes, making certain motions or something. I dunno, someone else could expound on that idea. Maybe single player would have to be in an open space and the screen would show your position and the positions of enemies/items and you would physically walk to move the player, and make gestures to do certain actions. I dont program DS homebrew yet so anyone is free to that idea.

Sounds like a great piece of kit, really looking forward to seeing it being used.

Given it's similarity to the Wii remote and freedom of 3D sensing here are some suggestions around on the words 3D, Free and Wii...

FreeDS (or Free-D-S)
FriiDS (or Frii-D-S)
Frii

Will there be something for people that have a slot 1 flashcart, like dslink or ds-xtreme? (I have a dsx)

I'd like to make a labyrinth game. The more I think about this the more ideas I have. I have an idea on how to control it with a stylus as a backup if you don't have the motion sensor.

Last edited by sirpoonga on Mon Nov 27, 2006 9:11 pm; edited 1 time in total

I don't have plans for one at this time. Maybe in the future.

Once the game is loaded from the dsx, can you remove the dsx from slot 1 without crashing the game? If so, you can insert the DS motion sensor after removing the dsx. The game could have a prompt to remove the dsx and insert the motion sensor, then press a button to continue.

That may work if there was no need for sram or fat. When I get home I will have to pull the dsx out with my current project and see.

However, if a program requires sram or fat (like to save settings/progress) I can see that being a problem.

I gave it a try. You can pull the dsx out and a program will continue running (because it is loaded into the ds memory). However, if you had to access fat it will fail. Since the dsx is a slot 1 solution there is no sram.

So, once the dsx is pulled out there is no way to save data unless you have a slot 2 device.

dude, that tottaly rocks! I've worked on an mathematic algorithm on a research at college to remake a movement based on the accelerations and rotations measured by an inertial accelerometer, but I got the algorithm but no accelerometer! that's my chance to try out my algorithm!

I'd like to make some questions, though:

- What does it measures? it measures the acceleration on the 3 axis and the rotation speed on one axe, is that it? I really wanted it to measure the rotation speed on the 3 axis too, that would make using my program possible!

- what is the measuring frequency? how many data per second can I get? the one I got the data from was 20 Hz, i.e., I got 20 different data on one second.

- doI qualify as a developer that you would give one of these? xD

You are correct - it measures 3 axes of acceleration and 1 axis of rotation. If you want to measure more than that then you should look into the DSerial, to which you can add as many sensors as you want.

The maximum sampling rate is limited by the communication port speed and the number of bytes that need to be exchanged. It is well over 200Hz, though I have not measured exactly what the maximum is.

What application are you planning to make - I'm only donating them to people who have a specific project in mind and have the skills and desire to complete the project.

In other news, I have finalized the name (DS Motion Card) and graphics, and put up a website that describes the product.

I think it would be really awesome to have a dodge-em type game in which you actually have to run around with your ds to dodge things. I'm sure it would not be particularly safe but oh well... as soon as I get my hands on one of these I will try to figure it out.
_________________
www.thrivepresents.com
palib.dustin.info

Heh, that could be interesting. You'd have to pay attention to two worlds at once to make sure you don't run into something in either of them. :p
_________________
I'm a PSP hacker now, but I still <3 DS.

After some more testing I don't see a way to remove the dsx and reinsert it without the ds rebooting. I would really like to do a labyrinth game using this motion sensor. I will still probably make it but it will use the stylus to move. I will keep the code open to having another control device just incase...

So, DSX doesn't just load the homebrew rom into RAM and leave it at that? Removing the DSX causes the DS to restart? Nice "feature".. :/
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

Removing the DSX causes the DS to restart? Nice "feature".. :/

But it's a similar "feature" that allowed us to learn firmware versions anyway.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Lynx wrote:

So, DSX doesn't just load the homebrew rom into RAM and leave it at that? Removing the DSX causes the DS to restart? Nice "feature".. :/

No, reinserting the dsx reboots it.

So one could make a game that uses the motion sensor. however,you couldn;t save anything, like calibration settings.

That could just be poor handling of the cartridge interrupt in your program.
_________________
I'm a PSP hacker now, but I still <3 DS.

Ahh.. That's not so bad. You could always save settings using WiFi ;) We need more WiFi enabled games anyway.. :)
_________________
NDS Homebrew Roms & Reviews

i noticed the supercard does it also, perhaps it has to do with the amount of power the cart draws
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

My proposed names are:

The DS FX (DS Flux X-aminer)
The DS (Dynamic Sensor)
The WF (Wave Flicker)
The DF (Dual Flick)
The DF (Dual Force)
The FF (Flick Force)
The DF (Dynamic Force)

Also, for the graphic design, I'd say that a really wicked tornado with strong streaks leaving it and destroying stuff around it would work. The destruction wouldn't even be needed, just a wicked tornado with the strong streaks would do the job.

I'm not an expert or even decent at programming. I'm learning how to do it now, but I've been a gaming for 14 years, I have some pretty solid ideas for a few games.

A racing game. The top screen is used for a map, stats, and speedometer. The bottom screen will be used to show a 3D representation of the track and your vehicle, along with the other's you're racing against. Motion will have you turn, depending on the speed of the motion and the direction. The L and R buttons will be used as the fire and the sharp turn buttons respectively. The d-pad will be used to increase and decrease your speed, and to swap between weapons. The game will have a decidely Diddy Kong Racing feel. The touch screen will be used to aim your weapons, choose your targets, change course paths, and change the way your weapon is used (every action depends on the context of the game).

A switchable topdown/quasi-3D shooter. The motion controls the camera when in the 3D mode, and in the 2D mode it controls the blades (the wings of the ship are used as swords/blades). The D-pad controls the movement of the ship in 2D, and in 3D it controls the speed and and weapon switching. The R button will be the firing button in both modes, and the L button will be the turbo boost in 2D (in 3D it's the shield). In 3D the touch screen aims by controlling the camera, in 2D it creates the shield. The shield will be limited in use. By holding down on L the shield stays in effect longer, double tapping causes it to grow. When done on the touch screen the the shield is increased in size by making constant circles.

I hope to use my knowledge of DarkBASIC to learn the programs needed for programming on the DS. If I can't program, I'd certainly like to help someone make these games or something like them. These were only brief descriptions of their controls and genre's. I have many more ideas relating to them that i havn't posted.

Also, when I read about the motion sensor it got me excited, I hope someone makes some good use of it. Also, will the sensor ever be able to double as a passcard, or will it be swappable with a passcard so that you can use it and the device people use for homebrew?

srkelley wrote:

The L and R buttons ... The d-pad ... The touch screen

How do you plan to use L, R, D-pad, and touch screen all at the same time? You'd need 3 hands at least.

Quote:

Also, will the sensor ever be able to double as a passcard, or will it be swappable with a passcard so that you can use it and the device people use for homebrew?

Just install FlashMe, then you won't need a nopass/passme at all for anything.

josath wrote:

srkelley wrote:

The L and R buttons ... The d-pad ... The touch screen

How do you plan to use L, R, D-pad, and touch screen all at the same time? You'd need 3 hands at least.

Left forefinger on L, left thumb on the +Control Pad. Right forefinger on R, right thumb on the right 24 pixels of the touch screen, sliding up and down.

Quote:

Also, will the sensor ever be able to double as a passcard, or will it be swappable with a passcard so that you can use it and the device people use for homebrew?

Just install FlashMe, then you won't need a nopass/passme at all for anything.

But will it be swappable with a microSD adapter in SLOT-1? Or do you claim that SLOT-2 flash cards will remain easy to find even as the GBA becomes obsolete?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Left forefinger on L, left thumb on the +Control Pad. Right forefinger on R, right thumb on the right 24 pixels of the touch screen, sliding up and down.

Yup, we forget about that thumb thingy that came with the DS.. :)
_________________
NDS Homebrew Roms & Reviews

For those who were wondering...

The DS Motion Card is not vaporware!

Pictures of the assembled PCBs are now posted on ndsmotion.com. Samples have been tested and they are working great!

The circuit boards will be assembled in card shells, labels will be applied, and they will be shipped out by the end of December.

HyperHacker wrote:

Perhaps a pinball game; I always wished Mario 64's pinball minigames were tilt-sensitive, and twisting the table could be interesting too. Maybe draw by tilting to roll around a ball of ink.

Pinball thread.

I think a tilt space shooter would be neat. Tilt to move. Move the unit up and down to move between upper and lower planes. Allow the player to use the buttons as a weapon palette. Rotate the map by rotating the unit.

A mode 7 flight game would be cool. Same controls as above, except that you rotate the unit to turn and raising/lowering the unit changes your elevation.

General notes:
I have not put too much thought into it, but auto calibration seems like is should be possible. So far as I can tell, gravity can be used as a unit vector to determine the orientation of unit, assuming that it is not moving. Calibration issues: There are top and bottom loading units. No side loading units yet, but someone could always play while laying on their side.

General worries:
Glare. Motion noise while riding the bus or train. Units oriented sideways. =) Earthquakes. =P

-Brendan

Unless you live in Japan, an earthquake is probably a good time to pause the game for a while. ;)

sgeos wrote:

I have not put too much thought into it, but auto calibration seems like is should be possible. So far as I can tell, gravity can be used as a unit vector to determine the orientation of unit, assuming that it is not moving.

Would it not have to be falling?
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

Unless you live in Japan, an earthquake is probably a good time to pause the game for a while. ;)

=)

HyperHacker wrote:

sgeos wrote:

I have not put too much thought into it, but auto calibration seems like is should be possible. So far as I can tell, gravity can be used as a unit vector to determine the orientation of unit, assuming that it is not moving.

Would it not have to be falling?

Depending on how you look at it, everything subject to gravity is always falling. Other objects often get in the way, so they may not move. Accelerometers measure acceleration. Gravity is acceleration. Accelerometers measure gravity.

From the readme:

readme wrote:

The DS Motion Card is a Kionix KXPB5 tri-axis accelerometer and Epson XV-3500CB single-axis gyroscope that can be connected to the Nintendo DS and DS Lite through the DS card slot. It can be used to create tilt/rotation/motion sensitive games and applications.

KXPB5 Product Sheet
XV-3500CB Data Sheet

readme wrote:

with the DS sitting flat on a table, the X-axis and Y-axis experience zero acceleration, so the X-axis and Y-axis outputs are both 2048. The Z-axis experiences one g of acceleration, so the Z-axis output is 2867 (2048 + 819).

Accelerometers measure gravity. The single downward g is going to change direction (the axes it manifests itself on) as you tilt the unit. Any other movement will cause movement noise though. Using the unit in an accelerating vehicle will also cause movement noise because accelerometers detect acceleration.

The DS motion card on has one gyro sensor that measures rotation around the bottom of the unit? This seems to assume that rotating the screen is the only type of rotation one would like to do. I'd like to detect rotations around the gravity vector. Is there any way to do using the current hardware?

Picture a scenario where a person plays with the screen parallel to the wall. What are the "natural" controls? What can atually be detected? So far as I can tell, I can't detect rotations toward and away from the wall, because that plane is perpendicular to the gravity vector and the gyro sensor operates on a different axis.

-Brendan

Quote:

Depending on how you look at it, everything subject to gravity is always falling. Other objects often get in the way, so they may not move. Accelerometers measure acceleration. Gravity is acceleration. Accelerometers measure gravity.

oO

Gravity is a force.
Acceleration is the effect of all summed forces on speed.

(Alltho usually accelerometers dont measure acceleration but directional forces on a known testmass against a piezo electrical element.)

When falling is the moving in the direction of the force gravity, then no, things are not allways falling. Unless you define "it could be falling" as falling itself ...
_________________
GBAMP Multiboot

Quote:

The DS motion card on has one gyro sensor that measures rotation around the bottom of the unit? This seems to assume that rotating the screen is the only type of rotation one would like to do. I'd like to detect rotations around the gravity vector. Is there any way to do using the current hardware?

The gyro can only measure rotation around one axis that is fixed relative to the DS. If the DS is sitting flat on a table, then the gyro measures acceleration around the gravity vector. In any other situation, there is no way to explicitly detect rotations around the gravity vector. To do that, there would need to be three orthogonal gyros. Then you could measure the tilt angle with the accelerometer, and combine the gyro outputs in the appropriate way to calculate rotation around the gravity vector

Quote:

Picture a scenario where a person plays with the screen parallel to the wall. What are the "natural" controls? What can atually be detected? So far as I can tell, I can't detect rotations toward and away from the wall, because that plane is perpendicular to the gravity vector and the gyro sensor operates on a different axis.

Actually, in this case you could detect rotations toward and away from the wall by using the Z-axis of the accelerometer. Flat against the wall, the Z-axis has no acceleration on it. Tip it one way and acceleration goes up, tip it the other way and acceleration goes down. So - accelerometers can measure rotation too - pitch and roll, but not yaw.

Yes, gravity can be used to calibrate the unit - either set it flat, or hold it in a desired orientation that you wish to be considered flat.

If you drop or throw the DS Motion Card, all three accelerometer axes will indicate zero acceleration. When it is stationary (or moving at constant linear velocity), in any orientation, the vector sum ( sqrt(X^2 + Y^2 + Z^2) ) will be equal to 1 G (gravity, or 9.8 meters per second squared).

This could be used to make some sort of "hot potato" game or some other game that sense when the DS is being thrown - anyone up for tossing their DS around?

Pinball sounds like a great idea!

KeithE wrote:

Yes, gravity can be used to calibrate the unit - either set it flat, or hold it in a desired orientation that you wish to be considered flat.

To further this idea. The labyrinth game I am working on you will have to hold the DS "level" and press a button to start.

Mighty Max wrote:

When falling is the moving in the direction of the force gravity, then no, things are not allways falling. Unless you define "it could be falling" as falling itself ...

Right. It all depends on how you look at things. I was looking at things like this: "I would be moving toward the center of the Earth if the floor wasn't in the way."

KeithE wrote:

Quote:

Picture a scenario where a person plays with the screen parallel to the wall. What are the "natural" controls? What can atually be detected? So far as I can tell, I can't detect rotations toward and away from the wall, because that plane is perpendicular to the gravity vector and the gyro sensor operates on a different axis.

Actually, in this case you could detect rotations toward and away from the wall by using the Z-axis of the accelerometer. Flat against the wall, the Z-axis has no acceleration on it. Tip it one way and acceleration goes up, tip it the other way and acceleration goes down.

My bad. In this case, tilting the top and bottom of the unit toward the wall can be detected. From what I gather, tilting the sides of the unit toward the wall is undetectable.

KeithE wrote:

So - accelerometers can measure rotation too - pitch and roll, but not yaw.

Yaw is not reflected by the gravity vector. Reading the gravity vector strikes me as the easy way to figure out the orientation of the unit.

KeithE wrote:

Yes, gravity can be used to calibrate the unit - either set it flat, or hold it in a desired orientation that you wish to be considered flat.

Gravity can tell the unit which way is down. At this point, up becomes obvious. Left, right, forward and backward don't seem to be. At least not in a forward compatible way (side loader; worse- top of cart is parallel with screen). If a unit with a strange loading orientation appears on the market, manual calibration seems like it will be necessary. Otherwise manual calibration seems like it should be possible. I'll admit that I may have missed something.

Assuming that I have my coordinate systems right (GBA is left handed), the gravity vector in the GBA-screen coordinate system is usually going to be some combination of negative-Z and positive-Y. (I personally prefer something closer to positive-Y). This should be obvious, but consider that the gravity vector can be any (combonation) of the following: positive/negative-X, positive/negative-Y, positive/negative-Z. Negative-X is odd, but I've seen it happen. Positive-Z... happens, and probably more often.

In practice a fixed gravity vector is often assumed. I think it would be neat write programs that are responsive enough to deal with strange gravity vectors. Assuming that we are working in real world coordinates (the ground is down and the sky is up), pitch and roll can be calculated from the gravity vector. Given the current design, yaw can only be calculated when the screen is parallel to the ground. If yaw can only be calculated given two definitions of down (GBA positive/negative-Z), there will be times and locations (overhead lights) where the game will not be playable due to screen glare.

Quote:

If you drop or throw the DS Motion Card, all three accelerometer axes will indicate zero acceleration.

Interesting.

Quote:

When it is stationary (or moving at constant linear velocity), in any orientation, the vector sum ( sqrt(X^2 + Y^2 + Z^2) ) will be equal to 1 G (gravity, or 9.8 meters per second squared).

Goofy question- if the KXPB5-2353 has a target sensitivity of 819 counts/g, how far from the earth does one have to take it for gravity to register as 818 counts? (Not that is matters at all. I'm sure the meaningful answer is "far".)

Quote:

This could be used to make some sort of "hot potato" game or some other game that sense when the DS is being thrown - anyone up for tossing their DS around?

Adults would be fine, but a group of 8-year olds would end up breaking something. I doubt that DS hot potato would be approved. At least I hope not. (Closing the DS can be polled just like any other button. Using that as gameplay input is currently discouraged. It was used in one game.) I think it would be funny to play a "please don't throw me" sound effect. =)

-Brendan

sgeos wrote:

oofy question- if the KXPB5-2353 has a target sensitivity of 819 counts/g, how far from the earth does one have to take it for gravity to register as 818 counts? (Not that is matters at all. I'm sure the meaningful answer is "far".)

+ 3897.3m When 819 counts is the exact measurement at 6.378km above earth middle. (at 0? latitude) not taking into account radialforces from the earths rotation.
_________________
GBAMP Multiboot

Sgeos, it's great to see that you have been thinking about this so much.

Quote:

My bad. In this case, tilting the top and bottom of the unit toward the wall can be detected. From what I gather, tilting the sides of the unit toward the wall is undetectable.

Yes, you are correct.

Quote:

Yaw is not reflected by the gravity vector. Reading the gravity vector strikes me as the easy way to figure out the orientation of the unit.

Yes, correct again.

Quote:

Gravity can tell the unit which way is down. At this point, up becomes obvious. Left, right, forward and backward don't seem to be. At least not in a forward compatible way (side loader; worse- top of cart is parallel with screen). If a unit with a strange loading orientation appears on the market, manual calibration seems like it will be necessary. Otherwise manual calibration seems like it should be possible. I'll admit that I may have missed something.

I'm confused about your question. Slot-1 on all DS consoles is in the same place, so left/right is always X-axis, up/down is always Y-axis, and perpendicular to the screen is always Z-axis.

Quote:

Given the current design, yaw can only be calculated when the screen is parallel to the ground. If yaw can only be calculated given two definitions of down (GBA positive/negative-Z), there will be times and locations (overhead lights) where the game will not be playable due to screen glare.

You are correct - yaw relative to the earth is measured by the gyro only when the screen is parallel to the ground. But yaw relative to the earth is probably not that important to be able to measure in most situations. Yaw of the DS around an axis perpendicular to the screen is what is most useful, and that is what the DS Motion Card measures. For an example, take a look at the DSaSketch demo on ndsmotion.com. When you get a DS Motion Card, try out that demo - it has a great feel.

Mighty Max wrote:

sgeos wrote:

Goofy question- if the KXPB5-2353 has a target sensitivity of 819 counts/g, how far from the earth does one have to take it for gravity to register as 818 counts? (Not that is matters at all. I'm sure the meaningful answer is "far".)

+ 3897.3m When 819 counts is the exact measurement at 6.378km above earth middle. (at 0? latitude) not taking into account radialforces from the earths rotation.

Achievable in an airplane, although a few counts shouldn't break a game. Would an accelerometer face any special problems in an airplane? Turbulence comes to mind. I think they generally fly at constant speeds, although changing altitude could be interesting. (Due to the DS's wifi, using it in an airplane is a bad idea. Don't do it! =)

KeithE wrote:

Quote:

Gravity can tell the unit which way is down. At this point, up becomes obvious. Left, right, forward and backward don't seem to be. At least not in a forward compatible way (side loader; worse- top of cart is parallel with screen). If a unit with a strange loading orientation appears on the market, manual calibration seems like it will be necessary. Otherwise manual calibration seems like it should be possible. I'll admit that I may have missed something.

I'm confused about your question. Slot-1 on all DS consoles is in the same place, so left/right is always X-axis, up/down is always Y-axis, and perpendicular to the screen is always Z-axis.

I'm considering two issues.
A) In the past, motion sensing games have been made that failed to be future compatible because they made assumptions about the hardware. It really only affectes used game sales, so from a business perspective it doesn't really matter. I still think it's a bit of a shame, and the same thing could happen again.
B) I've been thinking about motion sensors in general. Depending on how it was implemented, a slot-2 device might have to consider different orientations.

Quote:

Given the current design, yaw can only be calculated when the screen is parallel to the ground. If yaw can only be calculated given two definitions of down (GBA positive/negative-Z), there will be times and locations (overhead lights) where the game will not be playable due to screen glare.

You are correct - yaw relative to the earth is measured by the gyro only when the screen is parallel to the ground. But yaw relative to the earth is probably not that important to be able to measure in most situations. Yaw of the DS around an axis perpendicular to the screen is what is most useful, and that is what the DS Motion Card measures.

It depends on what you want to do, but I think you are right. Yaw relative to earth means that the unit is being rotated/tilted relative to earth. Rotation/tilting relative to the screen is more intuitive.

For a space shooter type game, I'm currently considering tilting the GBA XY plane and measuring motion along the Z axis. Rotation around the Z axis could also be neat.

Neat idea for pinball- the ball always falls "down". Down is down- either toward the player or the floor depending on how you hold your DS. Thing is, you can rotate the machine. =) This is at least 100% within the hardware spec.

A couple of other crazy ideas-
A) Move the GBA in the XY plane to scroll a map.
B) (Commercial only, do to wifi communication.) Treat each DS as a collision sphere in 3D space. Play 3D tag (or the like) by phsically moving/rotating the unit. Rotation changes the viewport angle, while moving in the earth's XZ plane changes in game coordinates. Units sync via wifi and can collide. (Every will need their own real life space to real life collisions. =)

If the DS screen is parallel to the ground and I rotate with myself as the center of rotation, how will the gyro respond? Can this motion be detected? Picture 135 degree lefthand rotation without changing your Earth XZ position. (Aside, Earth XZ is a spherical plane.)

-Brendan

Isn't WiFi only enabled if you choose a WiFi connection? Meaning, it's only in use when the LED is flashing.. so using the DS on a plane should be fine as long as you don't try to use a WiFi game/app.

Quote:

This could be used to make some sort of "hot potato" game or some other game that sense when the DS is being thrown - anyone up for tossing their DS around?

Now that is the best idea I have ever heard.. Someone has got to make it.. If they do, I'll make a video of it being played!! Maybe we can get a "whatmyDSbroke.com" and people can post pictures and videos of what they broke throwing their DS around while playing Hot Potato DS.. :)
_________________
NDS Homebrew Roms & Reviews

Lynx wrote:

Isn't WiFi only enabled if you choose a WiFi connection?

Probably, but I don't know for sure.

Lynx wrote:

Meaning, it's only in use when the LED is flashing.. so using the DS on a plane should be fine as long as you don't try to use a WiFi game/app.

I, for one, would rather be safe than sorry. Even if everything should be OK, you could touch the wrong thing by mistake. (Shouldn't crash the plane, but still.) I guess I don't see anything wrong with books on planes. (I read Machiavelli last flight.)

Quote:

Now that is the best idea I have ever heard.. Someone has got to make it.. If they do, I'll make a video of it being played!!

Here is a simple spec-
0) Close screen to start
A) Start random MP3, Set timer to a random number between 30 and 90
B) When the gravity vector disappears, start the timer
C) Decrement the timer every second
D) When the timer has expired and the gravity vector reappears, play an annoying buzzer sound
E) Open screen to reset

Quote:

Maybe we can get a "whatmyDSbroke.com" and people can post pictures and videos of what they broke throwing their DS around while playing Hot Potato DS.. :)

That would be funny in a mischievous sort of way.

-Brendan

Wifi is only enabled when you enable it, which in official games means selecting the option from the menu somewhere and then answering "yes" when prompted to connect. Leaving it on otherwise would just be draining batteries for no good reason. There was a Japanese airline a while ago that loaned customers DS Lite units for the duration of the flight.
_________________
I'm a PSP hacker now, but I still <3 DS.

The DS Motion Cards are ready! I'll be posting some pictures on ndsmotion.com shortly.

Quote:

Here is a simple spec-
0) Close screen to start
A) Start random MP3, Set timer to a random number between 30 and 90
B) When the gravity vector disappears, start the timer
C) Decrement the timer every second
D) When the timer has expired and the gravity vector reappears, play an annoying buzzer sound
E) Open screen to reset

I think it would be best to decrement the timer only when the device is being held. Then there would be some incentive to throw it quickly.

Great news KeithE !!!
I post also a news on my website :)

KeithE wrote:

I think it would be best to decrement the timer only when the device is being held.

Minimizing cases where the unit is being thrown as the buzzer goes off is the goal only allowing the buzzer to off when the unit is held. Because the unit should spend most of the time in the air, the buzzer will sound most often as the unit is caught. I'm not sure how valuable that really is.

Am I correct in assuming that the accelerometer can distinguish between being held, being thrown, being in midair, and being caught?

KeithE wrote:

Then there would be some incentive to throw it quickly.

I think a timer in and of itself provides incentive to throw quickly. Perhaps something like a three to five second time out rule could keep people from holding the unit. (Hold it for three to five seconds and the buzzer goes off regardless of the main timer.) Then again, a rush timer might just result in more broken stuff. =P

This seems like such an unlikely product it is hilarious, but if a retail version were made would anyone here actually buy it? (It seems like it would need to be packaged with safety warning stickers. =)

-Brendan

Pay for it? Heck no.. Increased chance of stuff getting broken? Heck YEAH! Isn't that part of the fun? :) I guess this game should be called "Nintendo DS Durability Test!" and you can add WiFi to it.. and it can record the number of times (and sensor numbers for impact) the DS hits the floor.. :)

Anyway, They just came in and will start shipping tomorrow! YEAH!

The DSaber demo is pretty cool.. I was walking around hitting stuff/people just to hear the "shwing" sound.. :)
_________________
NDS Homebrew Roms & Reviews

I'm not sure about throwing my DS around, but a motion-sensing bouny-ball that plays sounds and flashes would be a pretty cool toy, if it implemented a hot-potato style game.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Just got mine today. Unfortunately I can't use it until I get my replacement dsx :(

What is the hole in the top of the cart for?

This is just a guess, but the plastic was probably manufactured for a device that used it. As you can see through the case, there is nothing even close to that spot. Maybe it's there to help you get a screwdriver in there if you want to pull it apart. ;)
_________________
NDS Homebrew Roms & Reviews

Lynx is correct. The hole is vestigial.

Very quickly skimmed this thread (and just the other day ordered my Motion Card ;))...

Here's a couple idea's for you:

Physical Breakout

Your DS screens are a view-port into a 3D world.
Just under the screens are semi-transparent blocks which need breaking.

Grab your DS with the Motion Card in, and, just like with a tennis racquet and ball against the ground, you have to bounce the 3D virtual ball against the underside of your DS screens to break the blocks and score points.

The 3D world could be virtually endless, meaning no bounds to playing and movment.
If the DS is tilted when it hits the ball, the ball will (as physics predicts) shoot off on an angle back toward the ground.
The harder you smack the DS down on it, the faster it shoots back to the ground and up again.

All you would have to do is start off by entereing how high from the ground you're holding the DS, then start it up and she's away :-D

3D Model Viewer

Load a 3D model into the view-port and use the DS the walk around it and look at it from any angle you can think of.
Use the DPad (or touch-screen) to rotate the model itself, then keep walking around the object, tilting, twisting and rotating to get a different view :)

Anyhoo, I've also got another idea (much simpler) for the Drunken Coders Compo which I'll release under the GNU GPL after the compo's over ;)

Jess.
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

JessTicular wrote:

The 3D world could be virtually endless, meaning no bounds to playing and movment.

It seems like this would unbound your victory condition as well. I don't think that that is a good thing for a block breaking game.

-Brendan

Win condition could be quite bounded.

Maybe there's a certain number of blocks under your screen you must break... Or, maybe there's blocks that are placed within a 2m square area that you have to break all of...
There's so much you could do because you're building a virtual world ontop of the pre-existing physical ground :)
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

KeithE wrote:

Lynx is correct. The hole is vestigial.

I assume the same goes for the packaging, which is nice.

/me is still patiently waiting for his replacement dsx so he can use this.

Actually, I would like your guy's opinions. Just as a reminder, I am working on a labyrinth game.

I am using 16x16 tiles. So if I stick to the 256x192 screen using the edges of the screen as the game's boundaries that's a 16x12 grid. Decent, but small I think. So, if I max it out to 512x512 I can't use the physical screen as a border. It will have to be like the second pic I linked, there will have to be a border. That leaves me with a 30x22 play area grid. That's a little better.

Going with the bigger grid I will need to scroll. What do you think will be more natural. Only scrolling when the ball gets near the edge (say about 2 tiles away). or keep the ball centered in the screen.

Because I am going with 16x16 tiles, the top screen will use simple 8x8 tiles to give an over view of the maze and ball location.

I'm also designing it so the levels are stored as text files. You will be able to make your own level outside of the ds. It will also have a level creator in game. In that second screenshot it is running off the following text

Code:

WWWWWWWWWWWWWWWW
WS H W W
W H W W
W H W W
WWWWWWWWWW WW
W EW W
W WWWWWWW W
W W W
W WWW W
W W
W W W
WWWWWWWWWWWWWWWW

Edit: If you think this deserves it's own thread let me know, I will remove it from this thread.

Well I just got mine. Is it supposed to show up as "No DS Card Inserted" in the firmware? I haven't tried the apps yet.

[edit] They work. Neat!
_________________
I'm a PSP hacker now, but I still <3 DS.

I got mine as well...I made a very simple demo:

http://davr.org/ds2/marbles.nds

sirpoonga,
I would say keeping it in the middle of the screen when rolling would be more natural.

However, have a 'grace area' where it can move from the center, so, for example, it can move 1 tile to the right before the scrolling starts, and if it were to go back in the other direction, it would move 2 before the scrolling took effect again...

That way, it's not rigid, and everything flows more naturally ;)

HyperHacker,
Yeah, the DS boot screen doesn't seem to register that it's a DS cart, but it works when the appropriate homebrew is run!

josath,
Nice demo, you should email it to Keith and get it included (with source) on the nds motion site :)
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

I guess it would have cost more to put in the encryption logic and mask/flash ROM to make it actually contain the required data for the firmware to recognize it. I thought that was mandatory, which is why I suggested NoPass functionality since you'd already have code in there, but apparently not.

Anyway I'm in the middle of other projects right now but I hope to squeeze out some simple demos. A simple 3D game using it might be a while off since I have no experience using the DS's 3D hardware and not a whole lot on the PC (enough to make a simple environment without lighting, hit detection, or materials whatever those are), but I'm sure I'll make something up along those lines eventually even if only a tech demo. The joypad app might take longer since I'll have to write a custom driver for it which I've also never done, and I'm not sure I can do that without installing Visual Studio, which will require me to buy a new hard drive (or repartition which would be a big pain) since this one only has ~90MB free on the system partition.

BTW, someone mentioned an app where your view of a 3D model changes as you move the system... that was my idea. :p I never told anyone about it, so obviously I can't complain (and I wouldn't anyway), but the idea was to have a laptop with a motion sensor in it, and as you moved it around, the model moved, as if the screen were a window into another world. This is probably better done with the smaller, less expensive, and more durable DS though. I'd hate to drop my laptop experimenting with that. ;-) I hope you understand what I'm describing because I think if done right it could be very cool (and perhaps a step further into realistic virtual reality). Especially if you attatched a camera behind the screen, making it as though the screen were just a hole in the system, but you could see things in it that aren't really there.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker,

Yeah, that was my idea :P
I never thought of using a camera to shoot what's actually behind the DS, though, that's definatly a big tick on your part!

But hey, it's what they say... Greay mind's think alike.

It'd probably be possible to use a simple, cheap webcam (low resolution doesn't matter since all we need is 256x193 (and could probable get away with lower!) ), a converter from USB to Serial, then the DSerial adapter by Natrium (is that a Slot 2 or Slot 1 device?)

But, don't worry, I wont cut your grass on that one, you can make the project :)
The idea came after I thought of the Breakout game, since it would require pretty much identical code for handling the movement in a 3D semi-virtual world.

Good luck!

Oh, and my Card came yesterday, so much fun!
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

Am I right in thinking that this -

Code:

#include "ndsmotion.h"
int ndsmotion = 0;

enable(); // enable the motion sensor!
if (check_ndsmotion()) ndsmotion = 1;

Is all I need enable the motion card?
ndsmotion is always 0 for me :(

Do I need to do something special when using PALib?
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

You need to give the arm9 access to the DS card before enabling.

Code:

WAIT_CR &= ~0x0880; // DS Card access ARM9:bit11=0 GBA Cart access ARM9:bit7=0

Thanks to dovoto, the most current libnds available through CVS now has support for the DS Motion Card! The enable() function in libnds gives the arm9 access to the DS card, so you won't need to take that extra step if you use the libnds functions.

JessTicular wrote:

But, don't worry, I wont cut your grass on that one, you can make the project :)

Heh, I don't care who does it, I just wanted to toss out my ideas there.
_________________
I'm a PSP hacker now, but I still <3 DS.

I just got my motion card, awesome little thing! :) Now we need some games for it...
The unique thing about the DS with the motion card is really the motion/touchscreen combination. A game using both would be great simply because it couldn't be done on (most) other devices.
I like the window-into-another-world idea. It would be nice if you could manipulate that other world with the stylus. Some ideas:
-3D puzzle. A 3D object is displayed on the bottom screen, the camera angle depends on how you hold your DS. On the top screen are puzzle pieces that fit onto the 3D object somewhere. They are rotating all the time so you can see their shape. Select a puzzle piece with the d-pad or button d-pad, rotate camera by tilting, drag it onto the object on the touchscreen.
-A 3D Rubik's Cube that can be manipulated with the stylus and watched by rotating the DS.
-Sphere pong. Like a combination of the 3D-tube pong and circle-pong games that have been appearing. Rotate your DS around to move the circle paddle sitting on the surface of a sphere. Use the stylus for small movements within the viewing area. The ball moves inside the sphere, if it gets out, you loose. A singleplayer 3D breakout version would be possible as well as a multiplayer (could be quite a bunch of people...) wifi version. Wow, that'd be insane! :D

Other ideas that use other tilt/touch combinations:
-You can move a rolling cylinder up and down by tilting your DS that way. On the cylinder is a track you have to follow with the stylus. Get from the left to the right end of the cylinder by rolling it up and down and following the labyrinth drawn on it with the stylus.
-The same thing but with a ball that rolls through a labyrinth itself. Bottom screen displays detail of the ball, keep on the tracks with the stylus. The top screen displays the scene from further away, you can see the ball in the labyrinth with it's surroundings. Get from one end of the labyrinth to the other by tilting your DS and touching the screen but not touching the forbidden areas on the ball.
-Physics based 2D-box stacking game that let's you move the platform you stack the boxes on left and right by tilting but also allows you to drag around shapes with the stylus. Make 3 of the same color touch each other and they vanish. If one box falls off the side and out of the screen, 2 new boxes appear for it from above. (Or similar standard puzzle gaming rules...)

K, I've thought of some nice ideas I can work on in the days off I have coming up (though I'll probably get called to work a few of them), so hopefully I can have a very simple demo app done by tonight and more complex/fun stuff later this week/month. If I knew more trigonometry such that I could implement working 3D hit detection, I could make some really fun stuff. (Hint hint, anyone know a website that might teach me a few things? I didn't pay attention in class, stupid me >_< I can do 3D, just not hit detection - I've managed a mostly-copied, very slow algorithm that tests whether a line intersects a polygon, but this is of limited use and I don't really understand a lot of it.)

[edit] Hm, this thing can only tell me how fast I'm moving, not how high off the ground I am. That may make some things difficult. My original plans were a speedometer/pedometer/possibly altimiter. The third isn't going to be possible unless the player were to enter the altitude they start at which would kinda suck. First two may be possible but I'm not sure entirely how to go about doing them. The speedometer especially will likely require a load of trig to translate X, Y and Z speed into forward speed; I struggled with this for quite some time implementing movement in my 3D experiments, and still don't entirely understand how I got it working. (In fact it broke again, but probably due to some stupid typo or something.)
For a pedometer I was thinking put it in your pocket and it counts how often it goes up and down, but this may be complicated by the fact that it could be oriented just about any way and even move while in there. I recall now that most of these things (never used one myself) are strapped to one's leg, unable to move on their own. That doesn't mean it's impossible, but it may mean you have to carry the system in a rather strange fashion.

However, motion speed should be all the info I need to make some simple games, which don't necessarily involve real-world physics. :-p

Also, I'm getting a value of ~3 degrees/sec for rotation when not moving using the default rotation offset of 1680. 1683 seems to work better. However, even when not moving, all 4 numbers jump around quite a bit. Is this normal?
_________________
I'm a PSP hacker now, but I still <3 DS.

Well I can't seem to get this thing working right. The gyroscope seems to be broken; sometimes it doesn't respond at all, and sometimes it just starts reading off the charts at random. On the off chance it does respond it likes to keep reading the same speed even after I set it down. The Z axis sensor just jumps around wildly, it is responding to my movements but it randomly reads really high or really low values.

The X and Y sensors seem to be working fine, and the code is pretty much copied and pasted between all four sensors, so I have no idea what it could be. Interestingly I get different results when I poke the touch screen, reading ~8 degrees/second sometimes.

[edit] This could be a DevKitARM/libNDS problem, as I'm seeing different results depending whether I use /64 or >>6 which should do the same thing. O_o The test app is showing similar issues though. Rotation hovers around 6-7 degrees, X accell around -32, Y anywhere from -30 to 10, and Z around 990-1003, all while sitting perfectly still.
_________________
I'm a PSP hacker now, but I still <3 DS.

As with any sensor, there will always be slight errors. The values you are seeing in the test application are fine - they are within the tolerance for these sensors. If you need very tight precision, you'll need to do a calibration at the start of the game. Even commercial games that used motion sensors (Yoshi topsy turvy, warioware twisted, etc.) have a calibration mode.

These are also very sensitive sensors, and they will pick up any vibration they feel - motors/fans vibrating nearby, people walking, loud noises, and especially human hand vibrations. When holding the device in your hand - even very still - you can expect the X, Y, and Z accelerations to change by 30-50 counts.

New version of PALib just released.

PAlib 070118
"[DSMotion] Official DSMotion code added !!! Check the Input examples to see how it works (init/getting the data). Has 2 different ways of playing with it : either get the raw values and use that, or transform the data into Pad.Held.Up/etc data"

I just got my DS back - I had loaned it out. Tried out all the demos made so far - all I can say is wow. It's great to see what has been made so quickly, and I can't wait to see what will come in the next few months.

I'll post links to all the DS Motion Card projects on ndsmotion.com.

The entire first batch of cards is gone - all of them have been given to developers or sold to shops. It will be about 3 months until a new batch is ready, so if you want one you should purchase it soon before the shops are all sold out.

I have been very pleasantly surprised at the popularity of this card. Thank you to everyone for your support!

It's not a big deal. I will buy DS Motion Card if something more than a couple of tech demos will show up on the scene. =)
Frankly, in the current state it's only really useful to the developers and people who are eager to test the new stuff first. But - it's a good job nonetheless, Keith. Keep it up! ^_^

I just wonder if somebody will hack the commercial games to use it. =D
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

Alright, I thought the readings were probably normal, just seemed strange that Z and R jump so much while X and Y stay within a smaller range. Must have math bugs in my code, stupid floats. Is the floating point emulation DKA uses reliable? I've been using it instead of fixed point because it's easier and speed is not yet an issue, though I'll probably convert it all to fixed before it's done.

I've never used a motion-sensitive game before aside from the Wii I just got, and it doesn't appear to require any sort of calibration. What sort of things would these games do to calibrate? Have you just sit the system on a flat surface and wait? My current "calibration" method is to allow the user to adjust the offset and sensitivity for each axis until it's giving an acceptable reading when sitting still.

Speaking of which, since sensors vary, some sort of standard calibration system may be necessary. I was thinking just storing the offset/sensitivity values in a binary file in /data/ndsmotion.dat or something along those lines. Any better ideas?

[edit] Hey, I just realized something neat. Learning to work the DS Motion Card now will give us a head start in coding for the Wiimote when Wii homebrew becomes possible. :-)
_________________
I'm a PSP hacker now, but I still <3 DS.

Well something is definitely wrong with the gyro. I rigged my program to record the minimum and maximum values return from each call (readX(), readGyro(), etc). The axes are all normal (though I notice if I suddenly move very fast along one axis, both the maximum and minumum change significantly), but the gyro never reads less than 1677 or more than 1684 no matter what I do. These values get set by the first few readouts, even when the system is sitting on the table, and that's it. I also checked with the supplied test program, holding a webcam to the screen so I could read it while shaking it around, and it did the same thing, never reading <6 or >7 degrees per second. :-/

Could launching via DS Download Play have anything to do with it? Has anyone got the gyro working? I get slightly different results launching from DSOrganize (1679 < rotation < 1686); my app won't run from Moonshell for some reason and DSO's alternate launch seems to be broken (hangs at Initializing FAT).
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

[edit] This could be a DevKitARM/libNDS problem, as I'm seeing different results depending whether I use /64 or >>6 which should do the same thing.

They don't. C specifies that /64 rounds toward zero; on common architectures, >>6 rounds toward negative infinity.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

OK, I suppose that makes sense. I've figured out what my problem was with the Z axis; as I expected, it was just me doing it wrong - specifically, not quite understanding the difference between acceleration and velocity. In case anyone else is having this problem: velocity is how fast you're moving, acceleration is how fast your velocity is changing. Hence, if you take your DS and drop it straight down, the velocity is going to do what I was expecting the acceleration to do - increase until the system hits the ground, then drop to zero. The acceleration is going to increase slower and slower as the system nears terminal velocity (maximum falling speed) and then drop back to zero. Now here's the important part: when it hits the ground, acceleration will do the same as it just did, but negative, hence velocity dropping to zero.

(Of course I was not dropping my DS on the ground, just moving it up and down fast. Same idea. :-p)

Big hint: Put a screen in framebuffer mode and have it plot the readouts on the screen in various colours. Watch what they do as you move in different ways. This should help you determine how to detect such an action. For example, you can clearly see that there is much more variation when holding the system than when it sits on a table, and that when holding the system in front of you standing up, Y goes down and Z goes up. (They should all be zero when the system is laying flat on a table, assuming you account for gravity on the Z axis.)

Still no feedback from the gyro though. :-/
_________________
I'm a PSP hacker now, but I still <3 DS.

Hello there

I'm very interest in acquiring this but I have a question.

Does the slot-1 card allow me to go to sleep mode without that on-off-on-off thingy? Does it have those required connections?

Thanks:)

tuLL > homebrews don't need a DS signature to go in sleep mode anyway (if coded for)

I'm pretty sure he's asking about a problem with some other DS cards such as older Action Replays. I'm not sure exactly why but since these cards didn't have two pins connected, commercial games/demos would get confused when trying to enter sleep mode, and do things like go into a loop entering and exiting sleep mode repeatedly, crash, or just not sleep at all.

So basically the question here is if we're playing a WMB demo with the DS Motion Card inserted, will they enter sleep mode correctly? I'd check but my card turned out to be defective so I had to send it back; I imagine they will though, since it lacks the necessary hardware for the DS to even recognize it as a DS card; the games will probably just act like no card is present.

Homebrew doesn't have this problem as it ignores the card interrupt, and if it is an issue, you can simply insert an official card before using a demo.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

I'm pretty sure he's asking about a problem with some other DS cards such as older Action Replays. I'm not sure exactly why but since these cards didn't have two pins connected, commercial games/demos would get confused when trying to enter sleep mode, and do things like go into a loop entering and exiting sleep mode repeatedly, crash, or just not sleep at all.

...

Homebrew doesn't have this problem as it ignores the card interrupt, and if it is an issue, you can simply insert an official card before using a demo.

Yes, that's what I'm saying, But you're right, homebrews never go to sleep right? An official card will do the trick.

Thanks! I think I'll rush and buy one:)

Some do, but they don't enable the card interrupt, so they don't respond to the card inserted/removed notifications.
_________________
I'm a PSP hacker now, but I still <3 DS.

I just had another fantabulous idea!

A vertical scrolling shooter.

Move the DS right to move the ship right, left for left, push it down to drop down, up for up, back and forth...
Would use all 6 axis of the accelerometer, and would be sweet fun to play :D
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

Has anyone other than me noticed that mml detects ad dsmotion card using the detection routine? not sure if thats a problem for anyone, but my game detects the card(or not) and sets the control type based on that. so if mml is inserted (or of course motion card) tilt controls are set, else d-pad.
_________________
I'm not a boring person, it's just that boring things keep happening to me.
Homepage

Yeah, the detection routine could use some improvement. I'm currently updating all of my demos to use the libnds motion card functions, and when I'm done with that I'll work on improving the existing functions. If you have ideas for improving them, please let me know.

Here are my plans so far:

1) Change the motion_enable() function so it returns a value to indicate whether or not the enable was successful. This will replace the motion_is_inserted() function. If motion_enable returns true, you'll be good to go. If it returns false, there is no DS Motion Card.

2) Add functions for the combined nopass/DS Motion Card in development (This product may or may not ever see the light of day, so don't get too excited yet)

3) Add functions for the slot-2 motion pak in development.

I'm planning to make the functions so they will work with any of the three options. So a developer could develop with one of them, and their code will work with all three.

KeithE wrote:

I'm planning to make the functions so they will work with any of the three options. So a developer could develop with one of them, and their code will work with all three.

I think a Motion API thread may be in order.

-Brendan

does this card act has a pass card?
_________________
My Blog

No.
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

Question, why slot 1?

Well anyway I have an idea for the name that might seem obvious but wasn't mentioned yet.

Why don't you just call it the Motion Pack/Cart named similarly to the Rumble Pack/Cart. I mean it seemed the obvious name to me. Sure throw in a "DS" in there if you want to be gimmiky about it.

Anyway other name ideas

WiiMote Pack/Cart (wheeee motion :D)

eMotion Pack/Cart (electronic motion.. yes)

Space Pack! (KIDS LOVE SPACE!!)

Motion and Orientation Sensitive Aparatus for the DS in Slot 1 Cart form.
_________________
Some people think asians are smart, I've devoted my life to prove otherwise!

Koji wrote:

Space Pack! (KIDS LOVE SPACE!!)

Of course it's not my opinion that matters, but I always looked at the motion pack as a dev toy for geeks old enough for a credit card, not a kid's toy.
_________________
If I use a term wrong or something then feel free to correct, I?m not much of a programmer.

Original DS Phat obtained on day of release + flashme v7
Supercard: miniSD, Kingston 1GB, Kingston 2GB
Ralink chipset PCI NIC

gbadev.org forum archive

DS Motion Sensor > DS motion sensor

#108637 - KeithE - Fri Nov 10, 2006 8:32 pm

#108638 - thegamefreak0134 - Fri Nov 10, 2006 8:46 pm

#108644 - KeithE - Fri Nov 10, 2006 9:12 pm

#108645 - MaHe - Fri Nov 10, 2006 9:17 pm

#108650 - josath - Fri Nov 10, 2006 10:01 pm

#108667 - pollier - Sat Nov 11, 2006 3:47 am

#108671 - knight0fdragon - Sat Nov 11, 2006 3:54 am

#108679 - Lynx - Sat Nov 11, 2006 5:14 am

#108684 - Sektor - Sat Nov 11, 2006 7:21 am

#108715 - KeithE - Sat Nov 11, 2006 4:29 pm

#108741 - Agilo - Sat Nov 11, 2006 7:44 pm

#108767 - Sausage Boy - Sat Nov 11, 2006 11:55 pm

#108810 - lyingisanartform - Sun Nov 12, 2006 4:55 am

#108837 - HyperHacker - Sun Nov 12, 2006 8:06 am

#108924 - Lynx - Mon Nov 13, 2006 5:42 am

#108986 - shadow1w2 - Mon Nov 13, 2006 9:34 pm

#108991 - KeithE - Mon Nov 13, 2006 10:01 pm

#109069 - Inopia - Tue Nov 14, 2006 8:40 pm

#109127 - alekmaul - Wed Nov 15, 2006 9:26 am

#109144 - freemaan - Wed Nov 15, 2006 4:00 pm

#109179 - Lynx - Wed Nov 15, 2006 9:29 pm

#109195 - SyntaxGS - Thu Nov 16, 2006 12:17 am

#109322 - dh2050 - Fri Nov 17, 2006 6:02 am

#109335 - thos_thom - Fri Nov 17, 2006 11:30 am

#109818 - thos_thom - Tue Nov 21, 2006 1:42 pm

#109877 - HyperHacker - Wed Nov 22, 2006 5:35 am

#109997 - MrD - Fri Nov 24, 2006 3:25 am

#110044 - thos_thom - Fri Nov 24, 2006 6:21 pm

#110150 - Dood77 - Sun Nov 26, 2006 1:14 am

#110273 - hydraspray - Mon Nov 27, 2006 12:05 pm

#110303 - sirpoonga - Mon Nov 27, 2006 7:16 pm

#110313 - KeithE - Mon Nov 27, 2006 9:09 pm

#110316 - sirpoonga - Mon Nov 27, 2006 9:15 pm

#110716 - sirpoonga - Thu Nov 30, 2006 10:59 pm

#111593 - The_Legend - Fri Dec 08, 2006 3:32 am

#111637 - KeithE - Fri Dec 08, 2006 5:30 pm

#111975 - dustin - Tue Dec 12, 2006 4:32 am

#112013 - HyperHacker - Tue Dec 12, 2006 1:24 pm

#112033 - sirpoonga - Tue Dec 12, 2006 6:10 pm

#112039 - Lynx - Tue Dec 12, 2006 7:43 pm

#112044 - tepples - Tue Dec 12, 2006 8:16 pm

#112048 - sirpoonga - Tue Dec 12, 2006 8:50 pm

#112076 - HyperHacker - Wed Dec 13, 2006 12:18 am

#112096 - Lynx - Wed Dec 13, 2006 4:42 am

#112097 - knight0fdragon - Wed Dec 13, 2006 5:46 am

#112250 - srkelley - Thu Dec 14, 2006 10:02 pm

#112273 - josath - Thu Dec 14, 2006 11:15 pm

#112291 - tepples - Fri Dec 15, 2006 12:46 am

#112322 - Lynx - Fri Dec 15, 2006 6:42 am

#112355 - KeithE - Fri Dec 15, 2006 3:45 pm

#113476 - sgeos - Thu Dec 28, 2006 1:53 am

#113481 - HyperHacker - Thu Dec 28, 2006 5:01 am

#113516 - sgeos - Thu Dec 28, 2006 1:40 pm

#113518 - Mighty Max - Thu Dec 28, 2006 1:57 pm

#113540 - KeithE - Thu Dec 28, 2006 6:54 pm

#113542 - sirpoonga - Thu Dec 28, 2006 7:41 pm

#113552 - sgeos - Thu Dec 28, 2006 9:46 pm

#113557 - Mighty Max - Thu Dec 28, 2006 10:25 pm

#113558 - KeithE - Thu Dec 28, 2006 10:53 pm

#113582 - sgeos - Fri Dec 29, 2006 1:42 am

#113591 - Lynx - Fri Dec 29, 2006 2:04 am

#113610 - sgeos - Fri Dec 29, 2006 5:10 am

#113749 - HyperHacker - Sat Dec 30, 2006 8:57 am

#113999 - KeithE - Tue Jan 02, 2007 3:42 pm

#114065 - alekmaul - Wed Jan 03, 2007 1:58 pm

#114127 - sgeos - Thu Jan 04, 2007 10:02 am

#114184 - Lynx - Fri Jan 05, 2007 1:01 am

#114187 - chishm - Fri Jan 05, 2007 2:17 am

#114634 - sirpoonga - Tue Jan 09, 2007 5:55 pm

#114647 - sirpoonga - Tue Jan 09, 2007 7:31 pm

#114651 - Lynx - Tue Jan 09, 2007 7:57 pm

#114844 - KeithE - Thu Jan 11, 2007 1:40 am

#114876 - JessTicular - Thu Jan 11, 2007 6:31 am

#114903 - sgeos - Thu Jan 11, 2007 12:52 pm

#114904 - JessTicular - Thu Jan 11, 2007 12:56 pm

#114940 - sirpoonga - Thu Jan 11, 2007 8:50 pm

#114945 - HyperHacker - Thu Jan 11, 2007 9:15 pm

#114990 - josath - Fri Jan 12, 2007 1:34 am