Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - tob.s

Pages: [1] 2
General Discussion / Re: Progress on Navigation ?
« on: December 08, 2016, 02:01:30 pm »
well im not speaking about actually hiting the walls, but about driving zig zags instead of a straigh line - my goal is to avoid any unecessary turning. Lets say in a straight corridor a bot is moving nearly but not exactly paralel to the wall on its right - most bots would simply turn a bit to the left when a certain distance to the wall is reached, then the will drive straight until the get close to the left wall and turn right and so on... so the easiest way to avoid this is to make the bot stay in the middle between those walls - this works well in a corridor, but leads to problems in a maze ( like driving into any obstacle thats exactly straight ahead and/or having trouble to turn away from the obstacle in such a situation - and its also likely to "irritate" the bot while its turning. So youll need workarounds for those situations but every workaround could again cause unwanted effects.

My goal would be to have a little situational awareness, so its not like "if obstacle -> turn" but more like "obstacle there, obstacle there,.. i wanna move this way and the closest i can get to this is this direction" 

General Discussion / Re: Need info on plasma-projectiles
« on: December 08, 2016, 01:23:06 pm »
im currently not thinking to much about combat efficency but to figure out ballistics once and for all, atm im using plasma as its much easier to handle ( exact speed, infinite reloads, doesnt blow up your bot if accidentialy triggered ) and its high range shows even the smallest inaccuracys, but once my gun is working, it should be able to fire and hit with anything ( rockets / hypercannons/pistons ) . Basicly all u need would be to adjust the projectiles speed

Yes that changing gravity realy is a problem, i didnt know it increases with altitude on blueshift, this explains why my tries on firing the high arc always ended way to short and also why i had to tweak the projectile speed value to 103.5 instead of the actual 101.2 (shoot force  4000 / 39,5 ) when firing the low arc. It should be possible to calculate the flighpaths highest point and also to calculate the gravity up there. The middle between those two gravity values should do ( atleast aslong as theres no big altitude difference between cannon and target )

just tested this and ended up shooting a bit too far, tested further and it turned out gravity isnt increasing linear - sigh why does it have to be that complicated.

that idea seems promissing,, will give i a try


to hit something moving, you need to be able to hit a stationary target very precisely first.
i always used rel. simple geometrics to determine the launch angle of my cannons - so they were basicly pointing directly at the target ( with some offsets to counteract gravity for certain ranges ).
This time though i used ballistic calculations to proper include gravity and the result is  ;D , but see yourself.


I linked the target to the cannon, so i could fire it without having to switch between target and cannon, also added some distance-  and a *wip* time-to-target -display , targeting is using a camera imput though and isnt connected to any off the other stuff. Everything exept firing is full automatic, the target turns red whenever i press my fire key.

There seems to be a bit of a dead/lower accuracy spot when firing nearly horizontal, i guess its because many of the arc functions deliver values very close to zero - not sure if the "freezing" of any slow moving object also affects this - so in the video im firing short salvos. If the first shot doesnt, the second one hits ( seems like the physics have to be woken by the first shot). Also im currently not compensating the very small differnce between the set angle and the cannons actual pitch, which might also be the cause.

The Values i couldnt calculate are based on experiments and guesswork, so theres still room for improvement.
Next step will be to declutter / nicely arrange the vp-code and then figure out how to hit moving targets.

- edit-
with your help, some value tweaking and also by adding a controler to make sure the cannons pitch is exactly alignend to the calculated launch angle, i nearly doubled range. Now it hits precisely between distances of 50 to 1000. Maximum shooting distance at the given speed  and 45° launch angle is around 1250 . However at more than 1000 range, the closer i get to max range, the increasingly earlier the projectiles drop. I tried changing the projectile speed in the calculations but it has no effect, so i guees it may be due to rounding &/ canon alignment errors.
video is being updated

General Discussion / Re: Need info on plasma-projectiles
« on: December 07, 2016, 03:05:04 am »
thanks - after a lot of fiddling, i, pretty pleased with my result ( see seperate thread ), still im not 100% sure if those maths are correct or just happen to work under the tested conditions. Im not realy good at maths, so a lot of it is guesswork ( especialy when arc-functions are involved ). Currently im using a speed of 75,5 for my calculations - using half G.
At 1 Capaticy, the shot force is around 4000 - divided by 39,5 thats 101,2... ill give this a try together with 1g and see what happens.

General Discussion / Need info on plasma-projectiles
« on: December 07, 2016, 12:21:20 am »

currently my plasma-turrets use triangulation or the altitude difference based maths for vertical aiming - both methods ignore gravity though, which easily could lead to missing even a stationary target at above medium distance.

so currently im trying to use the same ballistics i used to lob the grenades in the video below to aim with a plasma cannon. I determined the speed of the plasma by firing backwards from a plane - around a speed of 75 the plasma drops almost vertical from the plane, so i fed my maths with v=75. Also, plasma seems to be floating / not fully affected by gravity - i reduced it to half witch seems to work, to realy be sure ill need to build a much larger test-map though. Atm im still using the formula for targets at the same altitude, as the error is minimal when firing in an high arc.  Now with plasma though, the arc is very flat, so im currently searching for the correct formula.

as i renember, xfm tweaked the plasmas behaviour - so the correct values might have been posted somewhere back then. If someone knows the exact values it would be a big help.

basicly, i just added the fins to make the missile turn accourding to its flight path ( without, the missile would just keep the angle at wich it was launched as theres no air resitance) , so its mainly decorative and to see how much of a differnce the drag would make. One benefit though is that the missiles always hit with the grenade first, while without fins they would crash their rear into the ground short before the target, sometimes even making them bounce of target - as seen on this old bot

video should be public now

Also thought about adding reverse thrust to that missile, set the lauch to double speed ( so the flightpath should have its highest point directly above the target ) and stop the missile midair when directly above the target, so it will fall down at the target from directly above ( maybee even accelerating as soon as pitch hits -90 )

in the meantime i tried using a hypercannon


changed the design of my launcher a bit so it uses a larger rocket with fins. Also now using a fixed launch angle of 45° and instead just varrying the missiles speed based upon distance ( d=vē/g   if launch at 45° and startpoint and impact point at the same height ). Tends to shoot a bit too far at high distances, but hits accurate at distances around/below 500


tinkering on ballistics again, atm i have troubels getting my jet-driven projectile to accelrate nearly instantly to a certain variable speed (desired vfront between 50 and 150 ) - atm im using a pid and a counter ( maths operator&multiplexer ) to shut the jet off some 10th seconds after launch and/or as the desired speed is reached. In theory the pid shouldnt alow the projectile to get faster than its setpoint, but if the kp is to high, the initial thrust is so high that the projectile reaches speeds above the setpoint - if the kp is to low though, the projectile doesnt reach the desired speed fast enough. With some trial & error i reached a good precision when using a fixed velocity. However i want to optimise the projectiles flightpath for an relatively flat arc ( so instead of lauching almost straight up when a target is close, the projectiles launch speed should be reduced until a launch at 45° would hit the target )

I also used fast pistons  to toss grenades before, but it doesnt seem very precise / affected by framerate

any ideas ?

General Discussion / Re: Progress on Navigation ?
« on: December 02, 2016, 06:23:59 pm »
though my old erazer Acl bot used such a relatively simple setup and layed down some nice high speed manouvers, it also could easily get trapped in an edge, oscilating left and right and also missed its target quite often ( it was meant to ram it with lasers )as target following and wall avoidiance fought each other. So thats what im trying to get away from, as u basicly just bump from wall to wall wich doesnt look very smart - perhaps i started at the wrong end and its better to make a bot that turns only by fixed angles as base for further ideas - it might simply things.

as for the coordinate system idea i can only thing of it helping to align your bot to stay paralell to walls, knowing the bots relative position though wouldnt help with pathfindings unless u had a map of the arena, but thats beyond the visual programming possibilities

General Discussion / Re: Offering an idea
« on: December 02, 2016, 05:40:09 pm »
just trying to get it to work, but im not exactly clear how to translate the musical standards to something rawbots understands - im using a korg nanokontrol 2 to generate midi, then use this ( ) as midi to osc bridge ( u have to set the osc out port to 8000 in the settings xml file) wich seems to work nicely as i monitored incomming osc data with this However my Osc message look like "noteOn" "94" "127" where notOn is the type of event, 94 is the number of the corresponding note and 127 being the velocity ( = loudness of the note )
so i guess for rawbots it should be /noteOn/94 but it nothing happens - maybee ill try with touchosc later to see if it works when using the exact settings shown in the video


General Discussion / Re: Offering an idea
« on: December 02, 2016, 04:15:48 pm »
i always wanted to visualize sensor data ( eg from a hook ) to get a better understanding of how your bot sees the world.
On my small real robot i had a sharp ir distance sensor ( acts like a laser range finder but is much cheaper ) mounted to a servo - it sweeped the servo full 180 deg, measuring the distance at every deg - this data was then transmitted to pc / processing via serial where it was written in an array and also visualized ( looked very much like a radar screen ). As next step i planned to let the bot move a fixed distance and scan again, combining the offset from the bots last position and the new distance readings to get a map of the room and also evaluting shapes ( a ball should be easy to identify as it would always show the same siluette just varying in size  regardless of the bots position to it ) . But as the tank chasis i bought is realy poor at running straight ( i used photocells to sync left / right rpm but never got to work exactly ) i didnt get any further.

When it comes to reading from ram i just tried with cheat engine to find a single blocks mass i set to random values , but i had no luck. Still if i could have read it the address one would need to run this process everytime he starts rawbots/loads the bot and its likely to crash the game.

As for OSC im not totally sure if its just input ( by default osc is bidirectional ) im assouming they used an osc-libary instead of writing their own solution, so the function to send osc might be in there but not connected to any vp-tile - if you want to further investigate, this seems to bee the most popular osc libary for unity -

thanks for the link to the old topics, so its port 8000 ( someone also mentioned 9000 ) and in the input sampler you should write the address like /1/rotary1 - havent done anything with osc for a long time, but i got plenty of midi controlers here and might give it a try.

Pages: [1] 2